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

[netCDF #TLB-677315]: FW: Net CDF-4 Issues

Hi Coy,

It appears we got your email support question from a week ago, but it
"slipped through the cracks" and didn't get a quick response.  Sorry
about that.

> The problem I was having was due to two calls using the same string.
> This works in NetCDF-3 but causes NetCDF-4 to throw an error when
> calling nc_enddef. It seems odd that the second call below did not
> return an error since it was the cause of the problem. I fixed this by
> simply changing "Mode" to "ModeNumber" in the second call.
> iReturn = nc_def_dim (m_iNcFileID, "Mode", NC_UNLIMITED, &m_iDim_Set);
> iReturn = nc_def_var (m_iNcFileID, "Mode", NC_SHORT, 1, aURI,
> &m_iModeNum);
> iReturn = nc_enddef(m_iNcFileID);

It's a netCDF convention that a variable with the same name as a dimension
represents a coordinate variable.  As the Users Guide says:

  It is legal for a variable to have the same name as a
  dimension. Such variables have no special meaning to the netCDF
  library. However there is a convention that such variables should be
  treated in a special way by software using this library.

  A variable with the same name as a dimension is called a coordinate
  variable. It typically defines a physical coordinate corresponding
  to that dimension.

Due to the lack of shared dimensions in HDF5 and the way coordinate
variables had to be implemented to work around that problem, they now
really do have a special meaning to the netCDF library.  If you use
the same name for a dimension and a variable, the netCDF-4
implementation assumes the variable is a coordinate variable for the
dimension, which led to the problem you discovered.  The best
workaround may be to just choose a different name for the variable, as
you have done.

> I now have my code writing NetCDF-4 files with up to 4 unlimited
> dimensions instead of 1, but I am having several problems with these
> unlimited dimensions. The only changes I am making to my code is
> changing the dimensions (shown in the code snippet below) to be
> unlimited.
>
> Problem 1) Making "NameLenght" unlimited causes the character string to
> be written as garbage and sometimes crashes. Can you use unlimited
> dimensions with character strings?

I just tested this and it seems to work fine on a simple 1D example.
However, with a 2D variable, it doesn't do what you intend.  The
unlimted dimension is not intended for ragged arrays, where each row
is a different length.  That's what the "string" data type or more
generally the "variable-length" user-defined data types are for.

When you extend an unlimted dimension, the resulting array is still
rectangular, it just gets extended along the unlimited dimension with
new values for every other dimension.

Try using the string data type instead of "char" and I think you'll
get what you intended.

Nevertheless, the crashes you see indicate a bug in trying to use the
unlimited dimension in this unintended (and evidently untested) way.
Thanks for reporting the problem.

I'll try to respond to your other questions in a subsequent email.

--Russ

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



Ticket Details
===================
Ticket ID: TLB-677315
Department: Support netCDF
Priority: Normal
Status: Closed