Error when trying to load HadISST obsdata with ESMValTool 2.8.0

[TomasTorsvik]

Describe the bug
I get an error when I try to run the standard recipe_seaice.yml case with the latest installation of ESMCalTool.

ERROR   esmvalcore.preprocessor:353 Failed to run preprocessor function 'load' on the data
[LocalFile('/projects/NS9560K-datalake/ESGF/obsdata/Tier2/HadISST/OBS_HadISST_reanaly_1_OImon_sic_187001-201712.nc')]

For some reason ESMValTool is not able to laod the HadISST data. When I run the same recipe with v2.7.0 it goes trough without problems.

ESMValTool version:

• ESMValCore: 2.8.0
• ESMValTool: 2.8.0

I have not been able to find an explanation why this happens. I suspect that it either can be related to changes in the esmvaltool conda environment (see attachments), or due to changes in the HadISST dataset #3027 , but I suppose there can be other reasons as well. Does anyone have an idea how to fix this problem?

Please attach

recipe_seaice.txt

main_log_debug.txt

esmvaltool2.8.0-env.txt

esmvaltool2.7.0-env.txt

[valeriupredoi]

hi @TomasTorsvik thanks for pointing this to us! It's an iris issue (if you follow the traceback at the end of the main debug file - and cheers for posting it - you'll see iris doesn't like a certain index in the metadata). Since your fail happens with iris=3.6 and not with iris=3.2.1 (wow that's ye olde) it could be one of two things:

• either a retired/deprecated functionality in iris that somehow breaks a valid load case (a fancy word for a bug)
• a bug

@trexfeathers @bjlittle what would it be the best way for you guys to grab hold of that file and have a looksee - it's pretty big, maybe you can coordinate with @TomasTorsvik you guys get a smaller (say 10 years) file from him and test? esmvalcore's I/O is wrapped around iris.load_raw() (as the main debug out attached points to 😁 )

[bouweandela]

It looks like SciTools/iris#5119

[valeriupredoi]

@bouweandela that's exactly that, cheers! In this case, no need for error replication, it's established - what to do next, that's above my paygrade 😁

[bouweandela]

Actually this issue looks like a duplicate of #1875, which was solved by updating the CMORizer script. The solution seems therefore to CMORize the data again with the latest version of ESMValTool.

[TomasTorsvik]

Hi @bouweandela , @valeriupredoi thanks for the quick response. I will try to CMORize the HadISST obsdata again and see if this solves the problem.

[valeriupredoi]

that sounds vaguely familiar, sorry @bouweandela , my memory span is about 12 hours 🤣 @TomasTorsvik how old is that data in /projects/NS9560K-datalake/ - also note that whoever does the data distribution and management should not put OBS data in a dir called ESGF (unless it's obs4mips) 😁

[TomasTorsvik]

Hi @valeriupredoi , @bouweandela , I CMORized the HadISST dataset with the updated script from ESMValTool 2.8.0, and now the recipe works. So, it seems we should update our obsdata, some of it dates back to 2020. 😃
Thanks for the heads up about not having OBS data under an ESGF dir. The NS9560K-datalake is not part of an ESGF node, but I suppose it still makes sense to separate ESGF and non-ESGF related data. 😉

[valeriupredoi]

@TomasTorsvik brilliant! Very many thanks for following it up with reCMORization, and closing - this is how everyone should do issues on GH 😁