Trying to load a cube but too many names differ for time and time bounds

103 views
Skip to first unread message

MichelleMc

unread,
Jul 23, 2020, 12:43:40 PM7/23/20
to SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools
I am trying to load in sea ice concentration data using iris however I get a ValueError which prevents the cube from loading as shown below


ValueError: Too many dimension names differ between coordinate variable 'time' and the bounds variable 'time_bounds'. Expected 1, got 0.



I took an ncdump of the data to see if there were any obvious issues (see below) but do not,



dimensions:

nj = 384 ;

ni = 320 ;

vertices = 2 ;

time = 780 ;

variables:

float latitude(nj, ni) ;

latitude:bounds = "vertices_latitude" ;

latitude:missing_value = 1.e+20f ;

latitude:units = "degrees_north" ;

latitude:long_name = "latitude" ;

latitude:standard_name = "latitude" ;

latitude:_FillValue = 1.e+20f ;

float longitude(nj, ni) ;

longitude:bounds = "vertices_longitude" ;

longitude:missing_value = 1.e+20f ;

longitude:units = "degrees_east" ;

longitude:long_name = "longitude" ;

longitude:standard_name = "longitude" ;

longitude:_FillValue = 1.e+20f ;

float vertices_latitude(nj, ni, vertices) ;

vertices_latitude:units = "degrees_north" ;

vertices_latitude:missing_value = 1.e+20f ;

vertices_latitude:standard_name = "latitude" ;

vertices_latitude:_FillValue = 1.e+20f ;

float vertices_longitude(nj, ni, vertices) ;

vertices_longitude:units = "degrees_east" ;

vertices_longitude:missing_value = 1.e+20f ;

vertices_longitude:standard_name = "longitude" ;

vertices_longitude:_FillValue = 1.e+20f ;

double time(time) ;

time:units = "days since 0001-01-01 00:00:00" ;

time:calendar = "365_day" ;

time:long_name = "model time" ;

time:bounds = "time_bounds" ;

double time_bounds(time) ;

float siconc(time, nj, ni) ;

siconc:units = "%" ;

siconc:long_name = "ice area  (aggregate)" ;

siconc:coordinates = "latitude longitude" ;

siconc:cell_measures = "area: areacello" ;

siconc:comment = "none" ;

siconc:cell_methods = "area: mean where sea time: mean" ;

siconc:time_rep = "averaged" ;

siconc:standard_name = "sea_ice_area_fraction" ;

siconc:_FillValue = 1.e+30f ;

siconc:missing_value = 1.e+30f ;




Does anyone have a way to fix this to load in the data required?

Phillips, Tony

unread,
Jul 24, 2020, 2:23:27 AM7/24/20
to MichelleMc, SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools

I think the problem is that the time_bounds in your sea ice data are not CF-compliant: a CF boundary variable should have one more dimension than the coordinate variable it describes (so that it can hold the cell vertices – the start and end of the time bounds for each cell, in this case), as described here: http://cfconventions.org/Data/cf-conventions/cf-conventions-1.8/cf-conventions.html#cell-boundaries.

 

I suspect that Iris is treating the most rapidly varying dimension of the bounds variable (“time” in this case) as the cell vertices and then trying to match the remaining dimensions (of which it has none) to the coordinate variable’s dimensions: hence complaining that it expected 1 dimension but got none.

 

To fix this, I would first attempt to correct the creation of the data to give it CF-compliant bounds. If that is not possible, I would remove the bounds attribute on the “time” variable so Iris doesn’t attempt to read the bounds at all (and ideally add them back afterwards).

--
You received this message because you are subscribed to the Google Groups "SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scitools-iri...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/scitools-iris/93a840b6-20b5-4a59-82c6-6702bbc8799ao%40googlegroups.com.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

Michelle McCrystall

unread,
Jul 24, 2020, 11:30:07 AM7/24/20
to Phillips, Tony, SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools
Thanks for the response Tony, I see what you mean. Is this as simple as doing a guess.bounds() for the cube in a callback when loading the cube (which I have attempted to no success) or is there another way to do this? 

I have been basing my work-around on this response to a similar problem https://github.com/SciTools/iris/issues/1801 but trying to adapt for creating bounds

Phillips, Tony

unread,
Jul 27, 2020, 7:33:38 AM7/27/20
to Michelle McCrystall, SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools

Hi Michelle

 

Unfortunately, I don’t think that using a callback will help in this case as the failure is occurring inside the execution of the netCDF-loading Pyke rules which are called from iris.fileformats.netcdf._load_cube (https://github.com/SciTools/iris/blob/master/lib/iris/fileformats/netcdf.py#L788) which is just before your callback is run (from https://github.com/SciTools/iris/blob/master/lib/iris/fileformats/netcdf.py#L798).

 

I have worked around a problem of this nature (with a grid mapping variable having the wrong attributes) by monkey-patching iris to wrap iris.fileformats.netcdf._assert_case_specific_facts (https://github.com/SciTools/iris/blob/master/lib/iris/fileformats/netcdf.py#L460) with a function that modifies the attributes in the cf_group object representing the netCDF file before calling Iris’ own _assert_case_specific_facts, so that by the time the Pyke rules are run it looks correct. You could use this to remove the bounds attribute from your time coordinate on load, which (I think) would at least allow Iris to load your data, sans bounds. But that’s a very ugly thing to do -  a better solution would be to use something else to modify the netCDF so that it either lacks the bounds or has CF-compliant bounds – this could either be something like NCO or something in Python that does not require CF-compliance such as xarray.

 

I’m happy to try either of these approaches and post the results – can you put your file somewhere that I can read it so I can check that what I do actually works?

 

Tony

Michelle McCrystall

unread,
Jul 27, 2020, 12:22:48 PM7/27/20
to Phillips, Tony, SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools
Hi Tony, 

Thanks for sharing this information, I wasn't fully aware of it and particularly where the callback function came in, in the loading of data.

I have attached the data here, if you cannot access it please let me know. I will attempt the NCO command as you suggest or else perhaps work in xarray (although the rest of my code is in iris) 

Michelle
Message has been deleted

MichelleMc

unread,
Jul 30, 2020, 12:32:07 PM7/30/20
to SciTools (iris, cartopy, cf_units, etc.) - https://github.com/scitools
Just to update, following your advice Tony, I used NCO to create time bounds, and all works perfectly now. 

Thanks again for all your help

To unsubscribe from this group and stop receiving emails from it, send an email to scitools-iris+unsubscribe@googlegroups.com.

This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

Reply all
Reply to author
Forward
0 new messages