[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Cray T3E F90 interface
- To: NetCDF Mailing List <netcdfgroup@xxxxxxxxxxxxxxxx>
- Subject: Cray T3E F90 interface
- From: Mark Hadfield <m.hadfield@xxxxxxxxxx>
- Date: Tue, 12 Jun 2007 16:45:21 +1200
- Dkim-signature: v=0.5; a=rsa-sha1; c=relaxed/simple; d=niwa.co.nz; s=blizzard; t=1181623521; bh=q/wfdcfC8Fm7xom3/vZ3085V6d0=; h=Received: Message-ID:Date:From:Organization:User-Agent:MIME-Version:To: Subject:Content-Type:Content-Transfer-Encoding:X-Greylist: X-Scanned-By; b=LAp3NkEvICSzWiRWQwgbMEzc0ZQycs88JZNr9Ru7xTBbScBZeQ pMW/P5ugdkTeW6U1oet9UbBP6mF60XgkCFpRnWcu+RrCE09HW046VLDkHdTCJPKIVhS NyefMVPDJXu
- Keywords: 200706120445.l5C4jRrt020869
- Organization: NIWA
- Reply-to: Mark Hadfield <m.hadfield@xxxxxxxxxx>
- Sender: owner-netcdfgroup@xxxxxxxxxxxxxxxx
- User-agent: Thunderbird 2.0.0.0 (Windows/20070326)
Hello all
In case anyone is interested, I have got the netcdf-3.6.2 Fortran-90
interface working on a Cray T3E (don't laugh!). The main obstacle to
this was related to the usual T3E problem: the default REAL type has the
same number of bytes (8) as the default DOUBLEPRECISION. However the
netCDF Fortran 90 code defines two real kinds:
FourByteReal = selected_real_kind(P=6, R=37)
EightByteReal = selected_real_kind(P=13, R=307)
and then assumes that FourByteReal corresponds to REAL. This is an
incorrect assumption, with the result that all the nf90_*_FourByteReal
functions give SEGFAULTs. My solution was to strip out all references to
these functions in the interface declarations in
f90/netcdf_overloads.f90. The resulting library supports only 8-byte
reals (as does the underlying Fortran 77 library).
The purpose of the current message is twofold:
* To leave a record of this in the Googleverse, in the unlikely
event that anyone else needs to use the netCDF Fortran-90
interface on a Cray T3E.
* To ask, is there any interest from the developers in incorporating
my changes into the master code?
By the way, some time ago I explored the alternative approach of using
the compiler's "-default32" switch, which makes the default REAL 4 bytes
long. This turns out not to be a good idea, as it also affect the
default integer size in a way that breaks a lot of other code.
--
Mark Hadfield "Ka puwaha te tai nei, Hoea tahi tatou"
m.hadfield@xxxxxxxxxx
National Institute for Water and Atmospheric Research (NIWA)
===============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
===============================================================================
