Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error while regridding sic for BCC model #151

Closed
nperezzanon opened this issue Jul 9, 2019 · 12 comments
Closed

Error while regridding sic for BCC model #151

nperezzanon opened this issue Jul 9, 2019 · 12 comments
Assignees
Labels
fix for dataset Related to dataset-specific fix files

Comments

@nperezzanon
Copy link
Contributor

Hi!
I am trying to regrid 'sic' variable to 1x1 in order to have a regular
grid with longitudes and latitudes, so the same script can work with
atmospheric or ice variables.

I did it in the past and it worked with BCC data. Now, I found the
following errors:

     Cell methods:
             mean: time, {'target_grid': '1x1', 'scheme': 'nearest'})
    ...
      File

"/home/users/nperez/miniconda3/envs/esmvaltool/lib/python3.7/multiprocessing/pool.py",
line 657, in get
raise self._value
TypeError: 'NoneType' object is not subscriptable

If I remove the regrid option, I found different error

     Cell methods:
              mean: time, {'start_longitude': 0, 'end_longitude':

360, 'start_latitude': 50, 'end_latitude': 90})
....

      File

"/home/users/nperez/miniconda3/envs/esmvaltool/lib/python3.7/multiprocessing/pool.py",
line 657, in get
raise self._value
ValueError: The truth value of an array with more than one
element is ambiguous. Use a.any() or a.all()

The data is on Jasmin. Using CNRM-CM5 data this error doesn't appear, so I keep testing with CNRM-CM5 data.

main_log_debug.txt
recipe_modes_of_variability.txt

Cheers, Núria

@bouweandela
Copy link
Member

It looks like it's failing because the latitude and longitude coordinates do not have bounds:

$ ncdump -h /home/bandela/esmvaltool_input/sic_OImon_bcc-csm1-1_historical_r1i1p1_185001-201212.nc
netcdf sic_OImon_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 sic(time, rlat, rlon) ;
		sic:standard_name = "sea_ice_area_fraction" ;
		sic:long_name = "Sea Ice Area Fraction" ;
		sic:comment = "fraction of grid cell covered by sea ice." ;
		sic:units = "%" ;
		sic:original_name = "CN" ;
		sic:cell_methods = "time: mean" ;
		sic:cell_measures = "area: areacello" ;
		sic:missing_value = 1.e+20f ;
		sic:_FillValue = 1.e+20f ;
		sic:associated_files = "baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_seaIce_fx_bcc-csm1-1_historical_r0i0p0.nc areacello: areacello_fx_bcc-csm1-1_historical_r0i0p0.nc" ;
		sic:coordinates = "lat lon" ;

@zklaus @jvegasbsc Do you have any ideas on how to solve this?

@zklaus
Copy link

zklaus commented Jul 11, 2019

You are right that that is most likely the problem. The thing is that the bcc data is really challenging in this regard: Bounds are a hard requirement and they are difficult to reconstruct without knowing the grid. At first glance one might think that the (rlat, rlon) variables give enough information, however, looking at the 2d longitude field it's immediately clear that this is not, as claimed, a rotated grid, but rather a tripolar grid. My best guess is that the rlat, rlon information really is just wrong, but in the southern hemisphere probably a not-too-terrible approximation. Close to the north pole I expect it to be rather incorrect though. Unfortunately, the grid also doesn't coincide with any of the other tripolar grids that I checked for this, so that we can't just take the bounds information from there.

At this point, I gave up on bcc data when I was looking into it myself. If you are determined to solve this, it might be not too difficult: You have to track down the bounds information and write a fix file for ocean and seaice variables. If somebody finds the bounds or the gridspec file, I, @sloosvel, or @jvegasbsc can help with the writing of the fix file.

Heads up for the core team: Preliminary checks suggest the situation as not changed appreciably in CMIP6.

@schlunma
Copy link
Contributor

Does this fix help?

@zklaus
Copy link

zklaus commented Jul 11, 2019

Oh yeah, I forgot about that. We discussed this before.

Yes, yes it does. @schlunma, could you modify it so that it automatically applies to all ocean and seaice variables?

@schlunma
Copy link
Contributor

Not really, I have no clue which variable are affected. As far as I know you have to specify all of them individually in the fix. The only possibility would be in all_vars, but then this function needed to check if the fix is really necessary.

@zklaus
Copy link

zklaus commented Jul 11, 2019

@jvegasbsc, can we put this in all_vars and check for the mip? For cmip5 it should apply to all variables from the tables OImon, Oclim, Omon, and Oyr.

@jvegreg
Copy link
Contributor

jvegreg commented Jul 11, 2019

The only possibility would be in all_vars, but then this function needed to check if the fix is really necessary.

This is what all_vars is supposed to do. In this case, check if latitude and longitude are bidimensionals and do not have bounds

@zklaus
Copy link

zklaus commented Jul 11, 2019

@schlunma are you up for it?

@schlunma
Copy link
Contributor

I'm working on another branch right now, so not now, sorry 😬

@bouweandela
Copy link
Member

@jvegasbsc Shouldn't missing bounds be detected by a CMOR check already, instead of failing at regridding?

@jvegreg
Copy link
Contributor

jvegreg commented Jul 12, 2019

@jvegasbsc Shouldn't missing bounds be detected by a CMOR check already, instead of failing at regridding?

Making it an error will be to strict: most of the times we don't need them. A warning will be nice, though.

@valeriupredoi
Copy link
Contributor

yes, for some reason the oceans data is special - I can confirm that the ESGF version of the data is also missing bounds:

d = iris.load_cube("/badc/cmip5/data/cmip5/output1/BCC/bcc-csm1-1/historical/mon/seaIce/OImon/r1i1p1/latest/sic/sic_OImon_bcc-csm1-1_historical_r1i1p1_185001-201212.nc")
d.coord('latitude').bounds
Nada

Guessing bounds with guess_bounds() would not work either coz it's a multidimensional coordinate:

CoordinateMultiDimError: Multi-dimensional coordinate not supported: 'longitude'

The fix by Javi and pointed out by Manu works really well, I have just tested it with the ESGF sic file 🍺

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix for dataset Related to dataset-specific fix files
Projects
None yet
Development

No branches or pull requests

7 participants