CMORvar 'ts' in table 'Eday' may call for multiple cell methods

[senesis]

This CMORvar is requested, among others, by LS3MIP; hence, I assume that it should, for that purpose, be defined with a cell method 'mean where land' However, it is also requested by other MIPs, in this table, which usually do not call for this cell method

[martinjuckes]

I'll add a new LS3MIP variable ... it will have to have a new name to stay in the table .. so I'll call it "tsland" . It will be in 01.00.21

[martinjuckes]

However ... Karl has raised questions about introducing "tsland" as a new variable label at this stage.

[taylor13]

You are quite right that there could be a conflict not to change the name, but some groups may have already used the name "ts" for the land surface temperature, so that's why I'm reluctant to change the outname. I'm not sure what would be least disruptive at this point.

In CMIP5 we asked for: tos (liquid ocean surface temperature) tslsi (surface temperature of land and sea ice).

In the CMIP6 "Eday" table we ask for: ts (surface temp.) tsland (surface temperature of land-portion of grid cell) tcs (canopy temp.) tsns (snow surface temp.) tgs (bare soil temp.) tr (surface radiative temperature) tsl (temperature of each soil layer) tsn (vertical average of snow cover temp.)

and in the CMIP6 "day" table we ask for: tslsi (surface temperature of land and sea ice)

and in the CMIP6 'Oday" table we ask for: tos (liquid ocean surface temperature)

This seems like overkill. We probably should have pushed back some on those requesting all these, but we didn't, so what to do? We could consider dropping the "tsland" request all together and replacing it with "tslsi" in the "day" table. The two differ only for a relatively few cells along the high-latitude coasts of continents (in winter).

Whatever we do, there will be daily surface temperature variables in the archive that have the "wrong" names (unless no one has yet chosen to save these and everyone is willing to use release 01.00.28 when it is available.

[senesis]

In DR01.00.21, as Martin reported above, LS3MIP actually has requests in table Eday both for CMORvars 'ts' and 'tsland', in the same request variable group LS3MIP-LEday. This is quite fine for CNRM-CERFACS, which uses that version of the DR up to now. IPSL also does.

[taylor13]

@senesis Are you actually writing both of these fields ('ts' and 'tsland') and are you using "ts" as the "altLabel" (or "out_name")? If so, don't you have files that have the same name? Isn't that a problem?

[senesis]

You're right to ask : for the time being, we haven't started any simulation that produces tsland. When they will start, they will, depending on a toggle : i) either fail to start or ii) produce data files which filename uses 'tsland' while containing a variable named 'ts'. This has been designed to cope with the ua7h/ua issue. This does not comply with CMIP6 DRS. Not sure about how IPSL uses dr2xml in this case ( @SebastienDenvil : what is your use of dr2xml's toggle 'use_cmorvar_label_in_filenames' ?)

[senesis]

@taylor13 CNRM will internally discuss hacking its (DR01.00.21 based) workflow in order to produce Eday variable 'tsland' with out_name 'tsland'

[taylor13]

@martinjuckes @senesis @matthew-mizielinski So it appears that IPSL & CNRM won't mind us changing the out_name (altLabel) of tsland from "ts" to "tsland". We probably should also check with GFDL too.

[SebastienDenvil]

@senesis we are using use_cmorvar_label_in_filenames=false. And we are about to start land-hist simulations. As you migt have seen NASA-GISS also published CMIP6 data on ESGF. There are four institutions now and I know GFDL is about to trigger "massive" publication.

[taylor13]

In previous comments, I misidentified the tags used to distinguish the CMOR table variable entry name (or key) from the name that appears in output files and file names. [Different tags are used to distinguish these in the dimensions and those were the ones I used above.] Wherever "altLabel" appeared above, it should be replaced by the phrase "DREQ's MIP variable 'label'" (which also is the "vid" appearing in the DREQ's CMOR variable and which corresponds to CMOR's "out_name"). [The DREQ's CMOR variable "label" corresponds to the CMOR table's "key" or "entry" name of the variable.]

[senesis]

@taylor13 : no problem at CNRM for changing the label used in filenames and inside datafiles for cmorvar tsland (and I use these wording "the label used in filenames and inside datafiles" for avoiding the misidentification problem you refer to just above)

[matthew-mizielinski]

I can't see any problems with this from our perspective.

[martinjuckes]

OK, thanks all .. so the change made in 1.00.28b1 (introducing tsland as a filename label) will be preserved in the full 1.00.28 release.