ARSC HPC Users' Newsletter 337, March 31, 2006

What's New and Old in Fortran

[ Thanks to Lee Higbie of ARSC for this article. ]

The new Fortran standard, sometimes called "Fortran 2000" or "Fortran 03," is in the final stages of approval (see J3/04-007 at j3-fortran.org ) and some features of "Fortran 08" have been settled. It is not reasonable to cover every nit that J3 has, but I'll hit some of the highlights, describe some of the process, and hopefully help you prepare and modernize.

Because of the lengthy process between proposal of a feature and agreement on a modification or addition to the standard and from that to its final approval, many features are available in some compilers long before they are in an accepted standard. (I proposed the forall statement about 1980. It was added to the standard in 96.) By contrast, because of implementation difficulty and complexity, some standard features are not efficiently implemented in compilers until long after the standard is approved. (It seems to me to take about a decade for a significant compiler feature to mature.)

The current process, as I understand it, is that J3 proposes technical changes, in effect it writes the standard, and WG5 approves it. j3-fortran.org has more details.

A few bits of trivia. The first Fortran standard, for Fortran 66, was 36 pages long, more than an order of magnitude larger than any previous standard. Earlier standards dealt with issues such as electrical and mechanical connectors and were a few pages long. The Fortran 77 standard was another order of magnitude larger. Though the standard has continued to grow, most of the additions since 1980 have come from the addition of indexes and appendices. By the time of the Fortran 77 standard, in 1978, the name had grown up and was properly spelled with only an initial capital letter.

Fortran 90 was years late arriving, apparently because of disagreement on the committee (www.cisl.ucar.edu/tcg/consweb/Fortran90/scnhist.html). One result has been that Fortran has disappeared from the radar in most academic circles. Fortran's use is now virtually restricted to scientific and engineering computation where code execution speed is of paramount performance.

