Hi Matt

On Mon, Apr 7, 2014 at 9:53 AM, Matthew Turk <matthewturk@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@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org