Skip to content

Conversation

@pp-mo
Copy link
Member

@pp-mo pp-mo commented Sep 6, 2019

Aims to address #153

@pp-mo pp-mo changed the title Support unknown phenomena with a 'GRIB_CODING' attribute; tests passing. Support unknown phenomena with 'GRIB_CODING' attribute Sep 6, 2019
@pp-mo pp-mo changed the title Support unknown phenomena with 'GRIB_CODING' attribute Label unknown phenomena with 'GRIB_CODING' attribute Sep 6, 2019
@pp-mo pp-mo changed the title Label unknown phenomena with 'GRIB_CODING' attribute Label unknown phenomena with a 'GRIB_CODING' attribute Sep 6, 2019
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.7%) to 85.708% when pulling df54c96 on pp-mo:param_coding into 00a72eb on SciTools:master.

@coveralls
Copy link

coveralls commented Sep 6, 2019

Coverage Status

Coverage increased (+0.4%) to 86.777% when pulling ff2bc89 on pp-mo:param_coding into 2cf099a on SciTools:master.

@pp-mo
Copy link
Member Author

pp-mo commented Sep 13, 2019

@ehogan I think you might be interested in this ?

@pp-mo
Copy link
Member Author

pp-mo commented Sep 13, 2019

Good to go now AFAIK !

@bjlittle @lbdreyer a distraction from Iris, but can you summon any interest in this ?

@pp-mo
Copy link
Member Author

pp-mo commented Sep 13, 2019

Some practical notes:

This is supposed to work just like the "STASH" attribute that Iris uses for loading + saving UM files into Iris (i.e. fieldsfiles or PP).
However.. when loading UM files, you always get a "STASH" attribute,
but when loading grib data, you will now only get a "GRIB_CODING" attribute when the phenomenon is unrecognised.

This is intended to avoid confusing existing loading code.
However, it will lead to results changing when we add new phenomenon codings. So that may not be ideal.

A safer way, more consistent with general Iris usage, would be ...

  • use a FUTURE type flag to enable GRIB_CODING attributes for all loads
  • and deprecate current usage
  • tidy up at a major release

But that's overkill for iris-grib,
isn't it ... ???

@pp-mo
Copy link
Member Author

pp-mo commented Sep 16, 2019

From discussion with @bjlittle ...

A safer way, ... use a FUTURE type flag
that's overkill for iris-grib, isn't it ... ???

Two points here :

  • (1) the above fuss is strictly not required, because we don't have a version 1.0 yet
  • (2) the existing proposal is still a bit flaky + not that safe for some reasons ...
    • adding a cf-translation for a code means it will stop loading with a grib-coding attribute
    • unlike Iris-STASH-attribute, the control attribute does not override on save, but is only honoured when a cf-translation is absent.

Given (1), we're probably better off implementing a mechanism identical to the iris-STASH-attribute,
as this is easier to explain + understand. That means ...

  • on load, all data will have the new attribute
  • on save, the presence of a stash-coding attribute will set the encoding + ignore any cf-translation

I'll just run off + implement that ...
( re- marking this "WIP" while I do that ... )

@pp-mo
Copy link
Member Author

pp-mo commented Nov 27, 2019

Update :
Just rebased
Still needs some test changes/fixes to accommodate the recent policy change...

@pp-mo pp-mo force-pushed the param_coding branch 2 times, most recently from 9765acc to 7ee59c5 Compare November 27, 2019 17:09
@pp-mo
Copy link
Member Author

pp-mo commented Nov 27, 2019

Thanks @lbdreyer
Adopted revised policy + fixed the PR.
Now good to go I think, please review ...

discipline, category, number = 255, 255, 255
identity_found = False

# First, see if we can find and interpret a 'GRIB_CODING' attribute.
Copy link
Member

@lbdreyer lbdreyer Nov 29, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced its a good idea to interpret the "GRIB_CODING" attribute first.

I think the standard_name/long_name should take precedence when determining the correct discipline/category/number as that it is the primary means we have of identifying a cube.

This reliance on GRIB_CODING means in future we have to take extra care with attributes and I don't want that requirement.

For example someone could take a copy of a cube, update the data array, and only update the name, then save it out as a cube. This would still have it out as the old discipline/category/number

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From an offline discussion with @pp-mo, it turns out that this is how the STASH attribute is handled ⚠️ ⚠️ ⚠️

In which case, my preference is for matching that behaviour so I'm happy with this as it is.

Copy link
Member

@lbdreyer lbdreyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more review comments, including some python 2 code that needs dropping

And as discussed offline, round-trip testing may be helpful

import collections
from collections import namedtuple
import re
import six
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file needs resolving merge conflicts

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

# importing anything else.
import iris_grib.tests as tests

import six
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

six should be removed now Py 2 has been dropped

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs removing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I got confused + thought I'd done this. Will fix.

# licensing details.
"""Unit tests for `iris_grib.grib_save_rules.set_discipline_and_parameter`."""
from __future__ import (absolute_import, division, print_function)
from six.moves import (filter, input, map, range, zip) # noqa
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer need the Python 2 support

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. Nicer !

return _CF_GRIB2_TABLE[(standard_name, long_name)]


class GribCode(namedtuple('GribCode',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GRIB is an acronym so you could argue that this should be GRIBCode

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried 'GRIBcode'. Is that ok ?

@lbdreyer
Copy link
Member

lbdreyer commented Dec 2, 2019

After more thinking and discussing, I propose the following format for the cube attribute:

attributes  = {
    'GRIB_PARAM': 'GRIB2:d001c001n001'}

Where GRIB_PARAM is the key, and the value follows the format GRIB?:d???c???n???

@pp-mo
Copy link
Member Author

pp-mo commented Dec 2, 2019

Rebased to fix.
Other requested changes coming ...

@pp-mo
Copy link
Member Author

pp-mo commented Dec 2, 2019

Thanks @lbdreyer.
Should be good now ?
Note that I thought of + added an extra test.

return _CF_GRIB2_TABLE[(standard_name, long_name)]


class GRIBcode(namedtuple('GRIBcode',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid I don't like GRIBcode I read that as GRI Bcode

Maybe it is best to go back to GribCode if you don't like GRIBCode
Wikipedia's article on camel links to an paper that points out a run of uppercase letters can cause problems which I think we're having with GRIBCode. So I don't think we have to strictly treat acronyms as all capital letters.

Copy link
Member Author

@pp-mo pp-mo Dec 2, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you don't like GRIBCode

I read as "GRIBC ode". It seems to be the opposite problem to your "GRI Bcode" !
But I'll go with yours, it's not an awful problem.

@pp-mo
Copy link
Member Author

pp-mo commented Dec 2, 2019

Hi @lbdreyer.
Changed as requested.
Can we go with this ?

@lbdreyer
Copy link
Member

lbdreyer commented Dec 3, 2019

Hi @lbdreyer.
Changed as requested.
Can we go with this ?

Hi @pp-mo

Yep this is almost good to go. Just need you to get rid of the six import

@pp-mo
Copy link
Member Author

pp-mo commented Dec 3, 2019

here it is, @lbdreyer !
Sorry for another mistake + delay.

@lbdreyer
Copy link
Member

lbdreyer commented Dec 4, 2019

🎉 six is now removed 🎉

I'll merge this in ....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants