"Ideally", involves "second guessing" what cube groups merge and/or concatenate will choose to make,
or what they would choose given the proposed coord equalisation process.
This is clearly a bit tricky.
The target solution should be:
- adequate for 80% key test cases (TBD)
- capable of quick description for user docs (fits into docstring of an "equalisation operation") (1)
- reasonable to implement
(1)
we have the idea that "equalise_cubes" is going to stop detailing/describing all available the equalise operations,
though it may still list them.
E.G. they will probably be described elsewhere as separate functions in a specific submodule of iris.utils
"Ideally", involves "second guessing" what cube groups merge and/or concatenate will choose to make,
or what they would choose given the proposed coord equalisation process.
This is clearly a bit tricky.
The target solution should be:
(1)
we have the idea that "equalise_cubes" is going to stop detailing/describing all available the equalise operations,
though it may still list them.
E.G. they will probably be described elsewhere as separate functions in a specific submodule of iris.utils