![[Menu Bar]](/images/header.gif)
| Newsletter Index | Quick-Tip Index | Search Newsletters |
[ 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:
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:
So, given this bit of history it is easier to understand the additions in Fortran 03 and Fortran 08. In Fortran 03:
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":
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.
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
#======================================================================
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 ]]
Contact:
Ed Kornkven ARSC HPC Specialist ph: 907-450-8669 Craig Stephenson ARSC User Consultant ph: 907-450-8653 Arctic Region Supercomputing Center University of Alaska Fairbanks PO Box 756020 Fairbanks AK 99775-6020
Send comments and questions to the current editors using this Contact Form.E-mail Subscriptions:
| Newsletter Index | Quick-Tip Index | Search Newsletters |
Arctic Region Supercomputing Center
PO Box 756020, Fairbanks, AK 99775 |
voice: 907-474-6935 |
email: 
home | search | about | support | news | science | resources