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".


     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

        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.


    You must compile all the source files for a program, including the
    source files of any required module files, with the same -qextname

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:

  1. 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.

  2. 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:

    1. define the literal "7" to be of kind 4: CALL FLUSH (7_4)

    2. Convert "7" at run time to kind 4: CALL FLUSH (INT (7, KIND=4))

    3. 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".

  3. The BLACS and Scalapack libraries don't have default64 versions yet.

  4. 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 ( or Scott Deal (

Too Clever?

[ 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 ]]

Current Editors:
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
E-mail Subscriptions: Archives:
    Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.
Back to Top