[yt-dev] A "taxonomy" for fields

[j s oishi]

Hi Matt,

If I'm understanding you properly, I am strongly in support of this. My
understanding is that you proposing a hierarchical taxonomy, such that all
data access will now be two layered. Thus one coudl do something like this

dd = pf.h.all_data()

dd['gas','density']
dd['deposited','density']

then below this, 'gas' will resolve to 'enzo' or 'flash' or 'pencil',
performing unit conversions, and something similar for "deposited"? Thus,
it would also be possible to get completely raw, unconverted code units
just by doing

dd["enzo", "Bx"]?

If so, I think this is a great idea. We could also then have a set of
defaults for single-key dict style access, e.g. dd['Density'] would do
something by default. I think this will also make all derived fields work
in any units in a much easier way.

j


On Tue, Oct 15, 2013 at 9:54 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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!
> _______________________________________________
> 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/20131016/951f6cee/attachment.html>