Regional Figures for recipe recipe_flato13ipcc.yml

[katjaweigel]

Short description of the diagnostic
Figures for recipe_flato13ipcc.yml, which cover different regions, similar to figures of the IPCC AR5 (Flato et al., 2013).
Seasonal cycle over land within defined regions (like Fig. 9.38)
Downscaling: Seasonal bias box plot within defined regions (like Fig. 9.39)
Downscaling: Seasonal bias box plot within defined polar and ocean regions (like Fig. 9.40)
Downscaling: observations versus models within defined regions (like Fig. 9.41)
Figure 13-16 in https://gmd.copernicus.org/articles/13/4205/2020/
Currently they are in recipe_regional_downscaling.yml
4 new diagnostice (+ one library file).
The library file includes hard coded definitions of the SREX regions which might be in conflict/redundant with an ESMValCore issue "Add support for named scientific regions in extract_shape" #758

I need help to add/check/complete the provenance.

Branch and pull request
Branch: https://github.com/ESMValGroup/ESMValTool/tree/regional_downscaling_gmddraft
Pull request: #2156

[katjaweigel]

I updated to latest master and I run a test now

[katjaweigel]

Ran successfully on Mistral.

[LisaBock]

@katjaweigel I tried to run the recipe but I got this error:
ValueError: Dimensions of tas and sftof cubes do not match. Cannot broadcast cubes.

Which core version did you use? Have you ever had this error, too?

[katjaweigel]

@LisaBock I don't remember, that I had this error. I used:
ESMValCore: 2.2.0
ESMValTool: 2.2.0
Which model causes the error? I checked the fixes and found one for ec_earth here, which is not the standard one, but unfortunately I don't remember why.

[katjaweigel]

I just checked my setup again and saw, that I used--skip-nonexistent
I'll try if I get the error without. For the data I only used the common folder (/work/kd0956/CMIP5/data/cmip5/output1), so there shouldn't be anything special there (but it could be a model in /work/kd0956/CMIP5/data/cmip5/output2, which was not used due to --skip-nonexistent, if this is the case I'll find it and take it out of the recipe).

[katjaweigel]

Now I got another error, and this one I had before:

INFO Reading in file = /work/bd1083/b380216/output/recipe_regional_downscaling_20210505_070813/preproc/regional_downscaling_Fig939/tas/CMIP5_NorESM1-ME_Amon_historical_r1i1p1_tas_1986-2005.nc
INFO Warning: unsupported calendar in function time_operations (diag_scripts/shared/statistics.ncl): Gregorian. Using 'standard' instead.
warning:toint: there are 12 float(s) larger than INT_MAX, which have been flagged missing.
warning:toint: there are 12 float(s) larger than INT_MAX, which have been flagged missing.
fatal:Subscript out of range, error in subscript #0
fatal:An error occurred reading subfield
fatal:["Execute.c":8637]:Execute: Error occurred at or near line 545 in file
fatal:["Execute.c":8637]:Execute: Error occurred at or near line 438 in file /mnt/lustre02/work/bd1083/b380216/CORE202102/ESMValTool/esmvaltool/diag_scripts/regional_downscaling/Figure9.39.ncl

This one occurred before (but only sometimes, usually when starting it again with identical setup it does not occur again) and seems to be related to the (random) order the models are read into the diagnostic.There is some calendar correction in the diagnostic, which causes it. It is possible that this correction is not necessary at all with the current preprocessor and should be removed?

[schlunma]

@katjaweigel I tried to run the recipe but I got this error:
ValueError: Dimensions of tas and sftof cubes do not match. Cannot broadcast cubes.

Which core version did you use? Have you ever had this error, too?

This looks like it was introduced with ESMValGroup/ESMValCore#999. I will have a look at that.

[katjaweigel]

Now it run without any of the errors with ESMValCore 2.2.0, so it is probably related to the core and not --skip-nonexistent

[LisaBock]

@schlunma Is there a possibility to avoid this error for now before ESMValGroup/ESMValCore#1096 is solved?

I tried to add

fx_variables:
      sftof:

but it does not help.

[schlunma]

Since tas is an atmospheric variable, I guess sftlf should work. Can you try that?

[LisaBock]

Since tas is an atmospheric variable, I guess sftlf should work. Can you try that?

Thanks, @schlunma! It works!

[zklaus]

Since the PR is still before both reviews, I am bumping this to 2.4.0.

[valeriupredoi]

OK bumping this to Milestone 2.8 @katjaweigel pls let me know if anything of interest for 2.7 happens and I'll move it back to this release cycle 👍