ESMValTool 🚀 - PORTING namelist_anav13jclim to v2

Remaining issues:

[x] Reading HadGEM2-ES and fx_files depends on #580.
[x] Diagnostic two_variables.ncl depends on #531.
[x] tos and fgco2 diagnostics depend on #550.
[x] Irregular regridding of tos of bcc-csm1-1 fails (#760)

schlunma on 24 Aug 2018

I started implementing the ocean variables and got some errors. Since I don't have experience in evaluating ocean models at all it would be nice to get some help from you guys @zklaus @ledm. Can you give me some tips ? :smile:

tos of bcc-csm1-1 and bcc-csm1-1-m:

Traceback (most recent call last):
  File "ESMValTool/esmvaltool/preprocessor/_regrid.py", line 209, in regrid                                   │
    result = _regrid_esmpy.regrid(src_cube, target_grid, scheme)                                                                         │
  File "ESMValTool/esmvaltool/preprocessor/_regrid_esmpy.py", line 349, in regrid                             │
    regridder = build_regridder(src_rep, dst_rep, method)                                                                                │
  File "/ESMValTool/esmvaltool/preprocessor/_regrid_esmpy.py", line 255, in build_regridder                    │
    regrid_method, mask_threshold)                                                                                                       │
  File "ESMValTool/esmvaltool/preprocessor/_regrid_esmpy.py", line 150, in build_regridder_2d                 │
    src_field = cube_to_empty_field(src_rep)                                                                                             │
  File "ESMValTool/esmvaltool/preprocessor/_regrid_esmpy.py", line 128, in cube_to_empty_field                │
    circular = is_lon_circular(lon)                                                                                                      │
  File "ESMValTool/esmvaltool/preprocessor/_regrid_esmpy.py", line 112, in is_lon_circular                    │
    seam = (lon.bounds[1:-1, -1, (1, 2)]                                                                                                 │
TypeError: 'NoneType' object is not subscriptable

The raw input file looks like this:

netcdf tos_Omon_bcc-csm1-1_historical_r1i1p1_185001-201212 {
dimensions:
        time = UNLIMITED ; // (1956 currently)
        rlat = 232 ;
        rlon = 360 ;
        bnds = 2 ;
variables:
        double time(time) ;
                time:bounds = "time_bnds" ;
                time:units = "days since 1850-01-01" ;
                time:calendar = "noleap" ;
                time:axis = "T" ;
                time:long_name = "time" ;
                time:standard_name = "time" ;
        double time_bnds(time, bnds) ;
        double rlat(rlat) ;
                rlat:bounds = "rlat_bnds" ;
                rlat:units = "degrees_north" ;
                rlat:axis = "Y" ;
                rlat:long_name = "latitude in rotated pole grid" ;
                rlat:standard_name = "grid_latitude" ;
        double rlat_bnds(rlat, bnds) ;
        double rlon(rlon) ;
                rlon:bounds = "rlon_bnds" ;
                rlon:units = "degrees_east" ;
                rlon:axis = "X" ;
                rlon:long_name = "longitude in rotated pole grid" ;
                rlon:standard_name = "grid_longitude" ;
        double rlon_bnds(rlon, bnds) ;
        float lat(rlat, rlon) ;
                lat:standard_name = "latitude" ;
                lat:long_name = "latitude coordinate" ;
                lat:units = "degrees_north" ;
        float lon(rlat, rlon) ;
                lon:standard_name = "longitude" ;
                lon:long_name = "longitude coordinate" ;
                lon:units = "degrees_east" ;
        float tos(time, rlat, rlon) ;
                tos:standard_name = "sea_surface_temperature" ;
                tos:long_name = "Sea Surface Temperature" ;
                tos:comment = "\"this may differ from \"\"surface temperature\"\" in regions of sea ice.\"" ;
                tos:units = "K" ;
                tos:original_name = "SST" ;
                tos:cell_methods = "time: mean" ;
                tos:cell_measures = "area: areacello" ;
                tos:missing_value = 1.e+20f ;
                tos:_FillValue = 1.e+20f ;
                tos:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_ocean_fx_bcc-csm1-1_historical_r0i0p0.nc areacello: areacello_fx_bcc-csm1-1_historical_r0i0p0.nc" ;
                tos:coordinates = "lat lon" ;
}

Apparently there are no bounds for lat and lon, only rlat and rlon have them. How do I calculate them?

schlunma on 12 Dec 2018

Hi @schlunma,
I think you diagnosed the problem correctly; it is the missing bounds for lat and lon.
As for calculating them:
rlat and rlon tell us that it is a rotated grid, and so I had written a nice description here how to transform the bounds. Unfortunately, looking at the coordinates I discovered that contrary to the claims of the coordinate variables, this is not a rotated grid at all and rather a different version of tri-polar grid.

At this point your options are:

Remove the model from consideration (recommended)
Hunt down the gridspec file (gridspec_ocean_fx_bcc-csm1-1_historical_r0i0p0.nc, see comment in ncdump) or enough detail in the model documentation (ES-DOC, official)
Use some interpolation scheme (scipy's map_coordinates comes to mind) to guesstimate bounds.

If you can solve this in a fix script, it would of course be quite useful as it opens up both versions of the bcc model.

Also, it seems the 4 GFDL models might have a similar metadata problem, though the bounds are present in that case.

Good luck!

zklaus on 13 Dec 2018

👍1

I've spotted similar problems when testing the irregular regridding with sic (see #550).
Since this is very model- and variable-specific, I support @zklaus suggestion to address this in a fix script, if possible.

Please open an issue for each case (or group of similar cases), so we can document them for future application.

mattiarighi on 13 Dec 2018

👍1

Thanks @zklaus for your help, I will try to write a fix for it and open a new issue :+1:

schlunma on 13 Dec 2018

Has this name list been ported to the new version? I am not able to see this in the list of recipes yet though.

rswamina on 31 Jul 2019

I think it is still work in progress.

mattiarighi on 31 Jul 2019

Ok. Thanks.

rswamina on 31 Jul 2019

If I want to use a new dataset for observed GPP (FLUXCOM), is there any other recipe I can use? I know this recipe uses the MTE data set and the FLUXCOM data is the new replacement for MTE. This is for the paper.

rswamina on 1 Aug 2019

I am trying to generate GPP based plots for the paper if possible with the FLUXCOM data set. As per @schlunma's suggestion, I cloned the branch at
https://github.com/ESMValGroup/ESMValTool/blob/Anav13JClim_v2/esmvaltool/recipes/recipe_anav13jclim.yml

created a new env and ran a reduced version of the original recipe_anav13jclim. This version only has gpp based diagnsotics. I found that the program hangs in an ncl script at a point where copyVar is called. I am not an ncl expert so am not sure why this is happening. Am attaching the log reporting the error and recipe I used in two subsequent comments.
@valeriupredoi - I have copied over the cmorized fluxcom files into a temporary directory (fluxcom-cmorized-test) under esmeval. Once the pull request is approved I can move it under obsdata-v2. I was wondering if the chunking issue for this data( https://github.com/SciTools/iris/issues/3362) played a role in this or if it was something else. Hence tagging you.

rswamina on 6 Aug 2019

Log file

DEBUG <<< Entering mvi_nh
DEBUG <<< Entering select_metadata_by_name (interface_scripts/interface.ncl)
DEBUG <<< Entering select_metadata_by_atts (interface_scripts/interface.ncl)
DEBUG >>> Leaving select_metadata_by_atts (interface_scripts/interface.ncl)
DEBUG >>> Leaving select_metadata_by_name (interface_scripts/interface.ncl)
DEBUG <<< Entering metadata_att_as_array (interface_scripts/interface.ncl)
INFO ++++++++++++++++++++++++++++++++++++++++++
INFO mvi_nh (var: gpp_grid)
INFO ++++++++++++++++++++++++++++++++++++++++++
DEBUG <<< Entering exit_if_missing_atts (interface_scripts/logging.ncl)
DEBUG >>> Leaving exit_if_missing_atts (interface_scripts/logging.ncl)
DEBUG <<< Entering select_region (diag_scripts/shared/latlon.ncl)
DEBUG >>> Leaving select_region (diag_scripts/shared/latlon.ncl)
INFO Restricting mean calculation to time period 1980-2005
INFO Restricting mvi calculation to time period 1980-2005
DEBUG Processing FLUXCOM-GPP-ANN
DEBUG <<< Entering read_data (interface_scripts/data_handling.ncl)
INFO Reading in file = /home/users/ranjinis/projects/src/anav13/ESMValTool/esmvaltool/esmvaltool_output/fluxcom-gpp-ann/recipe_test_fluxcom_20190806_205713/preproc/diag_mvi_gpp/gpp_grid/OBS_FLUXCOM-GPP-ANN_reanaly_v1_T2Ms_gpp_grid_1980-2005.nc
DEBUG >>> Leaving read_data (interface_scripts/data_handling.ncl)
DEBUG <<< Entering time_operations (diag_scripts/shared/statistics.ncl)
DEBUG >>> Leaving time_operations (diag_scripts/shared/statistics.ncl)
DEBUG Processing bcc-csm1-1-m
DEBUG <<< Entering read_data (interface_scripts/data_handling.ncl)
INFO Reading in file = /home/users/ranjinis/projects/src/anav13/ESMValTool/esmvaltool/esmvaltool_output/fluxcom-gpp-ann/recipe_test_fluxcom_20190806_205713/preproc/diag_mvi_gpp/gpp_grid/CMIP5_bcc-csm1-1-m_Lmon_historical_r1i1p1_T2Ms_gpp_grid_1980-2005.nc
DEBUG >>> Leaving read_data (interface_scripts/data_handling.ncl)
DEBUG <<< Entering time_operations (diag_scripts/shared/statistics.ncl)
DEBUG >>> Leaving time_operations (diag_scripts/shared/statistics.ncl)
fatal:Assignment type mismatch, right hand side can't be coerced to type of left hand side

fatal:Assignment type mismatch, right hand side can't be coerced to type of left hand side

fatal:["NclVar.c":1390]:Assignment type mismatch, right hand side can't be coerced to type of left hand side

fatal:["Execute.c":8637]:Execute: Error occurred at or near line 120 in file /home/users/ranjinis/anaconda3/envs/fluxcom-anav13/lib/ncarg/nclscripts/csm/contributed.ncl

fatal:["Execute.c":8637]:Execute: Error occurred at or near line 228 in file /home/users/ranjinis/projects/src/anav13/ESMValTool/esmvaltool/diag_scripts/carbon_cycle/mvi.ncl

rswamina on 6 Aug 2019

Recipe ( I reduced the number of data sets for this comment)

documentation:

description: |
This recipe reproduces most of the figures of Anav et al. (2013).

authors:
- anav_al
- wenz_sa
- righ_ma
- schl_ma

references:
- anav13jclim

projects:
- embrace

preprocessors:

noop:
{}

landmask_and_regrid:
mask_landsea:
mask_out: sea
regrid:
target_grid: 2x2
scheme: linear

regridding:
regrid:
target_grid: 2x2
scheme: linear

landmask:
mask_landsea:
mask_out: sea

grading:
regrid:
target_grid: ref_dataset
regrid_scheme: linear
mask_fillvalues: true

regrid_to_ref:
regrid:
target_grid: reference_dataset
scheme: linear
mask_fillvalues:
threshold_fraction: 0.95
diagnostics:

diag_mvi_gpp:
description: MVI scatter plot for gpp (Figure 8).
themes:
- phys
realms:
- land
variables:
gpp_grid : &regrid_Lmon_1980_2005_FLUXCOM
preprocessor: regridding
project: CMIP5
mip: Lmon
field: T2Ms
exp: historical
ensemble: r1i1p1
start_year: 1980
end_year: 2005
reference_dataset: FLUXCOM-GPP-ANN
plot_units: PgC y-1
derive : true
additional_datasets: &gpp_datasets
- {dataset: FLUXCOM-GPP-ANN, project: OBS, type: reanaly, version: v1, tier: 3}
- {dataset: bcc-csm1-1}
- {dataset: bcc-csm1-1-m}
scripts:
mvi_global: &mvi_global
script: carbon_cycle/mvi.ncl
legend_year_outside: true
sort: true
styleset: CMIP5
region: Global
mean_time_range: [1980, 2005]
mvi_time_range: [1980, 2005]
mvi_nh: &mvi_nh
<<: *mvi_global
region: Northern Hemisphere
mvi_sh: &mvi_sh
<<: *mvi_global
region: Southern Hemisphere
mvi_trop: &mvi_trop
<<: *mvi_global
region: Tropics

diag_main_gpp:
description: Error bar, sasonal cycle and evolution plots for gpp (Figure 9).
themes:
- phys
realms:
- land
variables:
gpp_grid:
<<: *regrid_Lmon_1980_2005_FLUXCOM
preprocessor: noop
reference_dataset: FLUXCOM-GPP-ANN
plot_units: PgC y-1
additional_datasets: *gpp_datasets
scripts:
main_global: &main_global
script: carbon_cycle/main.ncl
legend_year_outside: false
legend_outside: false
sort: true
seasonal_cycle_plot: true
errorbar_plot: true
mean_IAV_plot: true
styleset: CMIP5
region: Global
evolution_plot: true
evolution_plot_ref_dataset: FLUXCOM-GPP-ANN
evolution_plot_anomaly: false
evolution_plot_volcanoes: false
main_nh: &main_nh
<<: *main_global
region: Northern Hemisphere
evolution_plot_ref_dataset: FLUXCOM-GPP-ANN
evolution_plot_anomaly: false
evolution_plot_volcanoes: false
main_sh: &main_sh
<<: *main_global
region: Southern Hemisphere
evolution_plot_ref_dataset: FLUXCOM-GPP-ANN
evolution_plot_anomaly: false
evolution_plot_volcanoes: false
main_trop: &main_trop
<<: *main_global
region: Tropics
evolution_plot_ref_dataset: FLUXCOM-GPP-ANN
evolution_plot_anomaly: false
evolution_plot_volcanoes: false

rswamina on 7 Aug 2019

@rswamina please don't copy&paste yaml formatted text into plain text as gitHub comment; it is impossible for me to run your recipe since I am not going to spend an hour editing it back to yaml format :beer:

Also, have you tried debugging yourself ie just throw in a couple print statements see how the from variable looks as compared to the to variable

I have loaded your FLUXCOM data from one file and can access the data no problem, no such issue related to chunking

valeriupredoi on 7 Aug 2019

@valeriupredoi - Apologies, I thought the yml file or recipe was needed for anyone else to check and I did not know how to format it as yml text. I have hidden the comment now.

rswamina on 7 Aug 2019

you can post it as code snippet eg

preprocessors:
  pp_rad:
    regrid:
      target_grid: 1x1
      scheme: linear
  pp_rad_derive_var:
    # use this not to overwrite variables that are used both
    # for derivation and as standalone diag vars
    regrid:
      target_grid: 1x1
      scheme: linear

or attach it as a file attachement

valeriupredoi on 7 Aug 2019

I have also noticed that the bounds for latitude are in reverse eg [ 89.5, 89. ], [ 90. , 89.5]] - any idea why? DOn't think this is affecting the run but it's something to look into

valeriupredoi on 7 Aug 2019

Do you mean the bounds array in the OBS data for latitude?

rswamina on 7 Aug 2019

yep, those guys, each doublet is in reverse order

valeriupredoi on 7 Aug 2019

The guess_bounds function called from the fix_coords function sets the bounds array that way since it is called before flipping coordinates. This is now fixed. However I continue to have the error. Initially I thought the bounds array might be causing it because the error occurs in the call to a function called copyVarCoords. I am not able to find the definition for that function in the library. Is there some way other than using grep to find it?

rswamina on 9 Aug 2019

Ranjini, can you pls post the yml-formatted recipe here so I can try
running it myself? :beer:

Dr Valeriu Predoi.
Computational scientist
NCAS-CMS
University of Reading
Department of Meteorology
Reading RG6 6BB
United Kingdom

On Fri, 9 Aug 2019, 00:26 rswamina, notifications@github.com wrote:

The guess_bounds function called from the fix_coords function sets the
bounds array that way since it is called before flipping coordinates. This
is now fixed. However I continue to have the error. Initially I thought the
bounds array might be causing it because the error occurs in the call to a
function called copyVarCoords. I am not able to find the definition for
that function in the library. Is there some way other than using grep to
find it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ESMValGroup/ESMValTool/issues/473?email_source=notifications&email_token=AG5EFIYJUOBZTLKOMS5ZRNLQDSTTXA5CNFSM4FGJSNGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD35FNEY#issuecomment-519722643,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG5EFIYOLMFCYZJL6PMQIHLQDSTTXANCNFSM4FGJSNGA
.

valeriupredoi on 9 Aug 2019

Ok..I am finding pasting it as code very hard. So I put the recipe (recipe_test_fluxcom.yml) and the fixed data under esmeval/fluxcom-cmorized-test on JASMIN. Apologies.

rswamina on 9 Aug 2019

👍1

that's perfect, I'll have a stab at it now :beer:

valeriupredoi on 9 Aug 2019

Thanks. Also I was wondering if this could be an issue with other data sets. For e.g. if latitude values go from 90 to -90 and no bounds array is specified, we fix coords (where bounds are added). These bounds form pairs like [90,89.5] and so on because the lat values start at 90. Then we flip the coord points but the pairs in bounds still remain the same, just go in reverse order. I don't know if this is a problem when we use the data in recipes.

rswamina on 9 Aug 2019

it should be fine, no problems with any of the cmor checkers and the inverted nature of the bounds should not matter at diagnostic level either.

I am getting this when running your recipe:

INFO    ++++++++++++++++++++++++++++++++++++++++++
INFO    main_global (var: gpp_grid)
INFO    ++++++++++++++++++++++++++++++++++++++++++
INFO    Reading in file = /home/users/valeriu/esmvaltool_var_test/LEE/recipe_test_fluxcom_20190809_104217/preproc/diag_main_gpp/gpp_grid/OBS_FLUXCOM_reanaly_ANN-v1_T2Ms_gpp_grid_1980-2005.nc
INFO    Reading in file = /home/users/valeriu/esmvaltool_var_test/LEE/recipe_test_fluxcom_20190809_104217/preproc/diag_main_gpp/gpp_grid/CMIP5_bcc-csm1-1-m_Lmon_historical_r1i1p1_T2Ms_gpp_grid_1980-2005.nc
INFO    Wrote variable gpp_grid to /home/users/valeriu/esmvaltool_var_test/LEE/recipe_test_fluxcom_20190809_104217/work/diag_main_gpp/main_global/_yearly_gpp_grid_Glob.nc
INFO    Wrote variable gpp_grid to /home/users/valeriu/esmvaltool_var_test/LEE/recipe_test_fluxcom_20190809_104217/work/diag_main_gpp/main_global/_monthly_gpp_grid_Glob.nc
 CDFT_T: bad input parameter, IER=          -5
fatal:divide: Division by 0, Can't continue
^Mfatal:Div: operator failed, can't continue
^Mfatal:["Execute.c":8637]:Execute: Error occurred at or near line 2542 in file ;

^Mfatal:["Execute.c":8637]:Execute: Error occurred at or near line 706 in file /home/users/valeriu/esmvaltool/esmvaltool/diag_scripts/carbon_cycle/main.ncl

any clue?

valeriupredoi on 9 Aug 2019

also note that the preprocessed output file has correct bounds due to cmor fixes

valeriupredoi on 9 Aug 2019

I think it fails in function get_wks in file aux_plotting.ncl when computing npages.

rswamina on 9 Aug 2019

the cmor fix routines do not flip the order of each element in a pair. I thought they did which is why I got the results differently the first time. I had to add this bit in my cmorizer script for this data set.

rswamina on 9 Aug 2019

I think it fails in function get_wks in file aux_plotting.ncl when computing npages.

Bamboozled. Why is it failing for me and not for you? Did you implement a fix for this but forgot to commit&push to branch?

valeriupredoi on 9 Aug 2019

No. it is failing for me as well. I found that the script fails in two different places - one is the copyVarCoord and the second is this. Unfortunately I am not able to reproduce the same errors each time. I have made no code changes to this branch. Only modified the original recipe to use just the gpp bits.

rswamina on 9 Aug 2019

I couldn't run the whole recipe because we are missing some of the obs data needed (LAI ) and also I only need to plot gpp data.

rswamina on 9 Aug 2019

Cna you suggest how I may add print statements to the logger file. I'm having a bit of struggle debugging with ncl code.

rswamina on 9 Aug 2019

I've changed the recipe a bit to have two CMIP models, and now NH goes through OK, it seems you need more than one CMIP model to do the plotting; still hitting the Var error, will look into it

valeriupredoi on 9 Aug 2019

That is interesting...I wanted to test with just one and wasn't quite sure what I expected to see. This may explain why I could not reproduce the error. I tried different data sets and must have included more than one.

rswamina on 9 Aug 2019

the two variables that cause the crash are:

Variable: var_to (parameter)
Type: float
Total Size: 1684800 bytes
            421200 values
Number of Dimensions: 3
Dimensions and sizes:   [year | 26] x [lat | 90] x [lon | 180]
Coordinates:
            year: [1980..2005]
            lat: [-89..89]
            lon: [ 1..359]
Number Of Attributes: 8
  _FillValue :  1e+20
  dataset :     bcc-csm1-1
  typeConversion_op_ncl :       double converted to float
  coordinates : day_of_month day_of_year month_number year
  cell_methods :        time: mean (interval: 20 mintues) area: mean where land
  units :       kg m-2 s-1
  long_name :   Carbon Mass Flux out of Atmosphere due to Gross Primary Production on Land (relative to grid cell area)
  average_op_ncl :      dim_avg_wgt_n over dimension(s): time

Variable: var_from (parameter)
Type: float
Total Size: 1684800 bytes
            421200 values
Number of Dimensions: 3
Dimensions and sizes:   [year | 26] x [lat | 90] x [lon | 180]
Coordinates:
            year: [1980..2005]
            lat: [ -89..  89]
            lon: [   1.. 359]
Number Of Attributes: 6
  _FillValue :  1e+20
  coordinates : day_of_month day_of_year month_number year
  cell_methods :        time: mean (interval: 20 mintues) area: mean where land
  units :       kg m-2 s-1
  long_name :   Carbon Mass Flux out of Atmosphere due to Gross Primary Production on Land (relative to grid cell area)
  average_op_ncl :      dim_avg_wgt_n over dimension(s): time

It looks to me (by visual inspection of the way the lat-lon coordinates are written that they are of different formats (in seems to be float, from seems to be something else) - anyone with NCL experience (I am a n00b at NCL) can please comment?

valeriupredoi on 9 Aug 2019

I'm afraid I am not an expert either. @schlunma may be able to shed some light, perhaps?
Does this mean there are just a couple of problem datasets then?

rswamina on 9 Aug 2019

Also are these regridded/derived vars from gpp? I don't recognize "var_to" and "var_from".

rswamina on 9 Aug 2019

I will have a look at this soon. The branch is really old right now and needs to be updated. There were major changes in the tool (especially the whole core/tool separation), so it's not really surprising that something goes wrong.

schlunma on 12 Aug 2019

@schlunma - Should I check this branch out to generate the plot using the FLUXCOM data once its CMOR-ization code has been approved ?

rswamina on 7 Nov 2019

Esmvaltool: PORTING namelist_anav13jclim to v2

All 38 comments

Log file

Recipe ( I reduced the number of data sets for this comment)

Related issues