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

Re: Synchronizing and Open netCDF file

> Organization: NOAA/FSL
> Keywords: 199401102351.AA08301

Tom,

> One part of my code creates netCDF variables in an open netCDF file.
> The documentation claims that there is no need to put the file in
> define mode as this will be done automatically, and indeed this is the
> case.  My problem is that the disk file is not updated until after the
> program exits.  Unfortunately, our application runs constantly, hence
> the file is rarely closed.  When will this variable be updated to the
> disk file?  Do I need to call the sync function to ensure the file is
> updated?  My assumption is that the process that creates the new
> variable can access it, but other processes accessing the same netCDF
> file will need to do a sync to "see" the new variable.  Is this true?

The disk file won't get updated unless one of ncendef(), ncclose(), or
ncsync() in the underlying C interface get called.  Whenever you change a
file from define mode to data mode implicitly by writing out variable values
after adding a new dimension, variable, or attribute, ncendef() should get
called.  If it doesn't, I think it is the symptom of a bug.  There is also a
NcFile::data_mode( void ) member used to assert a netCDF file is in data
mode and call ncendef(), if not, to put it into data mode.  You shouldn't
have to call this member function explicitly; it's supposed to be called
automatically when needed by NcVar::put() or NcVar::get().

The ncclose() function is only called in the NcFile::close() member, which
in turn is invoked from the NcFile destructor, so it sounds like you would
never call that.

The NcFile::sync( void ) member function sounds like what you need to make
sure the data just written is on disk.  This member function should only be
invoked when in data mode, though it looks like the implementation may not
check for this.  I think if you try invoking nc.sync() when nc (an NcFile)
is in define mode, it will return a 0 indicating an error, otherwise a 1.

A reading process must also call the sync() member function to see the new
variable.  Looking at the code for implementing NcFile::sync() makes it
appear that there will be a memory leak in this case, since a bunch of new
NcDim and NcVar objects are created for the file without destroying the old
ones first.  I'll have to check into fixing this, maybe next week.

--Russ