netCDF on Unix and Windows

------- Forwarded Message

Date:    Tue, 23 Feb 1999 14:15:07 -0700
From:    Russ Rew <address@hidden>
To:      "Charlease L. Bobo" <address@hidden>
Subject: Re: 19990223: netCDF on Unix and Windows 

>To: address@hidden
>From: "Charlease L. Bobo" <address@hidden>
>Subject: netCDF on Unix and Windows
>Organization: Mission Research Corporation
>Keywords: 199902231937.MAA09071

Charlease,

>> My first guess would be that the copy
>> you have on your PC of the file created
>> on your SGI is not an exact copy, but
>> has been changed somehow in
>> transferring it.  For example, if you
>> used ftp to copy it and did not specify
>> binary mode, the file would get
>> mangled.  Do you have some way to
>> verify that the copy on your PC is
>> byte-for-byte identical to the original
>> file created on SGI?  If not, perhaps
>> you could attach the file to a mail
>> message and we could verify whether it
>> looks like a good netCDF file or not.

> Right now, I am mapping the SGI drive (NFS
> mount) on to the PC so that I'm trying to
> read the file directly from the SGI drive
> without having to copy or ftp the file.
> 
> The ncdump on the SGI can read the file with
> no problem.

OK, my next guess would be that either the
library on your PC or the library on your
SGI was built incorrectly, perhaps with
the wrong compile flags for the platform
used to build the library.  This could
happen, for example, if you built the
library on one system, then built it on
the other system in the same directory
without removing the "config.cache" file
that stores the machine configuration
computed by the "configure" script.  This
seems unlikely, because DOS machines can't
run the "configure" shell script, which is
intended only for Unix systems.

If the library is built incorrectly, it
might appear to be OK on the platform for
which it was built, but might produce
byte-swapped files that will only be
detectable when you try to move such a
file to another platform.  There is a test
binary file in the source distribution for
netCDF version 3.4 named
libsrc/test_nc.sav which can be used for
testing purposes.  If the SGI ncdump can
dump it but the DOS one can't, then the
problem is with the DOS netCDF library.

>> In case it helps, the first 4 bytes of
>> every netCDF file should be 'C', 'D',
>> 'F', and '\001' in that order, where
>> '\001' indicates a byte that
>> corresponds to the ASCII SOH character,
>> which has the numeric value 1.  If the
>> first four bytes are anything else or
>> not in this order, then the netCDF
>> library will not recognize the file and
>> will refuse to open it.

> I ran an od on the netCDF file and it does have 'C', 'D',  and 'F'.
> However it just shows a '001' with no slash.
> Could this be the problem ?  If so, how do I fix it ?

No, that's not the problem.  The "od"
utility will show the byte as '001', I was
just using the C language notation for the
char constant, which is '\001'.  I assume
you ran "od" on the SGI, not the PC, so
this shows the file looks OK on the SGI.

This is also consistent with the a badly
built library on the DOS machine, but you
can verify this with the test on
test_nc.sav described above.

We have binary (compiled) versions of the
netCDF software for Windows systems in 

 ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/

but as far as I know, we don't have any
recent DOS binaries you could use.  There
are some old DOS binaries you might be
able to use from

 ftp://ftp.unidata.ucar.edu/pub/netcdf/old/msdos/

At least you could try that NCDUMP and see
if it recognizes the file.

- --Russ

_____________________________________________________________________

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

------- End of Forwarded Message