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

[Matthew Turk]

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
>