Hi Matt, Stephen,
I think there is then an issue of how does the user know what the size of
the image is. Perhaps we should load up some hdf5 attributes that include
things like length, pixel scale, etc. The nice thing about the old behavior
was that you could easily figure out what the size was from looking at what
the default was. And if you changed it, then you know from the start.
Thoughts? I would be in favor of this change assuming we add the hdf5
attributes.
Sam
On Mon, Apr 11, 2011 at 8:34 PM, Matthew Turk
Hi Sam,
My feeling is that the HaloProfiler does a *lot*, and I would like to see it become feature parity with enzo_anyl. (A shame that we haven't yet fully recreated that enzo_anyl experience yet, with anything in yt...) As such, I think we should be positioning it as useful for a lot of domains.
I guess the choice is really, do we want it to do something smart? Or do we want to let the code knowingly go down, and then tell the user "Sorry, but we warned you!" while shaking our heads and shrugging our shoulders.
-Matt
On Mon, Apr 11, 2011 at 8:20 PM, Sam Skillman
wrote: Hi I would advocate, instead of changing the default, adding a message that says: halo profiler projections will be NxN, and preferably have it print somewhere just before it might die. That way when it does crash, it will be simpler to figure out why. Two Cents, Sam On Mon, Apr 11, 2011 at 8:11 PM, Stephen Skory
wrote:Hi all,
I just spent some time trying to diagnose a segfault when the HaloProfiler was trying to make projections of the haloes. The problem was in making the FixedResolutionBuffer, the image it was trying to make was 16K by 16K, which cannot fit in any normal machine's memory. I think this is because I am looking at a zoom-in simulation of a smallish cosmological size, with high resolution in the region of interest. The default projection width in the HaloProfiler is 8 Mpc, so I had a big numerator and a small denominator.
What do we think about changing this default to some multiple of the halo maximum radius? I think any constant value will make problems.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org