This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Sourish, > I found a problem with netcdf 4.1.3 while creating a group variable > where some of the dimensions should come from the parent group. > Basically, while trying to create a file with the structure > > netcdf wrong_file { > dimensions: > dim1 = 2 ; > dim2 = 1 ; > > group: grp1 { > dimensions: > dim3 = 45 ; > dim4 = 60 ; > variables: > double var1(dim1, dim2, dim3, dim4) ; > double var2(dim1, dim2, dim3, dim4) ; > } // group grp1 > } > > the variables var1 and var2 get wrong dimensions IDs. Please find > attached a fortran 90 program to reproduce the problem. On my system, > with the IBM xlf90 compiler, I do the following: > > 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 > > I see the following structure, which is absolutely not correct: > > netcdf wrong_file { > dimensions: > categories = 2 ; > months = 1 ; > > group: glb600x400 { > dimensions: > latitude = 45 ; > longitude = 60 ; > variables: > double poste_emission(longitude, latitude, longitude, latitude) ; > double prior_emission(longitude, latitude, longitude, latitude) ; > } // group glb600x400 > } > > Could you please look into this? Yes, it appears it is currently necessary to reorder the calls or call nf90_enddef(nc_id) after the definitions of dimensions and variables, but before writing data to variables. This is similar to a documented requirement for the netCDF-3 API, in which definitions must be invoked in "define mode" before data is accessed in "data mode" with calls to nf90_endef and nf90_redef separating transitions from define mode to data mode. In your example, if you replace ! define variable io_status = nf90_def_var(grp_id, 'poste_emission', NF90_DOUBLE, dim_id, var_id(1)) ! fill variable io_status = nf90_put_var(grp_id, var_id(1), x) ! define variable io_status = nf90_def_var(grp_id, 'prior_emission', NF90_DOUBLE, dim_id, var_id(2)) ! fill variable io_status = nf90_put_var(grp_id, var_id(2), x) with ! define variable nf90_def_var(grp_id, 'poste_emission', NF90_DOUBLE, dim_id, var_id(1)) ! define variable nf90_def_var(grp_id, 'prior_emission', NF90_DOUBLE, dim_id, var_id(2)) ! leave define mode nf90_enddef(nc_id) ! fill variable nf90_put_var(grp_id, var_id(1), x) ! fill variable nf90_put_var(grp_id, var_id(2), x) then I believe the resulting file will be OK, which you can check with ncdump. The file also appears OK if you leave out the call to nf90_enddef but reorder the calls so that all the nf90_def calls appear before all the nf90_put_var calls. This is consistent with the documentation, that says the call to nf90_enddef is not necessary for netCDF-4 calls, as it is made automatically by the library. But you have identified a bug, that no error status is returned if you make the calls out of the order required by the library. Another bug is that the library doesn't say the dimension defines have to be made prior to the put_var calls. I have created a Jira issue for this bug, so that we will fix it in a future release. It's really a bug in the C library, but it shows in other APIs built on top of the C library, like the f90 and f77 APIs. If you want to track progress on the bug or refer to it in the future, you can follow it here: https://www.unidata.ucar.edu/jira/browse/NCF-134 Thanks for reporting the problem and creating the example that demonstrates it! --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: VCD-725374 Department: Support netCDF Priority: Normal Status: Closed