SciTools / iris

A powerful, format-agnostic, and community-driven Python package for analysing and visualising Earth science data
https://scitools-iris.readthedocs.io/en/stable/
BSD 3-Clause "New" or "Revised" License
624 stars 280 forks source link

BUG: pp field parameters conforming to UM convention for unrotated LAMs #3560

Open cpelley opened 4 years ago

cpelley commented 4 years ago

UM requires LAM's which are not on a rotated pole to be described with bplat=90 bplon=180. Iris will currently set bplon to 0. The recent introduction of UM file metadata checking means that such incorrectly set bplon values will raise an error in the UM.

Our workaround is to override pp fields derived by iris:

https://code.metoffice.gov.uk/trac/ancil/browser/ants/branches/dev/carwynpelley/1169_IRIS_DITCHES_BPLAT_BPLON/lib/ants/fileformats/pp/__init__.py?rev=8607#L207

 207     # Overide bplon as iris doesn not support properly support unrotated pp
 208     # LAMs.  See https://github.com/SciTools/iris/issues/3560
*209     if not ants.utils.cube.is_global(cube):
 210         if x_coord.coord_system == ants.coord_systems.UM_SPHERE.crs:
 211             field.bplon = 180

It would be simple enough to apply a similar change to iris pp generation from cubes by overriding bplon as 180 if the provided field is a LAM with unrotated pole crs.

Background

The convention is that unrotated lams have 180 pole longitude. This way it matches the dumps and matches F03. This is related to the way the UM dump code performs the pole rotation as well as calculating any longitudinal offset of where to place the zero meridian. - Joe Mancell

Internal issue (ANTS workaround): ancil/ticket #1169 Internal issue (F03 update): um/ticket #5305

github-actions[bot] commented 2 years ago

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.

trexfeathers commented 2 years ago

Several stakeholders raised this as needing to be fixed at a recent 'surgery'.

github-actions[bot] commented 1 year ago

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.

github-actions[bot] commented 1 month ago

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.