I forgot to include the debugging output from the crash.
yt : [INFO ] 2012-01-17 23:16:58,301 Rendering fisheye of 100^2 vz = nan nan -26.912 nan, dv = 0.604703, ds = 14 6 16, dp = 0.911364 0.9 0.395297 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan vz = nan nan -26.9203 nan, dv = 0.414264, ds = 14 6 16, dp = 0.934091 -0.1 0.585736 OINDEX(0,0,0) = nan, OINDEX(0,0,1) = nan Segmentation fault
On 17 Jan 2012, at 23:21, John Wise wrote:
I tried to make some volume renderings with the latest tip (f7e39b91cc6b), and it was crashing because there were NaNs in the data when offset_interpolate was called. I could make it crash in a small fisheye rendering (100x100) of a 128^3 AMR simulation. I've uploaded the dataset (538MB) and script to
I uploaded a diff of my debugging statement to here.
When I reverted back to the changeset (1558cb36d03b) before the ghost zone update, this problem when away. Could someone look at this or tell me where to search for the bug?
On 17 Jan 2012, at 17:29, Matthew Turk wrote:
Looks great. Thanks.
As a sidenote, I added the functionality to auto-detect which fields are needed; supplying them in ValidateSpatial should be faster, though. Thanks!
On Tue, Jan 17, 2012 at 5:22 PM, Britton Smith email@example.com wrote:
I'm finally following up on this thread. I just submitted a pull request for the docs that includes some documentation of how to create fields that use ghost zones. Some of it was a little tricky to explain, so let me know if the wording can be improved.
On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk firstname.lastname@example.org wrote:
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith email@example.com wrote:
I'm not sure I understand the change that you're talking about, but it seems that they were auto-detected in the past, since the example without them there used to work. I'm in favor of returning to that if possible. Regardless, I think it would be worthwhile to add something to the derived fields documentation discussing this. I could add that if we wanted it, but it will be good to have it reviewed, since I'm not very familiar with how it works.
I think the best solution would be to have it simply auto-detect the fields necessary, rather than mandating they be specified (which may not always give the correct results.) I'll implement this tomorrow morning.
After some digging, it seems to me that this situation arose because we fixed a bug which had silently allowed this to occur, related to checking for field parameters in fields requiring ghost zones.
On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk firstname.lastname@example.org wrote:
It may not be documented, but I think we can actually auto-detect them; this would add on a list of lists of strings to the hierarchy, but I think that is manageable. Would this be worthwhile?
On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith email@example.com wrote:
> Hi Sam, > > That fixed it, thanks! I actually encountered this problem while > working on > my own derived field that used ghost zones and was using > VorticitySquared as > my example for how to do it. I think in the past it was not required > to > list the fields with ValidateSpatial, which is why it was working as > is > in > older versions. I wasn't able to find documentation on how to make > fields > that use ghost_zones. If it's in there and I just missed it, could > someone > point me toward it? If not, I could add something to the Creating > Derived > Fields section. > > Britton > > > On Wed, Jan 4, 2012 at 11:46 AM, Sam Skillman firstname.lastname@example.org > wrote: >> >> Hey Britton, >> >> It looks like VorticitySquared wasn't specifying the necessary >> fields >> (x,y,z velocity) in the definition. I will push a change >> momentarily >> after >> I look around at any other ghost zone requiring fields to make sure >> they >> work. DivV, for example, does the right thing. >> >> Sam >> >> >> On Wed, Jan 4, 2012 at 9:32 AM, Britton Smith >> email@example.com >> wrote: >>> >>> Hi everyone, >>> >>> I'm having a problem using fields that use ghost zones. The >>> following >>> simple script: >>> http://paste.yt-project.org/show/2010/ >>> >>> gives this error: >>> http://paste.yt-project.org/show/bOikDPScBBtDiUGvH11X/ >>> >>> I am working from the tip, but I get the same behavior from yt/2.3. >>> In >>> yt/2.2, everything is working. I am working now to narrow that >>> range >>> down a >>> bit, but does anyone have an idea? >>> >>> Britton