[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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.