Conversation
pp-mo
force-pushed
the
structured_load_api_pseudolevels
branch
from
efeab2b to
1d8954f
Compare
I agree, this seems like a pretty edgy edge case to me |
| results = iris.load(file) | ||
| expected = CubeList(flds).merge() | ||
|
|
||
| # NOTE: this problem is now fixed : Structured load gives the same answer. |
There was a problem hiding this comment.
do we need to hold onto these notes explicitly in the source?
I'd have thought that this is what the git history is for
may we remove this?
There was a problem hiding this comment.
The problem is that the version
Ok, I guess it is immortalised in the commit 33eb8d8
(though that won't be appearing in the main log).
I will tidy this up...
There was a problem hiding this comment.
following an off line discussion about this I am persuaded to leave this in for now, as this commit will be squished so it will never be in teh history.
the handling of pseudo levels may require more effort, so these reminders may prove useful
2 participants
This should allow structured-loading to work with most files where pseudo-levels are used.
If 'ordinary' levels (LBLEV values) and 'pseudo-levels' (LBUSER5) both vary at once, this rather inelegant solution could still have problems, potentially producing 2 vertical coordinates.
But only if that occurs within a phenomenon, which we think is probably not realistic ?
Note:
Possibly needs tidying a bit further.
? Should I remove that commented-out 'fixed' failure code in
tests.integration.fast_load.MixinProblemCases.test_FAIL_pseudo_levels?I have left it, assuming it is a useful statement of what the key problem actually is.