netCDF comments and concerns

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: netCDF comments and concerns
• From: pierce@xxxxxxxxxxxxxxxxxxxxxxxxxxx (David Pierce)
• Date: Wed, 21 Oct 1992 14:24:08 -0700

I'm switching over some of my numerical models to use netCDF because it's
quite a nice system (i.e., thanks for making it available!).  I do have a
couple of comments, though.  Specifically, I think the choice to have netCDF
change the *variable ids* depending on whether the package is called from a
C program or a FORTRAN program is a mistake.  There is no reason why the 
user should ever do anything with those ids besides pass them, unmodified,
back to other netCDF routines.  Having to add or subtract 1 from values which
should never be altered, depending on which language you call the package
from, seems like a mistake to me.  Just to be specific, I've included a
script of the output from a C/FORTRAN combination which shows what, in my
opinion anyway, is very undesirable behavior:


*** opencdf.c: ***

#include "/usr/local/include/netcdf.h"

        long
opencdf_( varid )
long    *varid;
{
        long    cdfid;
        long    dims[1];
        long    dim_x, dim_y, dim_z, var_x, var_y, var_z;
        char    *message_x="this is X", *message_y = "this is Y",
                *message_z="this is Z";
        char    *title = "title for the test cdf file";

        cdfid = nccreate( "test.cdf", NC_CLOBBER );

        dim_x = ncdimdef( cdfid, "dim_x", 10L );
        dim_y = ncdimdef( cdfid, "dim_y", 15L );
        dim_z = ncdimdef( cdfid, "dim_z", 20L );

        dims[0] = dim_x;
        var_x   = ncvardef( cdfid, "var_x", NC_FLOAT, 1, dims );
        dims[0] = dim_y;
        var_y   = ncvardef( cdfid, "var_y", NC_FLOAT, 1, dims );
        dims[0] = dim_z;
        var_z   = ncvardef( cdfid, "var_z", NC_FLOAT, 1, dims );

        ncattput( cdfid, NC_GLOBAL, "title", NC_CHAR,
                                strlen(title)+1, title );
        ncattput( cdfid, var_x, "message", NC_CHAR, 
                                strlen(message_x)+1, message_x );
        ncattput( cdfid, var_y, "message", NC_CHAR, 
                                strlen(message_y)+1, message_y );
        ncattput( cdfid, var_z, "message", NC_CHAR, 
                                strlen(message_z)+1, message_z );

        ncendef( cdfid );
        ncsync ( cdfid );

        /* Return the Y variable, so message should be "this is Y" */
        *varid = var_y;
        return( cdfid );
}

*** t.f ***
        program test

        character*60 attribute
        character*60 title

        icdf = opencdf( iyid )

c       ------------------------------------------------------
c       Note: if you comment the following two lines out, the
c       next NCAGTC call barfs!  Why?
c       ------------------------------------------------------
        call ncainq( icdf, NCGLOBAL, 'title', itype, ilen, ierr )
        print *, 'title type, length:',itype,ilen

        call ncagtc( icdf, NCGLOBAL, 'title', title,     ilen, ierr )
        call ncagtc( icdf, iyid, 'message', attribute, ilen, ierr )

c       This should print out "this is Y"
        print *, attribute

        end

Script started on Wed Oct 21 14:09:19 1992
(killer)1> cc -c opencdf.c
(killer)2> f77 -o test opencdf.o t.f -lnetcdf
(killer)3> test
 title type, length:           2          28
 this is X                  
(killer)4> ^D
script done on Wed Oct 21 14:09:45 1992

Although the y variable id is returned, when this exact same value is
used from FORTRAN, a different variable is accessed!  I haven't checked
whether this is true for dimension ids also.  At the very least, having 
a +/- 1 difference in the *variable* ids when calling from C or FORTRAN,
but having NO difference in the CDF file ids, is inconsistent and confusing.

The other question I had was pointed out in the comments in the FORTRAN
program--if you comment out the ncainq call, the next ncagtc call dies
with a ' NCAGTC: string won't fit in CHARACTER variable provided ' error
message!  This is in spite of the fact that the C program syncs the cdf
file, and the variable is plenty big enough to hold the result.  It 
seems like a bug to me.

The above comments nonwithstanding, I really like the netCDF package (far
more than the hdf one), so thanks again for making it available.

--Dave Pierce     pierce@xxxxxxxxxxxxxxxxxxxx
--