Added name+units->lbfc definitions to replace Iris rules matching by name alone.

[pp-mo]

Added several new mappings to associate LBFC values with specific CF name+units. This is to support the replacement of the old Iris text rules which set LBFC based only on cube names. See https://github.com/SciTools/iris/pull/965

NOTE: a potential problem -- I was unable to use my own id to assign editor/ownership, as this does not seem to be supported by metarelate at present, so the new rules are credited to marqh. If this (or anything else) needs to be amended, it may be necessary to revise the Iris pull request to ensure that um_cf_map.py exactly matches the latest output from iris-code-generators.

Stop press: user-id problem can be fixed (see later comment) todo:

• [x] re-enter with correct user id
• [x] check all-same
• [x] push here

[pp-mo]

NOTE: a potential problem -- I was unable to use my own id ...

@marqh pointed out that this was because I missed a section of the "getting started" page. I will fix this shortly (created todo list in task) -- closing until

[pp-mo]

Redone with correct editor ids. Reopened.

[pp-mo]

Scanning the database files, I believe there is still a problem with this. Somehow, I managed to create two near-identical mappings -- but one of them has reversible:True. Closing until sorted

[pp-mo]

Somehow, I managed to create two near-identical mappings

No, it was an (unintentional) edit -- the 'extra' mapping is an earlier version which got modified (i.e. replaced) So this is ok after all, I believe.

Reopening again !

[marqh]

I am content to merge these, but I would like to question why all the mapping are: invertible = False

Are there other mappings which would conflict if these were invertible?

Are they known not to invert or not known to invert?

[marqh]

on reflection, I am worried by the relations eastward_wind ~ lbfc56 northward_wind ~ lbcf57

as 56 is described: Westerly component of wind u and 57: Southerly component of wind v

please may these be set to 'broken' pending further investigation?

[pp-mo]

I am content to merge these, but I would like to question why all the mapping are: invertible = False

I simply thought that inversion is not intrinsically a safe process, as it is logically a many-to-one relation e.g. you can happily have both of

• "cf(name=NAME, units=UNITS) --> um(lbfc=A)"
• "cf(name=NAME_DIFFERENT, units=UNITS2) --> um(lbfc=A)"

I did not consider whether the reverse inference would be valid in specific cases (where there is no conflict) : I just made all the new mappings non-invertible.

I suppose you can in principle deduce name from LBFC alone in those specific cases where there is only one known type of data that can have that LBFC. But practically I doubt whether this would ever be "safe", as the deduction is only conditionally safe according to latest information -- i.e. the mappings must reflect the latest usage at all times : If someone creates a new type of data output and assigns it an existing LBFC value, this will break the logic until the conflicting case is added to our known mappings.

[pp-mo]

on reflection, I am worried by the relations eastward_wind ~ lbfc56 northward_wind ~ lbcf57 ... please may these be set to 'broken' pending further investigation?

Searching with the metarelate editor for lbfc=56 brings up a list

• cf -> um mapping(units:m s-1; type:Field; standard_name:eastward_wind; )
• cf -> um mapping(units:m s-1; type:Field; standard_name:tendency_of_eastward_wind_due_to_diffusion; )
• cf -> um mapping(units:m s-1; type:Field; standard_name:tendency_of_eastward_wind; )

The one I created is the top one, but the others pre-date + appear to make the same assumption about the 'definition' of this fieldcode. So I think we should run with this + raise this problem as a separate issue.

[marqh]

10 will now handle um:lbfc 56/57 as the consideration is wider than the scope of this pull request

good to merge