How to compare model tos to ESACCI-SST data cmorized for variable ts

[tomaslovato]

I tried the cmorizer for ESACCI-SST (satellite sea surface temperature) and it works fine ..

The cmorized data are associated to the atmospheric variable ts as from the original NCL implementation of the cmorizer (see #1895) with the objective to be used within recipe recipe_perfmetrics_CMIP5.yml

Is there a smart way to build a recipe that uses this OBS dataset of SST (Amon, ts) with oceanic model data, namely Omon, tos?

(I'm kind of puzzled by this, as I would have assumed that satellite sst should be associated to tos by default ...)

[valeriupredoi]

what better way to seek an answer to this question than to ask the person who helps produce this data - @cjroberts - Charles contributed the cmorizer and data parameters, and only the integration was done by me :+1: Charles, I know you started a new position recently, if you are not in touch with the SST data production, could you maybe pls point us to a person we can contact? Cheers :beer:

[cjroberts]

Hi V, you could try Owen in the Surface Temperature group. I don't seem to be able to mention him here, so I will send an email to you both putting you in touch.

[valeriupredoi]

cheers @cjroberts :beer:

[tomaslovato]

@valeriupredoi Given that this cmorizer is dedicated to support and existing recipe it does not make sense to change it, if there is a way to mix up datasets with two different variable names in the diagnostics section of the recipe (model Omon, tos and obs Amon, ts) ?

If not, then the ESACCI-SST data should be, e.g., duplicated to create files referring to Omon, tos cmor variable in order to be compared with ocean data for sst.

[tomaslovato]

a quick feedback on this ... its rather simple to obtain the tos variable from this cmorizer by adding it on the bottom of the configurations files as in the following :

# Variables to cmorize (here use only filename prefix)
variables:
  ts:
    mip: Amon
    raw: sst
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
  tsStderr:
    mip: Amon
    raw: sst_uncertainty
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
+  tos:
+    mip: Omon
+    raw: sst
+    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB

Then the discussion would be if it can go this way or not ...

Besides, I would like to suggest to have a direct control of start/end year values of the available raw data directly in the configuration file, as by now it is hardcoded in the script https://github.com/ESMValGroup/ESMValTool/blob/c528bee330163bbcd78dbcb87af33a4eca2b4da5/esmvaltool/cmorizers/obs/cmorize_obs_esacci_sst.py#L73-L75 an this will help in handling newer data to extend the temporal coverage of this OBS dataset ...

[tomaslovato]

@zklaus I noticed that you added this to v2.4.0 milestone ... could it be useful to open a PR to apply the above modifications (include tos and add year handles in ESACCI-SST.yml) for the ESACCI-SST cmorizer?

[zklaus]

I have to say, my intuition is that this should really be cmorized only as (Omon, tos), not as (Amon, ts) at all. It might then be necessary to adapt the NCL diagnostic, but that is a different thing altogether.

[tomaslovato]

I agree with you on the assignment of the sst data to tos, but I'm also realistic on the fact that mixing up different variable names in a recipe is kind of difficult ...

Would it be too naif to add the tos in ESACCI-SST.yml with commented lines and put a note on the use? maybe something like this ...

# Variables to cmorize (here use only filename prefix)
variables:
  ts:
    mip: Amon
    raw: sst
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
  tsStderr:
    mip: Amon
    raw: sst_uncertainty
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
# uncomment this part to produce sst cmorized data for ocean realm (Omon, tos)
#  tos:
#    mip: Omon
#    raw: sst
#    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB

[zklaus]

In principle, I don't think it is so difficult to mix two different variables in one recipe, but perhaps we are talking about slightly different things? Anyways, I'm afraid we won't solve this for 2.4.0, bumping to 2.5.0.

[schlunma]

@tomaslovato Release v2.5 is approaching quickly (the feature freeze will be on 2022-02-21). Since this issue is marked for v2.5, could you briefly comment if you further intend to include this in the new release and/or if you are facing any problems with it? Thanks!!

[tomaslovato]

Hi @schlunma, I've not much to add with respect to the above discussion. As I initially reported the ESACCI-SST were cmorized as ts variable to be used within recipe_perfmetrics_CMIP5.yml, although these data should naturally refer to tos ocean variable. I don't want to mess up here with existing recipes, so I would just reiterate my dummy idea of adding a set of commented lines in ESACCI-SST.yml to keep track of a simple way to process the dataset for tos.

# Variables to cmorize (here use only filename prefix)
variables:
  ts:
    mip: Amon
    raw: sst
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
  tsStderr:
    mip: Amon
    raw: sst_uncertainty
    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB
# uncomment this part to produce sst cmorized data for ocean realm (Omon, tos)
#  tos:
#    mip: Omon
#    raw: sst
#    file: ESACCI-SST_sat_L4-GHRSST-SSTdepth-OSTIA-GLOB

@zklaus @bouweandela If this is not the way the team would like to proceed then this issue could be closed.

[zklaus]

@tomaslovato, I basically agree with your approach, but since this is about cmorizers and we are doing a major overhaul of that part in 2.5.0, I suggest we bump this issue to 2.6.0 and tackle it before June.

Is that ok?

[tomaslovato]

ok

[sloosvel]

Any update here? Is this ready for 2.6?

[tomaslovato]

@sloosvel I think that adding a commented part to ESACCI-SST.yml to address the user on how to process from this dataset the tos variable is still a good solution as we avoid breaking the recipe recipe_perfmetrics_CMIP5.yml.

@zklaus any additional thoughts on this?

[sloosvel]

Maybe an explanation should be added somewhere (in the docs? a link to this issue in the recipe?) as for why this is commented, but if that is all that is needed and you have time to open a PR with the changes before friday, then I don't have an issue with this being included.

[tomaslovato]

@sloosvel thanks for taking charge of the PR