[yt-dev] seg fault on projections
Matthew Turk
matthewturk at gmail.com
Thu Mar 15 07:32:38 PDT 2012
Hi Eric,
This is intentional, but I think Dave's were something else.
RefineBy=2 allows you to use the (much, much faster) quadtree-based
projection; Enzo's default is RefineBy=4, so if you just run a unigrid
you're likely not going to override that. The overlap proj is what we
used up until about a year ago by default. The specific bug you saw
is puzzling to me, and I'm not sure without more detailed traceback
how to proceed. Could you run with --paste-detailed ?
On Thu, Mar 15, 2012 at 10:29 AM, Eric Hallman <hallman at txcorp.com> wrote:
> Matt,
> my prior error below is not related to the previous problem. But it does
> bring up a weird issue I thought you'd be interested in. I did not define
> any refinement criteria, but Enzo is writing the parameter "RefineBy" as =4
> by default in a unigrid run. This is causing yt to use something called
> "overlap_proj"? Which is crashing the projection. If I go back and set
> RefineBy=2, the problem vanishes. This is maybe more of a Enzo issue than
> yt, but if one is using non-factor-of-two refinement, it could cause
> problems. Could this be related to Dave Collins' problem with RefineBy=4?
>
> Eric
>
>
> On Mar 15, 2012, at 10:10 AM, Matthew Turk wrote:
>
> Okay, let's back out that changeset. I think it is okay to mandate an
> instantiated hierarchy if you want to have detailed, output-specific field
> information.
>
> On Mar 15, 2012 10:02 AM, "Eric Hallman" <e.hallman at me.com> wrote:
>>
>> Matt and Stephen,
>> I can confirm that the seg fault disappears on Mac OS X when updating to
>> h5py-2.0.1, though a simple projection is still giving an out of bounds
>> error on a simple unigrid data set. Not sure why that occurs. But I think
>> Matt is definitely right about h5py:
>>
>> p = pc.add_projection('Density',0)
>> File
>> "/Users/hallman/work/yt-i386/lib/python2.7/site-packages/yt-2.4dev-py2.7-macosx-10.4-x86_64.egg/yt/visualization/plot_collection.py",
>> line 758, in add_projection
>> **field_parameters)
>> File
>> "/Users/hallman/work/yt-i386/lib/python2.7/site-packages/yt-2.4dev-py2.7-macosx-10.4-x86_64.egg/yt/data_objects/data_containers.py",
>> line 1930, in __init__
>> self._refresh_data()
>> File
>> "/Users/hallman/work/yt-i386/lib/python2.7/site-packages/yt-2.4dev-py2.7-macosx-10.4-x86_64.egg/yt/data_objects/data_containers.py",
>> line 309, in _refresh_data
>> self.get_data()
>> File
>> "/Users/hallman/work/yt-i386/lib/python2.7/site-packages/yt-2.4dev-py2.7-macosx-10.4-x86_64.egg/yt/data_objects/data_containers.py",
>> line 2127, in get_data
>> pdxs = na.concatenate(pdxs, axis=1)
>> IndexError: axis 1 out of bounds [0, 1)
>>
>>
>> On Mar 15, 2012, at 4:55 AM, Matthew Turk wrote:
>>
>> > Hi Stephen,
>> >
>> > A bunch of people have been reporting segfaults. I am starting to
>> > think it may be an issue of an older h5py combined with this change,
>> > which may build up multiple copies of the hierarchy and keep multiple
>> > copies of a file (in this case the data file) open.
>> >
>> > I think we should consider backing this change out, and providing it
>> > in a more subtle way -- for instance, making field info just always
>> > create the hierarchy. Here it actually almost always creates it
>> > twice. Remove the deletion, just leave the hierarchy in existence.
>> >
>> > -Matt
>> >
>> > On Wed, Mar 14, 2012 at 10:46 PM, Stephen Skory <s at skory.us> wrote:
>> >> Bah humbug.
>> >>
>> >> I did a fresh install on my mac, and the problem went away. I wonder
>> >> what cruft I had left over was getting in the way? I deleted the .yt
>> >> file etc...
>> >>
>> >> Anyway, sorry for the noise, move along.
>> >>
>> >> --
>> >> Stephen Skory
>> >> s at skory.us
>> >> http://stephenskory.com/
>> >> 510.621.3687 (google voice)
>> >> _______________________________________________
>> >> yt-dev mailing list
>> >> yt-dev at lists.spacepope.org
>> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
>
> --
> Eric Hallman
> Tech-X Corporation hallman at txcorp.com
> 5621 Arapahoe Ave, Suite A Phone: (720) 254-5833
> Boulder, CO 80303 Fax: (303) 448-7756
> --
>
>
>
More information about the yt-dev
mailing list