Hi John,
I isolated the problem to when you have > 1 level jump in refinement
at an Enzo root grid tile boundary. I believe the fix I just pushed
(33df4ef9f06c) should fix this case without resulting in a performance
degradation for other situations (i.e., FLASH simulations or nested
hierarchy simulations.)
Thanks for bringing this up ...
-Matt
On Wed, Jan 18, 2012 at 12:02 AM, Sam Skillman
Hi John,
I just verified that it breaks on my even simpler data with the MosaicFisheyeCamera with no_ghost=False (getting the vertex centered data). However, it does not fail when doing a normal rendering. I'm out of steam for tonight, but hopefully we'll track this down right away. If you want to do stuff for now, you can do hg backout e699c92663c2 and stay on the latest tip without that ghost zone change. I'm sure this'll be a high priority to fix.
Best, Sam
On Tue, Jan 17, 2012 at 9:24 PM, John Wise
wrote: 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:
Hi,
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
http://www.physics.gatech.edu/~jw254/scpics/RD0009.tar http://paste.yt-project.org/show/2042/
I uploaded a diff of my debugging statement to here.
http://paste.yt-project.org/show/2041/
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?
Thanks! John
On 17 Jan 2012, at 17:29, Matthew Turk wrote:
Hi Britton,
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!
-Matt
On Tue, Jan 17, 2012 at 5:22 PM, Britton Smith
wrote: Hi everyone,
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.
Britton
On Wed, Jan 4, 2012 at 2:03 PM, Matthew Turk
wrote: Hi Britton,
On Wed, Jan 4, 2012 at 1:32 PM, Britton Smith
wrote: > Hi Matt, > > 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.
-Matt
> > Britton > > > On Wed, Jan 4, 2012 at 1:26 PM, Matthew Turk
> wrote: >> >> Hi Britton, >> >> 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? >> >> -Matt >> >> On Wed, Jan 4, 2012 at 1:24 PM, Britton Smith >> >> 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 >>> >>> 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 >>>> >>>> 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 _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org