[yt-dev] (HaloProfiler) Best way to handle Dark_Matter_Density?

[Britton Smith]

Hi Matt,

I think so, yes.  Dark_Matter_Density as named exactly like that is an Enzo
field that was written directly to disk by Enzo and includes star
particles.  It should be identical in value to particle_density, but it's
probably better to use particle_density as it would be less confusing.

Britton


On Thu, May 23, 2013 at 3:47 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Britton,
>
> In that case, wouldn't it make sense instead of using
> Dark_Matter_Density, to use the full particle density, which is
> particle_density ?  That would also (for instance) include star
> particles.
>
> -Matt
>
> On Thu, May 23, 2013 at 3:26 PM, Britton Smith <brittonsmith at gmail.com>
> wrote:
> > Ok, I see what the issue is.  The ActualOverdensity field, which is used
> to
> > calculate virial quantities, requires the TotalMassMsun field, which adds
> > the density and dark_mater_densities.  So, yeah, the Dark_Matter_Density
> > field is getting used there.
> >
> >
> > On Thu, May 23, 2013 at 2:57 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> >>
> >> Hi Britton and Cameron,
> >>
> >> Okay, perhaps a D_M_D that's universal is the way to go.  Here's the
> >> script that threw the D_M_D error on a FLASH dataset:
> >>
> >> http://paste.yt-project.org/show/3499/
> >>
> >> Does this call upon standard_fields at all?  Or is there somewhere
> >> else it might, perhaps in ActualOverdensity?
> >>
> >> -Matt
> >>
> >> On Thu, May 23, 2013 at 2:49 PM, Britton Smith <brittonsmith at gmail.com>
> >> wrote:
> >> > I like defining a new yt field that is dark matter density for all
> >> > frontends.  I also think it would be a good idea to be checking
> against
> >> > the
> >> > available field list when adding fields since dark matter density is
> >> > just
> >> > one of many fields that may only be defined by one of a few codes.
>  I'm
> >> > curious to know if anyone is using the standard_fields defined in the
> >> > HaloProfiler.  This was an attempt to recreate the functionality of an
> >> > old
> >> > Enzo radial profiling tool called enzo_anyl that never really got
> >> > finished.
> >> > Is this being used now?  If so, I'd be interested to know how and how
> we
> >> > can
> >> > make it more usable.
> >> >
> >> > Britton
> >> >
> >> >
> >> > On Thu, May 23, 2013 at 1:53 PM, Cameron Hummels <chummels at gmail.com>
> >> > wrote:
> >> >>
> >> >> I'd be inclined to change the field we examine from
> Dark_Matter_Density
> >> >> to
> >> >> a different field that is defined by yt.  It's easier than creating a
> >> >> Dark_Matter_Density for each frontend.
> >> >>
> >> >> Cameron
> >> >>
> >> >>
> >> >> On Thu, May 23, 2013 at 10:26 AM, Matthew Turk <
> matthewturk at gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Hi all,
> >> >>>
> >> >>> This came up after a discussion on #yt; I've CC'd the person who
> >> >>> brought this up.
> >> >>>
> >> >>> In the halo profiler, there's a list of standard fields.  In this we
> >> >>> have Dark_Matter_Density, which to my understanding is an
> >> >>> Enzo-specific field.  It's not the same as the CIC_Deposit3 (defined
> >> >>> in yt) field that does a similar thing, but it's very similar.  I am
> >> >>> wondering what the best way to handle this, particularly since any
> >> >>> frontend that wants to use the HaloProfiler will need this field
> >> >>> unless standard_fields is amended not to include it.
> >> >>>
> >> >>> Should we:
> >> >>>
> >> >>>  * Define a Dark_Matter_Density for each frontend?
> >> >>>  * Define a universal field that defines Dark_Matter_Density
> globally?
> >> >>>  * Change the field we examine from Dark_Matter_Density to a
> different
> >> >>> field that is defined by yt, not assumed to be in the output file?
> >> >>>  * Should we check if every standard_field is in the output
> >> >>> (pf.h.derived_field_list) before adding it?
> >> >>>
> >> >>> Britton, I think you might have the best idea of how to fix this,
> but
> >> >>> Sam Leitner I know has been working on using Halo Profiler on other
> >> >>> datasets.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> Matt
> >> >>>
> >> >>> PS Please hit "reply all" so that Meghann, who reported this in #yt,
> >> >>> sees the response.
> >> >>> _______________________________________________
> >> >>> yt-dev mailing list
> >> >>> yt-dev at lists.spacepope.org
> >> >>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Cameron Hummels
> >> >> Postdoctoral Researcher
> >> >> Steward Observatory
> >> >> University of Arizona
> >> >> http://chummels.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
> >
> >
> >
> > _______________________________________________
> > 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/20130523/c855a9bd/attachment.htm>