Cory,
ncdump is reporting the dimensions in C order, with the most rapidly
changing index last. Your Fortran code is based on Fortran order, with
the most rapidly changing index first. Therefore the order you specify
in Fortran will be the reverse of what you see from ncdump.
The order in which you define your dimensions and variables does not
matter. In your code, only the order given in your dimids matters.
The remaining question is whether the dataset you are converting has
latitude varying most rapidly, or longitude. In my experience, it is
usually longitude, so the data are stored as a sequence of stripes
varying over longitude, stacked with increasing (or sometimes
decreasing) latitude. The ncdump reported order is then (lat, lon), and
this is the order you would also see with C and Python. But if you were
reading with Fortran or Matlab, you would see (lon, lat).
My guess is that your input array has lon varying fastest, so you need
dimids = (/ lon_dimid, lat_dimid /). Then ncdump will show (lat, lon).
Eric
On 8/20/24 10:46 AM, Cory.A.Reed--- via netcdfgroup wrote:
Classification: UNCLASSIFIED
======================================================
Hello all,
This is my first time writing in; I appreciate any advice I receive, and
I thank you in advance.
I have been using the Fortran 90 NetCDF module to convert a considerably
large dataset (21600 × 43200 elements of latitude × longitude) into
NetCDF format, and I inevitably encounter the same problem upon output:
my data variables are dimensioned as Var(Lon, Lat) instead of Var(Lat, Lon).
After I fill my latitude & longitude arrays with the appropriate values,
I execute the following code (I use cmod = NF90_64BIT_OFFSET because the
file size exceeds 2 GB):
call NF90_CREATE(FILE_NAME, cmod = NF90_64BIT_OFFSET, ncid = ncid)
call NF90_DEF_DIM(ncid, “Lat”, 21600, lat_dimid)
call NF90_DEF_DIM(ncid, “Lon”, 43200, lon_dimid)
dimids = (/ lat_dimid, lon_dimid /) ! Print statements always
show that this is equal to (1, 2)
! I define the coordinates as double precision floats, but the data
variable is single precision
call NF90_DEF_VAR(ncid, “Lat”, NF90_DOUBLE, lat_dimid, lat_varid)
call NF90_DEF_VAR(ncid, “Lon”, NF90_DOUBLE, lon_dimid, lon_varid)
call NF90_DEF_VAR(ncid, “Var”, NF90_REAL, dimids=dimids, var_varid)
After the above definitions, I assign units, names, etc., to the
variables, ALWAYS defining the latitude first, followed by the
longitude, and the ‘dimids’ array is always (1, 2) corresponding to
(lat, lon).
After exiting definition mode, I call NF90_PUT_VAR for latitude /first/,
then longitude, with print statements confirming that lat_varid = 1 &
lon_varid = 2.
Then, I run
call NF90_PUT_VAR(ncid = ncid, varid = var_varid, values = var_out,
start = (/ 1, 1 /), count = (/ 21600, 43200 /))
When I call ncdump -h to view the metadata of the output file, the
variable is ALWAYS of dimension (Lon, Lat) despite the above code, and I
need it to be in (Lat, Lon).
Please note that because the file is excessively large (the .nc file is
3.5 GB), I cannot simply modify the CDL text and call ncgen to re-create
the NetCDF file. Additionally, I do *not* have access to the CDO
operators and cannot install them. Therefore, my *only *possible method
(at least, to my knowledge) is via Fortran.
Thank you!
Best Regards,
Cory Reed, PhD
Geodetic Earth Scientist
National Geospatial-Intelligence Agency
Geodesy/Geophysics II (SFNAF)
Office of Geomatics
Unclass: (571) 558-5379
Mobile: (314) 608-9269
======================================================
Classification: UNCLASSIFIED
_______________________________________________
NOTE: All exchanges posted to Unidata maintained email lists are
recorded in the Unidata inquiry tracking system and made publicly
available through the web. Users who post to any of the lists we
maintain are reminded to remove any personal information that they
do not want to be made public.
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
https://www.unidata.ucar.edu/mailing_lists/
