Dimension ID not correctly inherited in groups

[dopplershift]

From sourish....@gmail.com on November 08, 2011 07:49:21

What steps will reproduce the problem? 1. Execute 'python test_nc4.py'

2. On the resulting file, execute 'ncdump -h test.nc4'
3. Optionally, dump the full file, 'ncdump test.nc4' What is the expected output? What do you see instead? The variables 'poste_emission' and 'prior_emission' should both have shape (categories, months, latitude, longitude). Instead, 'ncdump -h' shows the shape (latitude, longitude, latitude, longitude).

The full ncdump give the following error:

NetCDF: Index exceeds dimension bound Location: file vardata.c; line 471 What version of the product are you using? On what operating system? python-netcdf4 0.9.2 netcdf 4.1.3 hdf5 1.8.7 python 2.5.1 numpy 1.0.4 OS: SuSE Linux (64 bit) Please provide any additional information below. The problem does not occur if the dimensions 'categories' and 'months' are defined within the group 'glb600x400', so I suspect that it is a problem with inheriting the dimension ID.

I had encountered the same problem with my own fortran 90 code which was using netcdf 4.1.3. Turned out, the problem could be solved by calling an 'enddef' after each 'def_dim' used to create new dimensions.

Attachment: test_nc4.py

Original issue: http://code.google.com/p/netcdf4-python/issues/detail?id=105

[dopplershift]

From whitaker.jeffrey@gmail.com on November 08, 2011 18:50:04

Confirmed. Appears to be a library bug. Will need to provide unidata with a simple c program that triggers it. I can do this next week probably if you are not able to.

[dopplershift]

From sourish....@gmail.com on November 09, 2011 01:02:26

I don't code in C, but please find attached a fortran 90 code to replicate the problem. On my system, using the IBM xlf compiler, I can reproduce the problem as follows:

1. xlf90_r -o netcdf_4.1.3_error -I$NETCDF_DIR/include netcdf_4.1.3_error.F90 -L$NETCDF_DIR/lib -lnetcdff -lnetcdf
2. ./netcdf_4.1.3_error
3. ncdump -h wrong_file.nc4

Attachment: netcdf_4.1.3_error.F90

[dopplershift]

From sourish....@gmail.com on November 09, 2011 01:11:48

I just submitted the fortran 90 code to Unidata with a bug report.

[dopplershift]

From whitaker.jeffrey@gmail.com on November 09, 2011 10:33:06

Great! If you get a ticket number, or other tracking reference from unidata, please post it here.

[dopplershift]

From sourish....@gmail.com on November 09, 2011 11:42:09

Ticket ID: VCD-725374

[dopplershift]

From whitaker.jeffrey@gmail.com on November 14, 2011 10:35:45

Looks like writing the data to the variables after all the variables are created is a valid workaround.

In other words, instead of

var = outGid.createVariable('poste_emission', np.float64, ('categories', 'months', 'latitude', 'longitude')) var[:] = emission_model var = outGid.createVariable('prior_emission', np.float64, ('categories', 'months', 'latitude', 'longitude')) var[:] = emission_model

in your test script, do

var = outGid.createVariable('poste_emission', np.float64, ('categories', 'months', 'latitude', 'longitude')) var = outGid.createVariable('prior_emission', np.float64, ('categories', 'months', 'latitude', 'longitude')) var[:] = emission_model var[:] = emission_model

Hopefully, Unidata will have a fix in 4.2.

[dopplershift]

From whitaker.jeffrey@gmail.com on November 14, 2011 14:33:39

here's a link to follow the process of this on the unidata bug tracker: https://www.unidata.ucar.edu/jira/browse/NCF-134

[dopplershift]

From whitaker.jeffrey@gmail.com on February 25, 2014 18:04:10

Status: Fixed