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

970813: ncdump output order for fortran

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: 970813: ncdump output order for fortran
  • Date: Wed, 13 Aug 97 10:42:04 -0600
Michael,

>Date: Wed, 13 Aug 1997 09:11:20 -0700 (PDT) 
>From: Michael Watts <address@hidden>
>Organization: NASA/ARC
>To: Steve Emmerson <address@hidden>
>Subject: Re: 970813: ncdump output order for fortran 
>Keywords: 199708121910.NAA09780

In the above message, you wrote:

> Steve,
> Thanks for pointing that out.  I had looked at primarily the header info
> and did not notice that the indeces were switched in the var data.  It
> still seems confusing that if you use the -b f with a .nc file created
> using c then the order in the variable dump doesnt match the order in the
> header.

The output of ncdump(1) must, necessarily, be in a fixed order and
syntax.  If it varied, then an ncgen(1) on the output would create
different netCDF files.

> If I use nc_get_var1 to get index (2,3,4) for a file written in c
> I will get a different number than using nf_get_var1 with index(2,3,4).
> I will get the value at index (4,3,2).  This seems counter to the concept
> that netcdf if language dependent.  I should get the value at index (2,3,4)
> no mater which language I use to write or read.

This should not be surprising.  Recall that the first element of a C
array is element 0; whereas, in Fortran it's element 1 (by default).
Thus, having to use different representations for the indexes of the
same element -- depending on which language is being used -- should come
as no surprise.  The netCDF interface simply follows the conventions
of the language being used.  To do otherwise would require that either
C programmers or Fortran programmers follow an unnatural (to them)
convention.

--------
Steve Emmerson   <http://www.unidata.ucar.edu>