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