Re: 971114: problems using netCDF 3.0

>From: "GOLDSMITH, ROGER" <address@hidden>
>Organization: Woods Hole
>Keywords: 199711142110.OAA13034 netCDF 3.0
>
> I seem to be getting some unexpected results using the NetCDF 3.0 library.

My first question is what version you really mean. I don't think
there was public release numbered 3.0. There are a couple of was to figure this
out. You can look at the VERSION file in the sources. On a UNIX system, you can
run the system utility ident(1) or what(1) on libnetcdf.a. Otherwise, you can
write a trival program to print the return of the nc_inq_libvers() function.
It would also be helpful to know what machine you are running on.

> Perhaps you or another user has encountered the following situation and
> can be of assistance.  To simplify,
>   I have time records containing among other things
>         int  date[time][3][3]   where time is the unrestricted dimension,
>                                       there are 3 dates per event (record),
>                                       and 3 elements (yr, mon, day).
>         double lon[time][3]     where time is the unrestricted dimension,
>                                       and there are 3 positions per event.

It would be clearer if you used CDL syntax (rather than C language syntax)
to describe the variables and how they are interelated via named dimensions.
You can use the ncdump utility with the -h option to print this out.
Feel free to send the whole thing.

>   Adding each event is a separate process, so I add events 1, 2, and 3.
>   I wish to skip event 4 (it being filled as missing as I understand it)
>   and insert event 5.

This being a C language program, you are using '0' based indexes, right?
You are calling nc_put_varX_XXX(...) for the individual variables, with
the leftmost coordinate 0, 1, 2, then 4.

>   Insertion of an event requires looking at the previous event and I
>   am guessing that because the last event was 3 and no writes have
>   occurred there is no event 4 until I do some future write.

(Aside - How does this work for the first event? I don't really want to know
the details, just be sure you are covering that case.)

>   However, I inquire about date for event 4 (C index 3) using
>     nc_get_vara_int ( ... ieb, iec, datetem[0]);
>     where ieb = [3, 2, 0]
>           iec = [1, 1, 3]
>   This returns an error NC_EEDGE=-57 which is understandable because
>   as I said the record for event 4 is technically not yet written.
>   I believe the called routine ncedgeck does this.  The interesting
>   part is that the routine nc_get_vara_int calls nccoordck before
>   the ncedge check and this apparently returned a normal status.
>   This is manifested in my next call to get the lon variable.
>     nc_get_var1_double (... ieb, &lontem)
>     where ieb = [3, 2]
>   The nc_get_var1_double routine only does the nccoordck and this
>   returns normal, so the retrieval proceeds and returns zero (0.0).
>   I am not sure what it is getting as I don't have a fill value set
>   or anything like that.

It is true that nc_get_var1_XXX() will never return NC_EEDGE.
It is also true that nc_get_vara_XXX(..., coord, edge, ...)
should return NC_EINVALCOORDS if and only if nc_get_var1_XXX(..., coord, ...)
would for the same variable. This principle can be extended to different
variables if they share the same dimensions, which is what I believe you are
trying to do.

>   So what's happenning.  Under the circumstances I would have expected
>   the coodinate check failure (NC_EINVALCOORDS).  The routine seems
>   to try to update the disc and I have in fact tried nc_sync but as
>   I have no writes for event 4 or 5 pending there is no effect.
>   Hope you can understand this and assist.

I believe your understanding of what should be happening is correct.
I don't have enough information to say what is actually going on.
My hypothesis is that this is a bug in the version of netcdf you are running
OR that the edges that you are passing to
        nc_get_vara_int ( ... ieb, iec, datetem[0]);
are not appropriate to the dimensions of that variable, and that the problem
is _not_ with the most slowly varying (UNLIMITED) index.

If it is a bug, you should be able to isolate it down to a simple
demo program. Use two or three dimensions (one of them unlimited) and
two variables.

>  Roger Goldsmith
>  508/289-2770
>  address@hidden

Hope this helps.

-glenn