[yt-dev] Thoughts on the future of units and fields

[Matthew Turk]

Hi all,

I promised an email about this last Friday, and I'm now finally
getting around to it.  Hooray?

One common problem that comes up pretty often is the issue of how
fields on-disk are represented, how the units and whatnot get passed
into the frontends, and then how to change this.  As an example, it
can be really quite tricky to tell yt that, no, hey, turns out, *this*
version of the data has *different* units than the *other* version, or
something.  We special case these in the frontends in almost all cases
-- which requires touching the yt source code, rather than something
that can be passed in.

I'd like to propose a handful of things, which may or may not be reasonable.

 * fields.py currently uses tuples of values hanging off a class
definition, which are rather undocumented and also oddly mixed in
mutability and immutability.  I'm still trying to think through the
best way to improve this.  But, the simplest problem that *needs* to
be fixed is that this is fragile to changing the arguments.  We can't
add new attributes without changing everything.  Same for getting rid
of arguments.
 * to_cgs should instead be to_natural in almost all cases.  Setting
the "natural" units of a dataset should be possible.  This would
enable doing things like code-as-natural, mks-as-natural, etc.  I
*think* it is straightforward, having looked at the code, but it's
also slightly out of my depth in the unit system.
 * We should be able to standardize unit *override*.  We should, at
the very least, be able to pass in a dict that maps field tuples to
on-disk units, which would override whatever is in fields.py.
 * Having a method of dynamically defining code_something units would
be very useful; this has shown up in odd ways with things like
particle units in octree codes where the code_length is differently
defined for different fields.  Having a dynamic code_* definition
would ease this, rather than mandating that there are N code_ fields,
of names blah blah blah.

OK, there are my thoughts.  Longer term thoughts could be to change
our field definitions to all be sympy expressions, which could be
simplified, but that's for another day.

-Matt