Remove redundant and erroneous standard_name to LBFC/STASH PP save rules.#190
Conversation
|
I've spoken with @marqh and we've agreed that it be nice to keep the LBFC mappings. Would that still solve your problem? |
|
Okay, that works for me. I've checked the source AQUM FF and all PP-fields with a stash code of 2 have an LBFC = 56, and all PP-fields with a stash code of 3 have an LBFC = 57. Excellent spot @rhattersley! Otherwise I would have lost the LBFC on saving. I'll resubmit the PR 😃 |
|
Do the tests, extests, doctests, etc. all pass already? (Oh, for a working Travis-CI config ;-)) |
|
Yes, yes and yes. Although, there are (I assume) pre-existing failures on master for unittests and extests. A fresh branch cut from upstream/master has a These are both image differences. |
You have to be careful which version of Cartopy you run the tests against. And when I say "careful", I probably mean "lucky" as it's not exactly clear which version you should be using. (Oh, for a working Travis setup which would formally capture some of this! ;-)) I've run the tests myself and it's lookin' good, so I'm happy to merge. |
Remove erroneous standard_name to STASH PP save rules.
|
Cartopy v0.4.0? |
Working with AQUM revealed that loading a Fieldsfile with a PP-field of
stash code 2is translated to a cube withstandard_nameofeastward_wind, and that a PP-field ofstash code 3is translated to a cube withstandard_nameofnorthward_wind.On saving such cubes, the PP save rules set/clobber the
LBFCandLBUSER[3](stash section and item) basedonlyon thestandard_nameof the cube:eastward_windit forces56and15201,northward_windit forces57and15202.These PP save rules are clearly wrong. It is not safe to translate from
standard_nametostash code.These save rules have been removed, along with several other such similar rules. All test still pass after removal, so thankfully we don't have current tests that rely on this erroneous behaviour.