iris
iris copied to clipboard
Incorrect LBLEV in pp save rules for surface fields.
🐛 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:
- Use iris to load a surface field (e.g. SST or orography)
- Save the surface field as pp file.
- Inspect lookup header with e.g.
mule-pumf --headers-only filename.pp | grep 'lblev'
Expected behaviour
LBLEV value of 9999 for surface fields.
Environment
- Iris Version: 2.3
@hdyson Thanks for taking the time to report this, much appreciated.
We're in the process of finalising iris
3.0.0rc0, and a fix for this might or might not make it across the line, given where we're at.
Note that, we won't be releasing a back-ported patch for iris
2.x, so this fix will only be available in python
3+ and iris
>=3
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:
- Re-open this issue, if you have sufficient permissions, or
- Add a comment pinging
@SciTools/iris-devs
who will re-open on your behalf.
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.