ARSC HPC Users' Newsletter 288, March 12, 2004
SP, xlf flush_ and -qextname
An IBM XLF Fortran user experienced trouble porting his code this week. Compilation was fine, but the linker reported the routine, FLUSH, as an unresolved external reference.
The solution was to append an underscore to the name, like this:
CALL FLUSH_ (7) !!! Flush IO buffer to file
Another alternative would have been to link with the xlf option, "-qextname". From "man xlf".
-qextname[=name1[:...[namen]]] -qnoextname Adds an underscore to the names of global entities (external names), except for main program names.
Here's an explanation of the situation, from the XL Fortran User Guide:
The -qextname option helps to port mixed-language programs to XL Fortran without modifications. Use of this option avoids naming problems that might otherwise be caused by: - Fortran subroutines, functions, or common blocks that are named main, MAIN, or have the same name as a system subroutine - Non-Fortran routines that are referenced from Fortran and contain an underscore at the end of the routine name Note: XL Fortran Service and Utility Procedures, such as flush_ and dtime_, have these underscores in their names already. By compiling with the -qextname option, you can code the names of these procedures without the trailing underscores. - Non-Fortran routines that call Fortran procedures and use underscores at the end of the Fortran names - Non-Fortran external or global data objects that contain an underscore at the end of the data name and are shared with a Fortran procedure If your program has only a few instances of the naming problems that -qextname solves, you may prefer to select new names with the -brename option of the ld command. Restrictions: You must compile all the source files for a program, including the source files of any required module files, with the same -qextname setting.
X1, ftn -s default64
The Cray X1 Fortran compiler, ftn, has the option "-s default64" which changes the size of default type variables to 64-bits. For instance,
REAL :: x !!! would become 64-bit with -s default64 REAL(KIND=4) :: x !!! would remain 32-bit with -s default64 INTEGER :: j !!! would become 64-bit with -s default64 INTEGER(KIND=4) :: j !!! would remain 32-bit with -s default64
It's tempting to apply the -s default64 option to your compilation without a second thought, especially if porting from the SV1ex or T3E, where 64-bits is already the default. However, unless you know you need 64-bit precision for all default type variables, you might try -s default32 (the default default :-) or -s real64, first.
Here are some considerations:
If 32 bits provide adequate precision, there are two obvious advantages to using it. The required memory is halved for the affected arrays and memory bandwidth (as measured in words) can potentially be doubled.
Some library calls require 32-bit, only, integer arguments. For instance, our friend FLUSH, and OMP_SET_NUM_THREADS. A program containing this call:
CALL FLUSH (7)will core dump if compiled with "-s default64" because the literal integer "7" is stored with a 64-bit representation while "FLUSH" requires a 32-bit argument.
Assuming you need 64-bit default integers and compile with -sdefault64, here are three possible code modifications to solve the problem:
define the literal "7" to be of kind 4: CALL FLUSH (7_4)
Convert "7" at run time to kind 4: CALL FLUSH (INT (7, KIND=4))
Call the flush routine with a variable or parameter of kind 4: INTEGER(KIND=4), PARAMETER :: fileunit=7 ... CALL FLUSH (fileunit)
Alternatively, when compiling with -s default64 , also compile with: -A FTN_LIB_DEFINITIONS This provides generic interface headers to some of the library routines (including FLUSH). Note, though, that some other library routines, like OMP_SET_NUM_THREADS, aren't handled by "-A FTN_LIB_DEFINITIONS".
The BLACS and Scalapack libraries don't have default64 versions yet.
If you do need -s default64, note that REALs become 64-bit, "single precision" becomes 64-bit, and "double precision" becomes 128-bit. Unless you really need 128-bit precision for DOUBLE PRECISION variables, you should also compile with -dp, which disables double precision and keeps DOUBLE PRECISION variables at 64-bits.
Drumming on the Access Grid, March 25th
You are invited to join ARSC and the UAF Music Department in an event on the access grid, Thursday, March 25 at 1pm Eastern Time.
Local UAF folks: Butrovich 109 9am Alaska time
We will be presenting Valerie Naranjo, Percussionist for the Saturday Night Live Band in a one hour clinic/demonstration.
In addition to playing percussion and arranging music for the Saturday Night Live Band, Ms. Naranjo has recorded and performed with The Philip Glass Ensemble, David Byrne, Tori Amos, Selena, Airto, and the international percussion ensemble, MEGADRUMS, which includes Milton Cardona, Zakir Hussein, and Glen Velez. Ms. Naranjo performs with and arranged for the five percussionists in Julie Taymor's THE LION KING.
Ten access grid sites from as far away as Manchester England have already signed up to participate.
For more information, contact Paul Mercer (firstname.lastname@example.org) or Scott Deal (email@example.com).
[ Thanks to Jim Long for passing this along... ]
Seen in a signature file:
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
-- Brian Kernighan
Quick-Tip Q & A
A:[[ Is there a way to invalidate my kerberos ticket before I trot off [[ to lunch? It seems a little risky to leave valid tickets sitting on [[ my workstation when I'm not around. # # Thanks once again to Greg Newby: # kdestroy. or "kdestroy -a". "man kdestroy" for information. This will work on your Unix/Linux workstations, or via the command line on Mac OS X. If you're using the Windows Kerberos package, you can just select a ticket in the Kerberos window, then hit the "delete" key. Q: I almost always need my loadleveler script to start executing in the same directory from which I "llsubmit" it. Thus, my first executable command is generally a "cd" right back to whatever that directory is. Sometimes I copy a script to a new directory and forget to change the "cd" command, and of course then everything goes wrong. Any advice?
[[ Answers, Questions, and Tips Graciously Accepted ]]
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669 Kate Hedstrom ARSC Oceanographic Specialist ph: 907-450-8678 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
Subscribe to (or unsubscribe from) the e-mail edition of the
ARSC HPC Users' Newsletter.
Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.