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.