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

Re: 970512: writing problem

>To: address@hidden
>cc: address@hidden
>From: address@hidden (Carrie Gonzalez)
>Subject: writing problem
>Organization: .
>Keywords: 199705122205.QAA00537

Carrie,

> I have a problem I think.
> 
> The scheme I am using is as follows:
> 
> First, I create an ASCII CDL file to define the dimensions, variables
> and global attributes that will be put into the binary netCDF file.
> I do not put any values for the defined variables.  After this "definition"
> phase is complete, I run "ncgen -b Export.cdl" to generate the binary
> netCDF file, whose filename is given in the CDL file after the netCDF
> keyword.
> 
> Next, I use ncopen to open the newly created binary netCDF file and I
> specify NC_WRITE to start filling in the values for the variables.  I use
> ncvarput to put the values.

You don't say how you are handling errors, documented in the User's
Guide section on error handling at

  http://www.unidata.ucar.edu/packages/netcdf/guide_6.html#SEC37

so I'll assume you are either accepting the default verbose and fatal
error handling, or making sure that the ncvarput() calls don't return
any errors.

>                              I use ncclose to close out the file.  I end
> up with the binary netCDF file, but it is the same size as the skeleton
> binary file I create from the CDL file.

That doesn't necessarily mean anything is wrong, if you are not using
the unlimited dimension with any of your variables.  All non-record
variables (variables that don't use the unlimited dimension) get filled
with "fill values" when they are defined, so that if you try to read a
value before it was written, you get some indication that's what's going
on.  Record variables are only filled record-by-record, as they are
written.  The User's Guide has more information on this, and a way to
avoid pre-filling:

  http://www.unidata.ucar.edu/packages/netcdf/guide_7.html#SEC49

>                                          Furthermore, when I call 
> 
> ncdump -v8,9,10 TSS-1R_RPDP_1996056234900.nc
> 
> I get an error code saying "ncvarid: variable "8" not found", but I look
> in the CDL file and the ninth variable is in there.  Is my overall
> approach incorrect?  I questioned whether ncopen put the file in define
> or data mode, but did not seem to be reading in the correct place to
> get an answer on this.

The "-v" option of ncdump expects a list of variable names, not variable
ids.  The ncdump man page says:

     -v var1,...,varn
          The output will include data values for  the  specified
          variables,  in  addition to the declarations of all di-
          mensions, variables, and attributes.  One or more vari-
          ables  must be specified by name in the comma-delimited
          list following this option.  The list must be a  single
          argument to the command, hence cannot contain blanks or
          other white space characters.  The named variables must
          be  valid  netCDF variables in the input-file. ...

Your approach seems fine.  ncopen() puts the file in data mode.  You're
right, the ncopen entry in the User's Guide does not state that it
leaves the file in data mode.  

Thanks for pointing out the problem with the documentation.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu