[yt-dev] A "taxonomy" for fields

Matthew Turk matthewturk at gmail.com
Tue Oct 15 18:54:30 PDT 2013


Hi all,

Nathan and I have been doing some work on units recently, and how to
handle on-disk fields, derived fields, and so on came up a little bit.

I speculated a little bit about this and was wondering if this is a
good enough idea to propose a modification to YTEP-0003:

https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html

Basically, what about having a taxonomy of fields?  What this would be:

 * An enumeration of the fields that yt may call upon that it may
expect to find in a dataset.
 * Explicit translations, rather than de facto/implicit translations.
 * Calling on-disk fields by a fluid name other than "gas"

So what I mean here is, right now we have support for multiple
"fluids", but the only ones we have are "gas" and "deposit".  I'm
proposing that code frontends:

 * Define their own fluid types that mean, fields on disk.  These will
by default be in code units.  So you could access
dataobj["enzo","Density"] and it will return a YTArray by default in
code units that is the "Density" field.
 * Frontends provide translations of these to yt-specific fields.
This would mean, for the example above, ["gas","density"].  (Note that
by default the search process would be "gas", then "enzo" in this
case, so you could still ask for "Density" but it would default to a
unitful code-unit array, and yt knows how to convert all of that.)
 * Somewhere (YTEP?), enumerate the fields that yt knows how to manage
and operate on.  This way we can also more easily detect derived
fields, and indicate to frontend developers how to hook their code up
to yt.

In the unit_refactor I've started working toward this by adding:

field_info.add_output_field( ... )
field_info.alias( ... )

to set these things up a bit more clearly.  It also devises a
different way of doing field plugins, to make it more deliberate and
reduce a LOT of the nastiness of the process.

So what I'm looking for feedback on:

 * What about new fluid type for on-disk datasets?
 * What about enumerating field names that yt knows about?

-Matt

PS I know 3.0alpha4 was scheduled for yesterday.  I was a bit
jet-lagged, but I'll put out what I can as soon as I can for a release
announcement.  But, the recent changes are in yt_analysis/yt now!



More information about the yt-dev mailing list