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.
Sourish, > Indeed putting all the 'def'-s before all the 'put'-s solved the > problem. However, I have an application where I really need to write > variables as they are available, so I don't know all at once what the > variables are going to be. I've been trying to follow your recipe by > explicitly calling 'enddef' before each 'put' and 'redef' afterwards so > that I can define the next variable. Doesn't seem to work: > > ! define variable 1 > io_status = nf90_def_var(grp_id, 'poste_emission', NF90_DOUBLE, dim_id, > var_id(1)) > > ! fill variable 1 > io_status = nf90_enddef(nc_id) > io_status = nf90_put_var(grp_id, var_id(1), x) > io_status = nf90_redef(nc_id) > > ! define variable 2 > io_status = nf90_def_var(grp_id, 'prior_emission', NF90_DOUBLE, dim_id, > var_id(2)) > > ! fill variable 2 > io_status = nf90_enddef(nc_id) > io_status = nf90_put_var(grp_id, var_id(2), x) > io_status = nf90_redef(nc_id) > > So what would be a way to do what I want to do? Or is there no way until > this bug is fixed? Yes, I've duplicated the problem in the underlying C library. What you did with with enddef and redef calls should have worked. This is a bug that I've entered into out Jira issue tracking system as a modification of NCF-134: https://www.unidata.ucar.edu/jira/browse/NCF-134 I don't know when this will get fixed, because it involves netCDF-4 code that we're not familiar with (the original developer is not at Unidata any more). I'll try to look at it soon ... --Russ > On 11/14/2011 02:53 AM, Unidata netCDF Support wrote: > > 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 > > > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: VCD-725374 Department: Support netCDF Priority: High Status: Closed