[Yt-dev] HaloProfiler vs. enzo_anyl

[Britton Smith]

Hi Matt,

Thanks for checking into this.  This looks like another thing that could be
checked off our list with a code sprint.  I won't be available for that this
week, but could do it next week.

Here are some questions that I think we need to consider.  While we are not
only looking to provide full coverage for all of enzo_anyl's functionality
so we can mothball it, we should also be thinking about things that could be
improved from enzo_anyl.

1. The density units in enzo_anyl are Msun/Mpc^3.  Do we want to keep
these?  I always converted to cgs back when I used enzo_anyl.

2. Stuff like clumping factors and velocity dispersion will require some
additional functionality out of profiles.  It's currently not easy to get
means and standard deviations in individual bins for profiles.  Does anyone
have any idea how difficult it would be to implement this functionality?

I'm sure there are other things we should think about, but I don't have
enough caffeine in my brain to think of them all.

Britton

On Mon, Apr 18, 2011 at 3:38 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all,
>
> I've updated the list of fields:
>
> http://paste.enzotools.org/show/1583/
>
> Some of these fields I don't know how to set up, but we either have
> most or could directly implement them.  The tricky ones are the ones
> that separate out DM/Star particles, which will require a bit more
> touching of the data.  (That's where most of the "NotImplemented"
> comes from.)  Some of these fields we even had before -- like the
> inertial tensor -- and I think some people have a couple of these
> fields already in private repos.  I pulled out all the disk analysis
> fields.
>
> It would probably be the work of an afternoon to wrap up replicating
> all the functionality and putting it into a "yt analyze" command.
>
> -Matt
>
> On Thu, Apr 14, 2011 at 2:54 PM, John Wise <jwise at astro.princeton.edu>
> wrote:
> >>> I agree with this.  After thinking about it and reading Britton's
> response, I think #3 would be the best option.  A possible solution to
> calculating the cooling time post-runtime would be to add a command line
> option to Enzo that adds the CoolingTime to the data, similar to the
> potential field output command line option.  The catch is that you'd have to
> make sure that you use the same version as you ran the simulation.
> >>
> >> I agree, that would be great.  Do you think this is straightforward?
> >> I have looked before at the WritePotential stuff, but I'm not sure I'm
> >> the best person to add this.
> >
> > I could add this pretty quickly.  I'll try to do it today.
> >
> > John
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110418/4895cc8a/attachment.html>