[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #IKS-582359]: netCDF example programs in IDL
- Subject: [netCDF #IKS-582359]: netCDF example programs in IDL
- Date: Tue, 13 Feb 2007 16:40:46 -0700
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