branded names for tasmin & tasmax

[JamesAnstey]

Daily and monthly tasmin, tasmax share the same branded names but have different cell methods and dimensions. E.g. for tasmin,

                "cmip6_compound_name": [
                    "Amon.tasmin",
                    "day.tasmin"
                ],
                "cell_methods": [
                    "area: mean time: minimum within days time: mean over days",
                    "area: mean time: minimum"
                ],
                "dimensions": [
                    "longitude latitude time4 height2m",
                    "longitude latitude time height2m"
                ]

with branded name tas_tmin-h2m-hxy-u. That is, the label tmin is common to both, but the time processing is different. Similarly for tasmax, with branded name tas_tmax-h2m-hxy-u.

Is a new temporal label needed to distinguish the monthly tasmin/max from the daily ones?

@taylor13 @znichollscr

[taylor13]

Well spotted. Yes, this is a problem. And this could be done by assigning a different temporal label. We also need to handle the similar difference between day.sfcWindmax and Emon.sfcWindmax. In the case of Emon.sfcWindmax, I noticed it also has the wrong time dimension. The time dimension should be "time4", not "time". I'll raise a separate issue to correct that.

I'll think about this a bit more today before suggesting a new label to fix the problem. Further thoughts welcome.

[taylor13]

Just noticed, that "time4" already is assigned to Emon.sfcWindmax, so there is no need to raise an issue about that.

[bethdingley]

(Note to myself, there are South30 versions of some of these that might also need updating)

[JamesAnstey]

Just noticed, that "time4" already is assigned to Emon.sfcWindmax, so there is no need to raise an issue about that.

Yes, from the latest DR airtable backend export (aka the working bases / raw export) the differences for these two variables (in same format as I gave for tasmin, above), both currently assigned branded name sfcWind_tmax-h10m-hxy-u, are:

                "cmip6_compound_name": [
                    "day.sfcWindmax",
                    "Emon.sfcWindmax"
                ],
                "cell_methods": [
                    "area: mean time: maximum",
                    "area: mean time: maximum within days time: mean over days"
                ],
                "dimensions": [
                    "longitude latitude time height10m",
                    "longitude latitude time4 height10m"
                ]        

[taylor13]

For the 3 variables with time4 and "maximum" (Amon.tasmax, Amon.tasmaxSouth30, and Emon.sfcWindmax), I suggest the label "tmxavg", and for the 2 variable with time4 and "minimum" (Amon.tasmin, Amon.tasminSouth30), I suggest the label "tmnavg".

I'm not happy with either because they are pretty long (nb. except for "tclmdc, all the other time labels are 4 characters or fewer), and hard to remember/interpret, but I can't think of anything better. Any other suggestions?

[JamesAnstey]

I'd vote for keeping the "i": tminavg & tmaxavg. The branded names would then be:

tas_tmaxavg-h2m-hxy-u
tas_tminavg-h2m-hxy-u
sfcWind_tmaxavg-h10m-hxy-u

Personally I'd find these easier to remember/read with the "min" and "max" spelled out in the label, which I think makes it clearer how they relate to the daily versions. Also reflects the order of operations implied by cell_methods (take max/min within days, then average the result over all days in a month).

[taylor13]

Yes the ordering was on purpose for the reason you state. And I'm o.k. with including the full "max"/"min" elements even though they do make the temporal labels about twice as long as the other temporal labels. Everyone else o.k. with that?

[taylor13]

I have now updated Table F1 in the branded variables document with the new labels as discussed here.

[bethdingley]

Thanks both. I'm just noting (mostly for myself) that no Airtable update is required here, until we reimport the new branded names

[github-actions]

This issue is stale after 30 days of inactivity.