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

[netCDF #IKS-582359]: netCDF example programs in IDL

Hi Ken,

Thanks for the IDL examples!

> The netCDF files are not strictly identical to the other examples,
> because I ordered the array indices and dimension names using IDL
> conventions (see P.S. below). Since these are tutorials rather than
> test and validation programs, that seemed OK.

We would prefer that all the example programs produce exactly the same data 
files. We want to emphasize that the same data can be written or read from any 
language, to point out that netCDF data is language independent as well as 
platform independent.  We also want to explicitly show how arrays have to be 
declared to correspond to the CDL notation produced by ncdump, since this 
sometimes causes confusion.  The fact that some languages including CDL use 
row-major order (last index varying fastest), whereas other languages use 
column-major order (first index varying fastest) unfortunately cannot be 
ignored when comparing how to do the same task in various languages.  If a user 
designs a data structure using CDL notation, then writing a program that 
produces the corresponding netCDF file *must* reverse dimension order for 
row-major languages such as Fortran or IDL, otherwise the arrays would be 
transposed on the disk.

> In the first example, simple_xy_wr.f, the output variable pres_out is
> defined as a 12 x 6 array, but the comments describe it as a 6 x 12
> lat-lon array. I think it would be clearer to describe it as a 12 x
> 6 lon-lat array. In the netCDF file produced by the program, the
> dimensions appear as
> 
> netcdf simple_xy {
> dimensions:
> x = 6 ;
> y = 12 ;
> variables:
> int data(x, y) ;

I think you may be looking at both the first and third examples, simple_xy_wr.f 
and sfc_pres_temp_wr.f.  There is no "pres_out" variable in the first example 
or any mention of "lat" or "lon".  The first example is merely intended to be a 
purely abstract example with dimensions "x" and "y" and variable "data". There 
is not supposed to be any relationship between examples 1 and 3, though it is 
also unfortunate that they both use dimensions of the same size, which might 
make one think that the "x" in example 1 somehow corresponds to the "latitude" 
in example 3, just because they are both of size 6.  No such correspondence was 
intended, and I agree with you that "x" is more conventionally associated with 
longitude than latitude.

When the program comments refer to writing a "6 x 12 lat-lon array", the 
intention was to describe the shape of the external array on disk in a 
language-independent way, rather than the internal array that stores the values 
to be written.  CDL is intended to be a language-independent specification of 
the external data.  You're right, this is confusing, and I'll see if we can 
clarify the comments to make this clearer.

> Trivial point: temperature units should be "degrees C" or "degrees 
> Celsius".

Actually we are following the CF Conventions standard here, which says 
temperature units (and all units attribute values in general) must follow the 
udunits notation and syntax.  "degrees" are an allowed unit for angular measure 
such as solar zenith angle or latitude or longitude of a transformed grid, but 
for temperature in Celsius, the permitted units must be one of

degree_Celsius
Celsius
celsius
degree_centigrade
degC
degreeC
degree_C
degree_c
deg_C
deg_c

In particular, "C" standing by itself denotes Coulombs, which is why "degrees 
C" is not permitted.  Do you think one of these alternate notations is so 
preferable to "celsius" that we should change the examples?  I'm only a 
computer scientist, so I probably have bad taste when it comes to units 
designations :-) ...

--Russ

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



Ticket Details
===================
Ticket ID: IKS-582359
Department: Support netCDF
Priority: Normal
Status: Closed