cmip6 - cmip6Plus table: a non bijective case

[treerink]

I encounter one case in the cmip6 - cmip6Plus conversion table and I wondered whether this is correct:

| CMIP6 table | CMIP6 variable | CMIP6Plus Table | CMIP6Plus  variable |
| LImon       | sbl            | LImon           | sbl                 |
| Amon        | sbl            | LImon           | sbl                 |

which menas two cmip6 combinations point to one cmip6Plus combination. Thus a non bijective case.

Thus just reporting, I had to filter this out in our chain based on this table.

[taylor13]

in CMIP6 these two differ in that the Amon version of sbl includes sublimation over sea ice (as well as land), so no "masking" has been applied. This probably should be put in the CMIP6Plus APmon table, but someone should confirm this.

[durack1]

@treerink you may have reported the first issue with these updated tables - thanks for checking.

The CVs Task Team (co-lead by @taylor13) is working on updates to many of these MIP components, so glad we have caught this single issue, and if you find any more, please create an additional issue so we can make sure such inconsistencies are resolved through iteration

[matthew-mizielinski]

When constructing the new tables I was trying to automatically assign variables to tables based on their properties. The two cases here differ in their cell_methods; in CMIP6 LImon/sbl is land masked while Amon/sbl is not. I felt that as LImon/sbl is a subset of Amon/sbl (I think this is true) then there was no clear requirement to create two entries.

I've just added a note to the conversion table page indicating this difference. In an ideal world I would confirm this for all variables, but I may not have time to get to this soon.

@treerink, if this doesn't cover your query please re-open this issue.

[treerink]

Thanks. What I can add: this is the only non bijective case in the conversion table. For my software, I fixed this case downstream. Maybe others will face it as well.

[treerink]

Actually we want CMIP6Plus equivalents for both CMIP6 variables: LImon sbl & Amon sbl which is now not possible.

Would this be a suggestion:

| CMIP6 table | CMIP6 variable | CMIP6Plus Table | CMIP6Plus  variable |
| LImon       | sbl            | LImon           | sbl                 |
| Amon        | sbl            | APmon           | sbl                 |

[treerink]

It seems I can't reopen myself ...

[matthew-mizielinski]

I'm not keen on adding sbl to the APmon table as we made a distinct attempt to avoid mixing realms across tables when constructing them.

To my mind the missing variable would be calculated as Afx.sftlf * LImon.sbl -- is there a good reason not to ask users to do this?

If we were to proceed down the route of adding a new variable I think it would have to be a separate name in the same table (e.g. sblLand) as I don't see a clean way to adding this another way.

@durack1 -- thoughts?

[taylor13]

In addition to sbl-Amon (no masking) and sbl-LImon (where land), there is also sblIs-LImon (where ice-sheet). I agree that we should decide which two of these three (or perhaps which one of these three) to request in the future. As @matthew-mizielinski points out, they can be related by the fraction of a grid cell occupied at the surface by frozen water (ice, snow). I would note that in the case of sbl "where ice-sheet", we couldn't exactly calculate the value given sbl-Amon and sftlf alone, since portions of grid cell might be covered by snow that sublimates and would contribute to sbl-Amon, but not the sublimation over ice-sheet.

By the way, with branded variables (which will be used in CMIP7), these could all appear in a single table and share the same root name (sbl), since their full brand names differ: sbl_tavg-u-hxy-u, sbl_tavg-u-hxy-lnd, and sbl_tavg-u-hxy-is. The last element indicates masking (or not).

[durack1]

If we were to proceed down the route of adding a new variable I think it would have to be a separate name in the same table (e.g. sblLand) as I don't see a clean way to adding this another way.

I agree with your thinking @matthew-mizielinski. The logic imposed in this repo was to "fix" inconsistencies introduced in CMIP6, but as discussed above, nuances exist. @taylor13 I note that for most cases, the atmos, seaIce and iceSheet (Greenland or Antarctica) are variables which do not share a surface grid, and so the logic defined by @matthew-mizielinski makes sense to me, in addition to a second entry for ice sheets (maybe we have to duplicate this too?)

[taylor13]

Even sbl "where land" (i.e., sbl-LImon) multiplied by land fraction is not exactly equal to sbl with no masking (i.e., sbl-Amon) because in general a grid cell can span both ice (or snow) on land and also sea ice regions. For example, a cell that spans ice-free land and sea ice will have non-zero sbl when not masked and zero sbl when "where land" is specified. The actual native grids are in general irrelevant. In short, Afx.sftlf * LImon.sbl does not everywhere equal Amon.sbl.

That being said, the equation will hold over some grid cells, and only when doing water budget studies (or ice mass changes), will the differences likely matter.