Incorrect LBLEV in pp save rules for surface fields. #3820
Comments
|
@hdyson Thanks for taking the time to report this, much appreciated. We're in the process of finalising Note that, we won't be releasing a back-ported patch for |
|
In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity. If this issue is still important to you, then please comment on this issue and the stale label will be removed. Otherwise this issue will be automatically closed in 28 days time. |
|
This stale issue has been automatically closed due to a lack of community activity. If you still care about this issue, then please either:
|
|
Would it be possible for this issue to be re-opened, please? @SciTools/iris-devs |
|
I believe this is one on @tkknight's list for allocating time to fix. |
|
In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity. If this issue is still important to you, then please comment on this issue and the stale label will be removed. Otherwise this issue will be automatically closed in 28 days time. |
馃悰 Bug Report
Iris pp save rules result in a LBLEV of 0 for a surface field (i.e. all the non-zero values are gated behind a check for a vertical coordinate: https://github.com/SciTools/iris/blob/master/lib/iris/fileformats/pp_save_rules.py#L653 ). F03, however, specifies a value of 9999 for surface fields: https://code.metoffice.gov.uk/doc/um/latest/papers/umdp_F03.pdf#page=27 In Ants, we rely on the pp save rules to set this value as we translate a cube into mule fields for saving ancillaries. We will put in a workaround in Ants to set this ourselves for an immediate fix, but it would be good if this could be fixed upstream.
How To Reproduce
Steps to reproduce the behaviour:
mule-pumf --headers-only filename.pp | grep 'lblev'Expected behaviour
LBLEV value of 9999 for surface fields.
Environment
The text was updated successfully, but these errors were encountered: