[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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