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

[netCDF #KFB-787515]: netcdf f90 code



Hi Ben,

I can't tell from the code you have sent, but it may be the order of
dimensions in your Fortran-90 variable declarations is wrong.  The
output from ncdump prints the dimensions in C order, which is also
called "row major" order, with the last dimension varying most
rapidly.  Fortran uses "column major" order, with the first dimension
varying most rapidly.

Currently your code declarations like

  real :: temp_in(NLVLS, NLATS, NLONS)

would only be consistent with the data if the declarations from
running "ncdump -c afoifa.pg0504.nc" were something like this:

  float temperature(time, longitude, latitude, pressure) ;

If instead the output from ncdump looks something like

  float temperature(time, pressure, latitude, longitude) ;

then the declarations of arrays in your program should be

  real :: temp_in(NLONS, NLATS, NLVLS)

Your setting of count

  count = (/ NLONS, NLATS, NLVLS, 1 /)

looks OK only if the declarations of the variables in the ncdump
output use the order of dimensions

  float temperature(time, pressure, latitude, longitude) ;

Currently your settings of the count vector are inconsistent with the
order of dimensions in your Fortran variable declarations.  I suspect
that count is OK, but the variable declarations are wrong.  But if the
variable declarations turn out to be OK, then you should change the
order of the count vector correspondingly.

There is another problem with your code: it just reads the first
record over and over each time through the loop

  start = (/ 1, 1, 1, 1 /)
   ...
  do rec = 1, NRECS
   ...
  end do

since it never updates the start vector.  If you want it to read the
data for the n-th time when rec = n, you should either set

  start(4) = rec

after the beginning or insert something like

  start(4) = start(4) + 1

just before the end of the loop, again assuming time is the slowest
varying dimension (the first dimension in the ncdump output variable
declarations).

I would also recommend eventually changing your code to read in the
sizes of dimensions, rather than assuming what they are.  I realize
this comes from your basing the code on an example that wrote a data
file and then read it back in.  Since you are only reading the data
file, you should be getting the sizes of dimensions from the data file
to make your program more flexible, and similarly if you will be using
the units attributes, you should be reading them in, not setting them
in your program.  But if you don't use the units, you could just
delete that part of the program to make it more understandable.

--Russ

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



Ticket Details
===================
Ticket ID: KFB-787515
Department: Support netCDF
Priority: Normal
Status: Closed