[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: grid_number in netCDF file

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: grid_number in netCDF file
  • Date: Mon, 5 Apr 1999 21:24:32 -0500 (CDT)
Robb:

> ngrids is a dimension only, the grid_number should be at the bottom of the
> cdl file:
> 
> grid_number = 236, 255 ;

Thanks for your note.  I did locate the grid number, as you say.  My
problem was that the variable "grid_number" is specified as having
dimensions (nav, ngrids) and my software was not expecting this, since
my only other examples (eta and ruc) had only one dimension (nav) for
this variable; therefore, when I tried to do a 'getInt()' on it with
only one index array value, I got an exception.

I will change the software so that it correctly detects the number of
dimensions of this variable...will it always be the case that if the
dimension 'ngrids' does not show up in some variable that the implied
values for the grid number is given by "grid_number(0,0)"?

Thanks for your patience...this is my "first time" with the
NetCDF APIs in Java...

> 
> I  attached  ruc2.cdl in case your copy was somehow corrupted.  I used
> ncdump on a ruc2.nc file today and located grid_number ok, maybe the file
> Don sent was corrupted.  This happens once in a while when there is no
> disk space to write the ruc2.nc file.  These files are large:
> 48478444 Apr  5 12:42 99040518_ruc2.nc
> 

I'll say -- the one Don sent was like 190MBs...

Thanks again.

tom

--
Tom Whittaker  (address@hidden)
University of Wisconsin-Madison
Space Science and Engineering Center
Phone/Voicemail: 608/262-2759  
Fax: 608/263-6738