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.
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