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?
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.
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
To unsubscribe from this group and stop receiving emails from it, send an email to scitools-iris+unsubscribe@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.