ARSC HPC Users' Newsletter 260, December 20, 2002

SUPER-UX Run-time Parameters: Lessons Learned

NEC uses environment variables extensively at run-time to control elements of execution. For comparison, to dump performance data on Cray vector platforms, use the "hpm" command; on the NEC, an environment variable:


  CRAY:
    hpm ./a.out
  
  NEC:
    export F_PROGINF=DETAIL
    ./a.out
 

Change file format. On the Cray use "assign", on the NEC, a variable:


  CRAY:
    assign -N ieee_64 u:11
    ./a.out
  
  NEC:
    export F_UFMTIEEE=11
    ./a.out

Two problems were solved on the SX-6 last week with the "discovery" of the run-time parameters:

  • F_SYSLEN

    Increase maximum line-length permitted to the standard output file ( F_SYSLEN=nnn , default: 134 chars).

  • F_RECLUNIT

    Change the record length unit for unformatted, direct access I/O: ( F_RECLUNIT={WORD|BYTE} , default: WORD).

Details:

F_SYSLEN

The following Fortran WRITE statement and FORMAT runs without complaint on most platforms:


       WRITE(6, 50) (I, I=1, 50)
   50  FORMAT (1X, 50I3)

However, on the SX6, executing this WRITE results in an error message similar to the following:


   *** 186 Formatted record insufficient in WRITE UNIT=6 REC=1
       PROG=main_ ELN=12(400001390)

This and other runtime error messages are listed in Appendix D of the FORTRAN/SX Programmer's Guide. Looking up error number 186 we find that the cause of this error is an attempt to output in excess of a record length. Even more helpful is the suggested action of either correcting the formatted output statement (no, we know it is correct) or setting the sufficient record length to F_SYSLEN (sounds promising).

In section 2.4.1.28 of the FORTRAN/SX Programmer's Guide we find that the environment variable F_SYSLEN "sets the maximum number of characters that can be output to the standard output file (line length)." And section 2.4.1 reveals that the default value of F_SYSLEN is 134. But we are trying to output a line of 151 characters -- there is the problem.

So correcting this problem is a simple matter of increasing the value of F_SYSLEN -- in our example it must be at least 151. The syntax for setting environment variables depends on one's shell. Quoting section 2.4.1.28 again


      For sh:
             F_SYSLEN=nnn
             export F_SYSLEN
      For csh:
             setenv F_SYSLEN nnn

      Option value is:

      nnn The maximum number of characters that can be output to a
      standard output file.

F_RECLUNIT:

A different program was crashing when it attempted to read the third of eight records in a direct access unformatted file. The file in question was opened as follows, where nrecl==7372800:


        open(nu,file=filename,recl=nrecl,
     &       form='unformatted',access='direct')

And "ls -l" showed the size of the actual file:


  -rw-------    1 billybob   arsc       58982400 Dec 11 21:25 dat.r

Dividing the file size by the record length, 58982400/7372800, suggests the file contained 8 records. This, of course, was the expectation because the program runs fine elsewhere. On the SX-6, however, two records were read (incorrectly), and then the "read" statement crashed on the third record, with this error message:


    *** 151 Record number is out-of-range UNIT=11 FILE=dat.r REC=3
    PROG=dat_read_write.dat_read ELN=96(40003e294)

Unfortunately, the Fortran manual wasn't as helpful as it was for the F_SYSLEN problem described above. From appendix D of the fortran manual:


  151  Record number is out-of-range.

       Cause:
              The value was specified by a direct
              access input/output statement RECL
              specifier, but that value is outside the file
              range.
  
       Action:
              Correct the program, or reconstruct the
              file 

Still naive about file record length units, the next step was to collect more data. Setting yet another run-time parameter:


  F_FILEINF=DETAIL

dumps information on every file unit opened. Here's an excerpt:


  Format              :  UNFORMATTED
  Blank               :         ----      Access              :     DIRECT
  Recl (Byte)         :     29491200      Max Record No.      :          3
  File Size (Byte)    :     88473600      File Descriptor     :          3

What a head-scratcher!

The record-length (7372800) had become 29491200, and the actual file length (58982400) had become 88473600!

(Of course, you already know the answer...)

The default record unit is words, so the specified record length of 7372800 (words) was converted to 29491200 (bytes). The "Max Record No." of three is the number of the highest record started, and the record length times this max record number gives the (incorrect) file size.

Changing the record length units to BYTE,


  F_RECLUNIT=BYTE

fixed everything. The F_FILEINF excerpt now showed all the numbers back to normal:


  Format              :  UNFORMATTED
  Blank               :         ----      Access              :     DIRECT
  Recl (Byte)         :      7372800      Max Record No.      :          8
  File Size (Byte)    :     58982400      File Descriptor     :          3

---

It might be valuable to scan the entire list of environment variables in NEC's on-line documentation. (ARSC-sponsored rime users can read "news documentation" on rimegate for server location, login, and password).

Another Comment on Preprocessing Fortran Code

[ From Kate Hedstrom of ARSC. See the article on "(Not) Using cpp to Pre-Process Fortran Code" in issue #257:

/arsc/support/news/hpcnews/hpcnews257/index.xml

]

Our experience has been that using a cpp style of preprocessor with Fortran is simply not portable enough for us to trust the Fortran vendors.

We write the Makefile rules to invoke cpp ourselves. Even then we can't always find a cpp that does the job, and we carry around source code for one that works. Just today Cray's /opt/ctl/bin/cpp added spaces during substitution, creating something that isn't legal Fortran. And their f90's built-in fpp won't do recursive includes.

Works by ARSC Artists in UAF Museum Show

There's an exhibit, "Made In Fairbanks," running now at the UAF museum, which includes works by two ARSC staff members, Bill Brody and Miho Aoki.

