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
- 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 codelength 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.