First some background. Fortran 90 introduced:

  • Free format source code (Previous code was punched-card image based. This slow arrival, alone, was reason enough for Fortran's near abandonment.)
  • Case, do while, and modules. (Block-if only dates to Fortran 77.)
  • Data structures, array syntax, dynamic memory allocation. Soon, Fortran 95, which was a minor revision and fixup for Fortran 90, added features for multiprocessing:
  • Forall statement (telling the compiler that do loop iterations can be done in any order).
  • Pure and elemental procedures.
  • Some additional functions.

By the time of Fortran 95, the J3 committee started seriously cleaning up some of the early, problematical constructs. Features that were made officially "obsolescent" included:

  • Arithmetic if statements: E.g.: IF (TEST) 12, 34 and, even worse, IF (TEST) 1, 23, 45.
  • Shared terminating statement for several do loops
  • Alternate returns, alternate entry points, computed and assigned gotos.
  • Fixed form source. In other words, you should not use the punch-card image format that all the compilers still allow for Fortran.

So, given this bit of history it is easier to understand the additions in Fortran 03 and Fortran 08. In Fortran 03:

  • Interoperability with C is built in, finally. The language has gotten to the point where many of the requirements for a C routine no longer exist, but the interface is now "standardized."
  • Library functions to access the host environment.
  • Pointers to procedures and procedure intent specification.
  • Exception handling in the form of support for the five IEEE floating point exceptions.
  • Some support for object oriented programming (polymorphism, overloading, abstract data types, ...)
  • Allocatable arguments and enumerated data types.
  • Enhancements, or at least additions to, the I/O operations.
  • And, of course, a gaggle of minor refinements and additions. (They're minor to me. Your mileage will differ.)

I think the subroutines to retrieve the command invoking a program and accessing environment variables are the most important for portability. It is now straightforward, for example, to determine the operating system shell or to access the type of machine executing a program. Or, which is probably more important, file names can be absolute by using standard variables such as $ARCHIVE, $TEMP, $HOME etc.

In "Fortran 08":

  • The big addition that has already been approved for "Fortran 08" is Co-array syntax. This allows a simple, Fortran-style notation for accessing data that is spread across processors. The important result of providing this as part of the language is that the compiler, at least in principle, can optimize the type of access to data.

My recommendation for any new MPI code development is that it be prototyped in Co-array Fortran. This forms a documentation base for the largely inscrutable MPI syntax forced on programmers now. When the Co-array Fortran is compilable, its performance should be better than the MPI version. (Co-array Fortran, by the way, is available on klondike via ftn's "-Z" switch.)

By 1960, Fortran allowed nearly all scientific and engineering programming to be done with no regard for register allocation and other bit-twiddling level concerns. Finally, five decades later, the same level of facility will be available for multi-processing programs. Actually, Fortran took about 15 years to become available and Co-array Fortran has taken about 15 years since multi-processing became the norm for large scientific/engineering programs.

--

In a future article, we'll discuss other Fortran 2003 and 2008 features which vendors have already made available to users of HPC systems.

Pat Tracing Modified

In programming environment 5.4, Cray altered the behavior of pat tracing. If you have instrumented a code, you need to set this variable in the runtime enviroment for trace data to be stored to the .xf file:


     [ksh]  export PAT_RT_SUMMARY=0"
     [csh]  setenv PAT_RT_SUMMARY 0"

As before, you must also be sure this variable is not set:


   PAT_RT_EXPERIMENT 

Here's the updated version of our pattrace script, which first appeared in > issue 311 :

This is intended to simplify using PAT to produce a tracing report. First run it with "-h" for instructions on preparations, and then run it againt the .xf file to produce the report:


Script name: ./pattrace
#======================================================================
#!/bin/ksh

# 
# This script generates a PAT report.  
# Tom Baring, ARSC, Mar 2005
# 

SCRPT=$(basename ${0}) 
SYNTX="Syntax: $SCRPT [-h] <instrumented_exec_name> <name_of_xf_file>" 
case $1 in
  "-h" ) 
echo
echo $SYNTX
echo
echo "Preparation:"
echo  " 1. Instrument the executable: pat_build -w -t <routine_list> <executable_name> <instrumented_exec_name>"
echo  " 2. Unset the PAT_RT_EXPERIMENT environment variable, if it's set"
echo  " 3. In the PBS script (or interactive environment) set PAT_RT_SUMMARY:"
echo  "    [ksh]  export PAT_RT_SUMMARY=0"
echo  "    [csh]  setenv PAT_RT_SUMMARY 0"
echo  " 4. Run the instrumented executable. E.g., mpirun -np 4 ./<instrumented_exec_name>"
echo  " 5. This produces the .xf file needed by this script "
return 0 ;;
esac

EXEFILE=${1:?$SYNTX}
XFFILE=${2:?$SYNTX}
RPTFILE=${XFFILE}.${SCRPT}.rpt

B="-b ssp,function,callers"

echo "Generating report:   ${RPTFILE}"
pat_report $B -i $EXEFILE -o $RPTFILE $XFFILE
#======================================================================

Quick-Tip Q & A



A:[[ I've got a misbehaving file with lots of hidden and weird characters. 
  [[   Here's some sample output from "od -c" :
  [[
  [[ %    od -c file.txt
  [[ 0000000  \r   t   h   i   s       i   s       a       l   i   t   t   l
  [[ 0000020   e       d   e   m   o       o   f       t   h   e     311    
  [[ 0000040   f   e   a   t   u   r   e   s       o   f  \r   t   h   e    
  [[ 0000060   a   u   t   o   c   o   r   e   c   t     311       f   u   n
  [[ 0000100   c   t   i   o   n       o   f       t   h   i   s       w   o
  [[ 0000120   r   d       p   r   o   c   e   s   s   o   r     252   ,    
  [[ 0000140   h   e   r   e   .      \r  \r  \n
  [[
  [[  From the 
quick-tip in issue 287
 I know how to get rid of these
  [[  characters, but first I need to know what they are.  There must be
  [[  some pipeline of Unix utilities that would convert the "od -c" output
  [[  into a simple list of the characters that appear in the file. Any 
  [[  help?



#
# Thanks to Olivier Golinelli
#

  Perhaps, 
    od -c -w1 file.txt 
 awk '{a[$2] = 1} END {for (i in a) print i}'
  is an answer.

  Option "od -w1"  : output 1 byte per output line
  
  In the small awk program : "a" is an associative array (dictionary in
  Python language).  The instruction,

      "for (i in a) print i"

  prints the keys of this array.


#
# One from the editor
#

    od -c file.txt 
 cut -s -d' ' -f 2- 
 tr -s ' ' '\n' 
 sort -u

  Assuming all the "interesting" codes are represented by od with two or
  more characters, you could then pipe to:  egrep -v "^.$"

  $ od -c file.txt 
 cut -s -d' ' -f 2- 
 tr -s ' ' '\n' 
 sort -u 
 egrep -v "^.$"

      252
      311
      \n
      \r


Q: I want to "diff" two files.  The catch: one of them is on a remote system.
   Is there an alternative to "scp'ing" or "ftp'ing" the remote file to
   my local system and doing the diff there?

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