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

[Britton Smith]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130523/65162927/attachment.htm>