-
Notifications
You must be signed in to change notification settings - Fork 300
Structured load pseudolevels #2274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structured load pseudolevels #2274
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.