In addition to their personal artistic pursuits, Bill and Miho are professors in the UAF Art Department, and provide expertise in visualization and animation to ARSC users.

For more on the exhibit, visit:

http://www.uaf.edu/museum/exhibit/special.html

Readings, Radio, Alaskan Wine

[ Guy Robinson's Christmas article, with an update from Singapore... ]

If you have listening time, the BBC is making a lot of its radio programs available on the web, not just as broadcasts, but creating web sites with listen on demand and archives plus extra information and links.

Some current favorites which you might like to look at over the holiday period, both serious science and fun:

http://www.bbc.co.uk/radio4/science/

This has a collection of links to programs on specific scientific topics and general magazine programs. Mostly it is 'this weeks' program but some series are kept complete. Another interesting listen is:

http://www.bbc.co.uk/radio4/science/rams/serendip4.ram

you'll wonder why we actually try to plan scientific research when the results of scientific accidents are described.

http://www.bbc.co.uk/radio4/comedy/

is a little more lighthearted. I like programs like the 'Newsquiz', 'Radioactive', and 'Just a minute'.

If you are into history there are a number of features around, including an exciting description of the voyages of Captain Cook. I've visited his statue in Anchorage, his birthplace museum in the UK and the house he lived in while in the UK, which is, for some reason, now in Melbourne, Australia:

http://www.bbc.co.uk/radio4/history/captain_cook.shtml

Another last minute idea for a present, did you know they make wine in Alaska? See:

http://www.greatlandwines.com/

And web sites for a new year of computing...

http://www.compunity.org/ , for the latest in openMP, http://www.cug.org/ , for details of the forthcoming Cray conference, http://www.sc2002.org/ , has all the papers from the recent SC2002.

---

Here are some late gift ideas, emailed from a hot and tropical Singapore:

An interesting book, "The Next Fifty Years; Science in the First Half of the Twenty-First Century":

Twenty-five of the worlds leading scientists look at what might happen in each of their areas of expertise.

Discussion includes getting a scientific base on Mars and prolonged presence in space, how our understanding of the genome might impact medical advances and lifestyles, and how having information and resources at our fingertips will change our behavior. Reading many of these, I am reminded of "Brave New World." Maybe we need to think what we want to be rather than let technology steer our evolution.

And another book: "Treks Not Taken: What If Stephen King, Anne Rice, Kurt Vonnegut, and Other Literary Greats Had Written Episodes of 'Star Trek: The Next Generation?'"

---

Let us know if Santa brought you anything good in the HPC line.

Quick-Tip Q & A



A:[[ I use a Fortran-callable C function, for example, something like this:
  [[
  [[      void Simple (int *i) {
  [[        (*i)++;
  [[      }
  [[
  [[ But Fortran is a case-insensitive language and while some Fortran
  [[ compilers (SGI, SUN, NEC, IBM) shift everything to lower case, others
  [[ (CRAY) shift to upper case. Some (SGI, SUN, NEC) also append an
  [[ underscore to function names. Thus, attempting to link a Fortran
  [[ program which has a "call Simple (I)" to the above would give an
  [[ "unsatisfied external" on any system.
  [[
  [[ If I change the name of the C function to "simple_", it links
  [[ successfully on an SGI, SUN, or NEC, but I'd rather make the rotten
  [[ thing portable!  Suggestions?



# Simple and straightforward:

  #if defined(SGI) 

 defined(SUN) 

 defined(NEC)
  #define Simple simple_
  #endif
   
  #if defined(IBM)
  #define Simple simple
  #endif
 
  #if defined(CRAY)
  #define Simple SIMPLE
  #endif
 
  etc...


# More ideas: Thanks, to Kate Hedstrom:

There are several things to try. One is a package called cfortran, which
is used by the NetCDF package:

  http://www-zeus.desy.de/~burow/cfortran/

Another option is autoconf, in which you can write tests for whether or
not the underscore is needed, upper/lower case, etc. The results of the
tests are usually the setting of C preprocessor #defines which can be
tested:

  #ifdef UNDERSCORE
        ...
  #else

These are usually used to set cpp macros.

The NCAR graphics package cooked up their own cpp macros, based not on
autoconf, but on a test of what system we are on. The resulting macros
look like:

  #ifndef NGCALLF
  #ifdef  UNICOS
  
  #define NGCALLF(reg,caps)       caps
  
  #elif   defined(RS6000) 

 defined(__hpux)
  
  #define NGCALLF(reg,caps)       reg
  
  #else
  /* Regular old BSD conventions */
  #ifdef  __STDC__
  #define NGCALLF(reg,caps)       reg##_
  #else
  #define NGCALLF(reg,caps)       reg/**/_
  #endif  /* __STDC__ */
  #endif  /* UNICOS else ... */
  #endif  /* NGCALLF */
  
and are used as:

  NGCALLF(gcaps,GCAPS)(arg1,arg2,...)

One weird thing about some compilers is that if there is an underscore
in the name, two get added to the end:

  foo_moo  -> foo_moo__

The NCAR people don't handle this because they know they don't have any
function names with '_' in the middle, at least in their C-Fortran
interface.

If I had to chose one, I would probably take the NCAR approach, but use
autoconf for the tests, rather than tying it to specific systems. This
way, it should work on the next new system without modification.

By the way, the passing of string arguments in function calls between C
and Fortran is another whole mess. The NCAR graphics code has a lot of
"#ifdef CRAY" tests just for that. I haven't studied cfortran enough to
know if they have solved that problem.




Q: A reader asked this... more of a poll than a quick-tip:

     "Do people use .f versus .f90 for free/fixed format? or do they use
     the -free and -fixed sort of compiler arguments?  Is anyone writing
     free format?"

   Any comments?

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