Re: netcdf, IDL and OSF Alpha port

> Organization: RSI
> Keywords: 199403142107.AA14790

Hi Josh,

> I am changing IDL to use NetCDF 2.3.2 instead of 2.1 or 2.2 -- I can't
> remember which.  In any case, it seems to work fine on my RS 6K but
> it seems to fail in ncvarput() on the Alpha complaining of "Invalid
> edge legnth"  line 622, NCvcmaxcontig in putget.c
> 
> The idl code which produces this effect:
> 
> id = ncdf_create('foo.cdf', /clobber)
> d0= ncdf_dimdef(id,'d0',10)
> d1 = ncdf_dimdef(id,'d1',20)
> vid = ncdf_vardef(id,'v1',[d0,d1],/byte)
> ncdf_control,id,/endef
> ncdf_varput, id, vid, bindgen(10,20)  ;; write 10x20 array of bytes
> 
> edp is a long (an 8 byte quantity) and ends up being 0x100000001 which
> just screams 4 byte / 8 byte assumption /reality conflict.

I'm not sure what "edp" refers to here.  But I've tried a similar C program
on an Alpha running OSF V2.0, and it seems to work fine.  In defining the
dimensions, above, you must make sure that the dimension lengths, 10 and 20,
are longs or get converted to longs before the underlying ncdimdef is
called, since it expects longs for dimension sizes.  This is handled OK if
the prototype for ncdimdef() in netcdf.h is in scope.

Here is source for a C program I tried with netcdf 2.3.2 on our Alpha to try
to duplicate the error you saw:

----------------------------------------------------------------------
#include <stdio.h>
#include <netcdf.h>

int
main()
{
    int i;
    int dimids[2];
    int varid;
    char bytes[200];
    long start[] = {0, 0};
    long count[] = {10, 20};

    int ncid = nccreate("foo.nc", NC_CLOBBER);
    
    dimids[0] = ncdimdef(ncid, "d0", 10);
    dimids[1] = ncdimdef(ncid, "d1", 20);
    varid = ncvardef(ncid, "v1", NC_BYTE, 2, dimids);
    ncendef(ncid);

    for (i=0; i<200; i++)
        bytes[i] = i;

    ncvarput(ncid, varid, start, count, bytes);
    ncclose(ncid);
}
----------------------------------------------------------------------

The above program compiles, links, and runs without error, and ncdump shows
the expected values have been stored.  I've appended the results of running

    ncdump foo.nc

on our Alpha.

If you get different results when running the above program with the netcdf
2.3.2 library on your Alpha, please send us the output, and we'll try to
figure out what the problem is.

__________________________________________________________________________
                      
Russ Rew                                              UCAR Unidata Program
address@hidden                                        P.O. Box 3000
(303)497-8645                                 Boulder, Colorado 80307-3000


netcdf foo {
dimensions:
        d0 = 10 ;
        d1 = 20 ;
 
variables:
        byte v1(d0, d1) ;
 
data:
 
 v1 =
  0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
  20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 
39,
  40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 
59,
  60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 
79,
  80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 
99,
  100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 
    115, 116, 117, 118, 119,
  120, 121, 122, 123, 124, 125, 126, 127, -128, -127, -126, -125, -124, -123, 
    -122, -121, -120, -119, -118, -117,
  -116, -115, -114, -113, -112, -111, -110, -109, -108, -107, -106, -105, 
    -104, -103, -102, -101, -100, -99, -98, -97,
  -96, -95, -94, -93, -92, -91, -90, -89, -88, -87, -86, -85, -84, -83, -82, 
    -81, -80, -79, -78, -77,
  -76, -75, -74, -73, -72, -71, -70, -69, -68, -67, -66, -65, -64, -63, -62, 
    -61, -60, -59, -58, -57 ;
}