Re: 20051025:ncdump produced unreadable file ("#UNB" instead of number)

Chris Meek <address@hidden> writes:

> At 11:01 AM 10/28/05 -0600, you wrote:
>>Chris Meek <address@hidden> writes:
>>
>>>  Thanks Ed - I think I have found the problem - there are 
>>> at least 3 versions of ncdump floating around on the web.
>>> I was using the 57K + netcdf.dll version ... which produced
>>> the #UNB. If I use the 185K version with CYGWIN1.DLL
>>> I get NaN - which is still a problem but at least I know
>>> what it means. And also with this latter version I get the
>>> correct # altitudes per event, while before I was (unknown
>>> to me until I tripped on the #UNB) getting more than the header-
>>> specified # altitudes - but not reading them all, and even worse 
>>> maybe some mismatches between various parameter ascii dumps. 
>>>
>>>   There is a further version which is 560K and goes with SZLIBDLL.DLL
>>> ( I can't find the latter for download one the web although it is 
>>> mentioned in many places).
>>
>>Hmm. I really don't know what to say about this. Incidentally, are you
>>also using netCDF from Fortran on this platform? Or you are only using
>>ncdump and the C library?
>
> Hi Ed-
>  I am using ncdump by a system call  from Fortran (WATCOM 
> FORTRAN 77, windows 95/98/XP - I am using XP at the moment) to
>  dump parameters to an ascii file which I read and parse from 
> fortran to get the dimensions, dynamically allocate matrices
>  (yes WATCOM has this extension), and read the ascii data as
>  "list directed" [I think that's the term, e.g. read(iunit,*)vmatrx].
>  Since "events" are concatinated in the data I have no way of
>  knowing (in fortran) how many values are in each event unless there
>  are fewer than specified in the header information - in which case
>  my program will hit an unexpected EOF.
>     With the 56K ncdump.exe, every case I checked (counting
>  numbers by hand, and going by ascii formatting clues and data gaps
>  to detect event begin/end of events ) had more than the 
> header-specified # x number-of-events... so I didn't hit EOF
>  and didn't have any idea something was wrong until the read
>  error caused by the #UNB.
>
> Chris


Well Chris, that is a fairly crazy way to get the data into a fortran
program, if I am reading it correctly.

Why not read the information directly with the fortran API?

In any case you can try the latest version of ncdump for windows here:

ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-3.6.1-beta1-win32dll.zip


However, unfortunately, that release of netCDF on windows doesn't have
a working fortran API. So if you want to change the way you do things,
and use the fortran API, then you must get the previous version for
windows:

ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-3.5.1-win32dll.zip

Good luck!

Ed


-- 
Ed Hartnett  -- address@hidden