[netCDF #AKJ-370049]: ncdump question

Rob,

> Thank you for your response and I do apologize for not responding sooner but 
> working multiple task and time got the best of me.  I have researched the 
> documentation for the ISCCP D1 Data and it is treated at signed data, so your 
> recommendation to add the value of 256 if the initial value is less than zero 
> will result in the correct wall.
> 
> You did make reference to netCDF-4, the latest version of which is 4.1.2rc1.  
> Is this a library which you would include in compile run to form an 
> executable?  Unfortunately I do not have a sophisticated development 
> environment and have been pulling window command line utilities together to 
> help process the files I need.  When looking at the web page you suggested I 
> did not see where I could download the new version of the ncdump utility.

In our FAQ on porting to Windows, there's a note at the end of the question 
"How can I use netCDF-4.1 with Windows?"

  http://www.unidata.ucar.edu/netcdf/docs/faq.html#windows_netcdf4_1

that reads:

  NOTE: User Viet Eitner has contributed a port of 4.1.1 to Visual Studio,
  including an F90 port to Intel Fortran. Download source 
  (ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-4.1.1-win32-
  src.zip) or binary (ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32  
  /netcdf-4.1.1-win32-bin.zip) versions. 

That binary has an ncdump.exe for 4.1.1, when you unzip it.

Alternatively, our current netcdf-4.1.2rc1 release can be built on
Windows in a cygwin environment and will create an ncdump.exe for
version 4.1.2.  I think ncdump should treat signed/unsigned integers
the same way in both versions, so the older 4.1.1 probably has the
same features and bugs in that respect.

--Russ

> -----Original Message-----
> From: Unidata netCDF Support [mailto:address@hidden]
> Sent: Wednesday, March 23, 2011 9:19 PM
> To: Graydon, Robert
> Cc: address@hidden
> Subject: [netCDF #AKJ-370049]: ncdump question
> 
> Hi Robert,
> 
> > I have downloaded the windows command line utility ncdump and use it
> > to create an ASCII version of an HDF5 file I downloaded from the ISCCP
> > data serve r. D1 Cloud Data.
> >
> > The command line I used is:         ncdump -l 1212 inputfile > output file
> >
> > I have found that the ncdump routine has modified some of the values
> > from the original input file.
> >
> > For example: The value 255 from the input file is changed to the value
> > of - 1.  (255 is supposed to represent an undefined value.)
> >
> > The value 201 is changed to the value of -55
> >
> > The value of 190 is changed to -66
> >
> > The value of 144 is changed to -112 (this happens to be a longitude
> > value in the file)
> >
> > To the best of my knowledge this is an HDF5 formatted file.
> >
> > Is this a known problem with this utility or should I be including
> > addition command parameters in the command line.
> 
> It looks like ncdump is interpreting these 8-bit values as signed integer 
> bytes rather than unsigned integers bytes.  The range of a signed byte is  
> -128 to 127, whereas the range of an unsigned byte is 0 to 255.  To get the 
> equivalent signed value from the unsigned value, you can subtract 256.  An 
> 8-bit byte can represent either range of integers, depending on what type the 
> variable is declared.
> 
> The netCDF-3 library only supports 3 integer types, and they are all signed: 
> byte (8 bits), short (16 bits), and int (32 bits).  The netCDF-4 library (and 
> the ncdump utility that accompanies that version) supports those 3 types but 
> an additional 64-bit type (long), as well as the four unsigned types 
> corresponding to eacho of the four integer signed types.
> 
> 
> This is documented in the netCDF 3.6.3 User's Guide in Appendix C
> 
> http://www.unidata.ucar.edu/netcdf/old_docs/docs_3_6_3/netcdf.html#NetCDF-Classic-Format
> 
> where it says:
> 
> Note on byte data: It is possible to interpret byte data as either
> signed (-128 to 127) or unsigned (0 to 255). When reading byte data
> through an interface that converts it into another numeric type, the
> default interpretation is signed. There are various attribute
> conventions for specifying whether bytes represent signed or unsigned
> data, but no standard convention has been established. The variable
> attribute “_Unsigned” is reserved for this purpose in future
> implementations.
> 
> Was the HDF5 data you are reading declared to be of type unsigned
> byte?  If so, it ought to be handled correctly by the ncdump utility
> in netCDF-4, the latest version of which is 4.1.2rc1, available from
> the netCDF home page.  If that doesn't work and the HDF5 type was
> declared as unsigned, you've identified a bug in the library that
> we'll have to fix.
> 
> --Russ
> 
> Russ Rew                                         UCAR Unidata Program
> address@hidden                      http://www.unidata.ucar.edu
> 
> 
> 
> Ticket Details
> ===================
> Ticket ID: AKJ-370049
> Department: Support netCDF
> Priority: Normal
> Status: Closed
> 
> 

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



Ticket Details
===================
Ticket ID: AKJ-370049
Department: Support netCDF
Priority: Normal
Status: Closed