[yt-dev] Species fields

Sam Skillman samskillman at gmail.com
Mon Apr 7 10:42:11 PDT 2014


Hi Matt

On Mon, Apr 7, 2014 at 9:53 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all,
>
> There've been three big pushes on adding species fields in a generic
> way to yt recently.
>
>  * Enzo
>  * OWLS
>  * FIRE
>

All of which are awesome, by the way!


>
> Britton came up with an idea that I think works quite nicely.  The
> field info container is responsible for enumerating a list of species
> that it finds, on startup.  Then, when the field plugins are added,
> the field plugin looks for all of the fields that it can find that are
> related to each species enumerated, and the appropriate
> fraction/density/number density fields get added.
>
> Right now, the field plugin is not created yet, but that is my next
> step for this.  What the plugin will do is iterate over all the
> species names, try to find the appropriate fields in the
> pf.field_aliases, and then appropriately add things.  What this means
> is that if the frontend, in setup_fluid_fields, ensures that the
> species names are all appended to the species_list, the plugin will
> then create all of the appropriate fields.  So if it finds "He_p1" in
> the species_list, it will look to see if "He_p1_fraction" exists, then
> look for _density, and _number_density, and whichever one it finds it
> will use to create derived fields for the others.
>
> Where this gets a bit messy is in the actual creation of all of the
> aliases, which is why I think it's appropriate for it to be a plugin.
> Once we have these aliases, we can add on smoothed versions of the
> fields.  By basing this on a recognized list of species types, we can
> also reduce the number of fields looked for by the plugin system to
> just those it knows it ought to make.  And, since we have "species"
> objects, we can create those on-demand to use.
>

Moving these to on-demand would be great. This seems much more sustainable
than adding all the fields that could be possible by default.


>
> Gabe did some work with this for the OWLS datasets, where he created
> all of the ionization states based on the density fields.  What I'm
> suggesting here is that with this plugin, he could create *just* the
> ionization states in density or fraction form, and then the plugin
> would create the alternates *and* all the smoothed fields.
>
> This does open up the question of what to do about *neutral* species,
> as distinct from *total nuclei*, which the natural representation of
> is somewhat degenerate.  Britton opted for a %s_nuclei_%s naming
> scheme, where Gabe opted to specify Symbol_%s, with explicit p0
> suffices for those neutral fractions.  Originally, I wanted _p0, and I
> think I still do, but I recognize not everyone agrees.
>
> The other item Gabe worked on, which I promised I'd write up into a
> YTEP, was changing the particle deposition types.  This will be a
> forthcoming email, out of scope for this one.
>
> Any feedback from anyone?  I intend to consolidate all of the
> detection shortly and make it into a plugin, but I'll need help,
> especially from Gabe on the OWLS part of this.
>

I think this sounds great. Perhaps we could even provide finder functions
that when called could return semi-organized listings of available fields.
 For example, have it bunch the fields into io/in-memory, different
species, derived fields (from 2 or more original fields), etc.  Anyways,
all of this sounds good to me.


>
> -Matt
> _______________________________________________
> 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/20140407/927726df/attachment.html>


More information about the yt-dev mailing list