[netCDF #VCD-725374]: Trouble inheriting variable ID into group

Hi Sourish,

Sorry it's taken so long, but I've finally fixed this netCDF-4 bug you 
reported.  

The fix is in the current snapshot and will also be in the upcoming netcdf-4.3
release candidate.  It's a two-line fix to one file in libsrc4/nc4hdf.c, as
described in this Jira ticket:

  https://bugtracking.unidata.ucar.edu/browse/NCF-217

--Russ

> > 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
> 
> 
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