Open trexfeathers opened 1 year ago
@matthew-mizielinski has confirmed that data like this currently generates 1 Cube
for each time point, rather than a single Cube
with a time dimension.
It will be problematic for UK Met Office strategy (climate - IPCC) if this misses the 3.11 (October) release.
I believe it is currently possible to construct a hybrid height coordinate that varies over time. What is not possible is to merge multiple 2D cubes with varying orographies together. This would require a substantial change to merge behaviour. I suspect this may be covered by #5375 which has been a particularly stubborn issue to untangle.
I believe it is currently possible to construct a hybrid height coordinate that varies over time. What is not possible is to merge multiple 2D cubes with varying orographies together. This would require a substantial change to merge behaviour. I suspect this may be covered by #5375 which has been a particularly stubborn issue to untangle.
@stephenworsley let us know what you need. If necessary we have a whole team of developers (given the strategic importance of this).
Shout if a discussion on this would be useful -- I'm sure we can come up with a minimal test data set to work with.
@matthew-mizielinski minimal test data would absolutely be appreciated, and yes, I think it would be good to set up a discussion when possible.
One possible idea for resolving the merge issue:
Provide a keyword argument for the merge
method which you can pass the name of an AuxCoord or a tuple of coord names. this tells merge
which coordinates it ought to expand the dimensions of. Further information is likely to be required in the case where multiple dimensions are being added by merge
, perhaps a tuple of dimension names in which to expand for each AuxCoord. This keyword could also be passed down from the load
function.
This approach shouldn't break existing functionality and should allow sufficient controll of the merging process. I expect there may be some attention we would need to give to AuxCoordFactory
s to make sure they behave sensibly during this process since I'm not aware of any other functions which add a dimension to a coordinate that another coordinate is derived from, but I don't expect this to be too much of a problem.
An alternate approach to explore could involve concatenating instead of merging and using the new_axis
utility to expand the dimensions of the orography coordinate appropriately. This ought to be enabled now via #4896, though I'm not sure how this handles derived coordinates.
Some summary points from our offline discussion today (@pp-mo @stephenworsley @matthew-mizielinski )
we investigated a specific usecase which demonstrates the issue here.
We tried loading selected monthly files, e.g.
iris.load(['sep30, 'oct30', 'jan31']) # imaginary monthly files (!)
N.B. we have sample test data to demo this
@matthew-mizielinski said, for his expected usage, it should be easy to identify what data suffers from the "missing merge" like this, and potentially add a specific load keyword as a "hint" (as suggested above), or call into a post-load adjustment utility.
In case (2) we might need to worry about selecting the correct cubes to work with in the 'additional' operation. The general 'load+merge' behaviour can produce multiple cubes where one was expected if there is a small mismatch somewhere : In this case it could be hard to apply the 'additional' operation to the correct subsets. But we can limit the expected results, e.g. only allow it in "load_cubes", where a single cube is expected from applying each provided constraint. Likewise, a user-operated post-merge operation could be specified to work only with "suitable" data expected to produce a single result cube.
( ignoring for now the "better general merge" approach + looking for easy wins )
In general , we can solve merge/concat problems of this nature by
In this case, since we observe that concatenate can combine factories while merge cannot, it seems that (2) is probably easiest
So it looks like, a viable proof-of-concept solution could :
✨ Feature Request
As described in CF conventions
Motivation
From @matthew-mizielinski. Considering how to represent hybrid height over glaciers, where the orography moves/changes over time.
Additional context
@pp-mo expects problems with FF or PP loading, as it would require a specific sequence of merge steps.
Click to expand this section...
``` Please add additional verbose information in this section e.g., references, screenshots, listings etc ```