<div dir="ltr"><div class="gmail_extra">Hi Matt</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 9:53 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
There've been three big pushes on adding species fields in a generic<br>
way to yt recently.<br>
<br>
 * Enzo<br>
 * OWLS<br>
 * FIRE<br></blockquote><div><br></div><div>All of which are awesome, by the way!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Britton came up with an idea that I think works quite nicely.  The<br>
field info container is responsible for enumerating a list of species<br>
that it finds, on startup.  Then, when the field plugins are added,<br>
the field plugin looks for all of the fields that it can find that are<br>
related to each species enumerated, and the appropriate<br>
fraction/density/number density fields get added.<br>
<br>
Right now, the field plugin is not created yet, but that is my next<br>
step for this.  What the plugin will do is iterate over all the<br>
species names, try to find the appropriate fields in the<br>
pf.field_aliases, and then appropriately add things.  What this means<br>
is that if the frontend, in setup_fluid_fields, ensures that the<br>
species names are all appended to the species_list, the plugin will<br>
then create all of the appropriate fields.  So if it finds "He_p1" in<br>
the species_list, it will look to see if "He_p1_fraction" exists, then<br>
look for _density, and _number_density, and whichever one it finds it<br>
will use to create derived fields for the others.<br>
<br>
Where this gets a bit messy is in the actual creation of all of the<br>
aliases, which is why I think it's appropriate for it to be a plugin.<br>
Once we have these aliases, we can add on smoothed versions of the<br>
fields.  By basing this on a recognized list of species types, we can<br>
also reduce the number of fields looked for by the plugin system to<br>
just those it knows it ought to make.  And, since we have "species"<br>
objects, we can create those on-demand to use.<br></blockquote><div><br></div><div>Moving these to on-demand would be great. This seems much more sustainable than adding all the fields that could be possible by default.</div>

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

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote></div><br></div></div>