How to include data that's not an exact match to a CMIP variable?

[alisonwaterfall]

We would like to submit some CCI land surface temperature datasets to Obs4mips, but the data are monthly means of data measured at specific local times of day (e.g. 6am/6pm, or for ascending/descending node) data. For LST, the time of day will be significant, so these won't directly map to CMIP monthly mean data. Is there a way to handle this?

Some alternative approaches I can think of might be:

• add an additional frequency description (e.g. “monthly mean, sampled at specified (local) time point within each day.”)
• add bespoke variables e.g. tr_asc and tr_desc (for ascending/descending node data), although these would then not match a CMIP variable.
• Or potentially a third option is perhaps to just make it clear in the source ID’s that it refers to a given time – but my concern there might be people just mapping naively between CMIP variables and assuming it’s a true monthly mean and using the data incorrectly.

Additionally, we think the data best maps to the 'tr' (surface radiative temperature) variable in CMIP, but this is not currently included in any of the obs4mips tables, so we would need to add new variable terms to the Obs4MIPs tables.

[taylor13]

The CMIP variable "surface_temperature" in some models, at least, represents the temperature at which it radiates. For careful studies of energy balance, models also report their upwelling longwave radiation at the surface, which can be trivially converted to a radiating temperature. For observations, I think you could use "surface_temperature" as the standard name and provide additional guidance on how that temperature was derived from CCI measurements.

As for the time-samples that make up the monthly means, are they simultaneously obtained or are they obtained at different universal times, depending on longitude and latitude?

[gleckler1]

@alisonwaterfall @taylor13 The expectation with any product made available via obs4MIPs is that there is some pathway for it to be comparable to existing CMIP output. I am scratching my head thinking about what degree a fair comparison can be made with the monthly mean product described above. Karl's question regarding time-sampling is key. I think the following discussion on the GERB product is relevant (https://ceres.larc.nasa.gov/documents/STM/2018-09/ERBgerb_obs4mips.pdf) which is also based on geostationary platforms.

I am wondering if prospects for a more fair comparison with existing CMIP output samplings and definitions might be improved if an hourly or 3hourly product is made available with time varying missing data. Maybe a path forward would be to provide both a monthly and higher frequency product? I'm going to point this discussion to others involved in the "exploratory" products task team as this issue is not limited to this product.

[alisonwaterfall]

@gleckler1 @taylor13 There are actually a number of different products that have been suggested by the LST CCI team. The datasets for single LEO sensors are given for (or close to) the satellite overpass times, so are for differing universal time. However, they also have a combined satellite product that includes geostationary sensors which is output on 3hr UTC timesteps, which would be analogous to the GERB dataset. So perhaps that would be the easiest dataset to focus on initially.

For all the datasets there are also 'daily' data products available (again just at the satellite overpass times), so I guess those would be an option to provide as well / instead.

[gleckler1]

@alisonwaterfall @taylor13 It would be useful to have an idea of the different products the LST CCI is suggesting. Presumably they all are conducive to sampling in the same or similar ways. As a first step, it maybe a good idea to focus on the 3hr data that is sampled analogously to GERB. This more complex than just adding a new variable that is not part of CMIP, it requires adding a new time coordinate (3hr diurnal monthly means). Beyond ensuring there is a reasonable path to comparing with CMIP output, there are additional steps required with CMOR. It's good to have this conversation - there will be a group thinking about this.