Esmvaltool: Regional Figures for recipe recipe_flato13ipcc.yml

Created on 4 May 2021  路  11Comments  路  Source: ESMValGroup/ESMValTool

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

diagnostic

Most helpful comment

@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.

All 11 comments

I updated to latest master and I run a test now

Ran successfully on Mistral.

@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?

@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.

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).

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?

@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.

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

@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.

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

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

Thanks, @schlunma! It works!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bouweandela picture bouweandela  路  4Comments

valeriupredoi picture valeriupredoi  路  4Comments

valeriupredoi picture valeriupredoi  路  5Comments

jonnyhtw picture jonnyhtw  路  4Comments

valeriupredoi picture valeriupredoi  路  4Comments