BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP.
MINUTES of a Meeting held at British Computer Society, London, on Monday
3RD September 1979
G L Harding (Chairman) ECMWF
R S Blake ICL
R A Bowen European Space Operations Centre
P A Clarke Rothamsted Experimental Station
M R Dolbear BP, London
J K Gibson ECMWF
E Golton SRC Appleton Laboratory
D J Holmes Rolls Royce Ltd., Bristol
J D Murchland University of Leeds
D Nicholson ICL
K Normington Lanchester Polytechnic
N Pilemer NPL
T L van Raalte Ministry of Defence
I D Shepled Middlesex Polytechnic
A Tunnicliffe UMIST
R M Urry ICL
A Wilson ICL
J M Roberts-Jones (Secretary) Liverpool City Council
APOLOGIES FOR ABSENCE:
P D Bond, J D Wilson.
APPROVAL OF MINUTES: [4 June 1979]
Murchland said that he had not in fact undertaken to produce a paper
on macro processing; subject to this amendment, the minutes of the previous
meeting were approved.
It was reported that the officers of the Group had reached agreement
with the Secretary-General that the surplus arising from Fortran Forum
would be retained by the Group in a special account from which any
expenditure would be subject to the prior approval of the Vice-President
It was reported that the Group had not yet incurred any expenditure
in the current financial year. It had been proposed that Alan Clarke,
who would be in the United States shortly before the October X3J3 meeting,
should be asked to attend the meeting as an observer, and that his costs
of subsistence, estimated as £100, be reimbursed by this Group. Debate.
Roberts-Jones: Do we wish to set a precedent? We cannot get £100
out of £400 very often. Clarke: We should aim for regular representation
X3J3 meetings. There is the possibility of assistance from the Standards
Committee and from the Specialist Groups Committee. Harding: Since Alan
Wilson is both a regular attender at X3J3 meetings and a committee member
of this Group, we already have one representative. Two representatives
might be a luxury rather than a necessity. Our funds might be better spent
on activities within the United Kingdom, such as speaking at branch
meetings. Wilson: £100 is hardly generous; one could just scrape by on it.
As a vendor's representative, I concentrate on the array subgroup rather
than on the overall picture. I would very strongly welcome a further
UK representative. Clarke: Meek has drawn attention to there being no
impartial attender not linked to a manufacturer. Wilson: It must be
stressed that participation in X3J3 is on a personal basis. Affiliation
is recorded only for identification. Clarke: Other countries such as the
Netherlands regularly send observers. Harding: We would really like to
have someone attend regularly.
RESOLVED that subject to the approval of the Chairman of the Specialist
Groups Committee the Group should offer a grant in the sum of one hundred
pounds to Mr P A Clarke to be used to defray his expenses of attendance
at a meeting of X3J3.
Clarke noted an article by Jeanne Adams in The July 1979 ACM Sigplan
Notices. It appeared to imply that X3J3 was concentrating solely on free
form source, array operations, internal procedures, bit data type, record
data structures and enhanced calling mechanisms. There was a need for
input from this Group as to the directions in which X3J3 was proceeding;
there was a real danger that anything we did would be too late.
Harding felt that it was very difficult to deduce from the minutes
of X3J3 just what their attitudes were. Murchland said that Fortran needed
a specification of the same type as that produced for Ada; there was no
Wilson said that the status of Adams' article was similar to that of
the press releases issued after X3J3 meetings. It was not true that X3J3
had no overall plan. Brainerd's timetable had been approved by the
Boulder meeting. The main headings in that timetable were:
Array processing (core and extensions)
Implicit dynamic storage allocation
Intra-program control structures
Global data and internal procedures
Bit data type
Character data extensions
Rules for applications modules
Applications module management
The obsolete module
Outline of [new draft standard] document
Wilson reported on the current status of proposals for array extensions.
A core proposal had passed dealing essentially with arrays as single
entities, requiring that each array in an expression be of identical
size and being interpreted element-by-element. Intrinsic functions were
extended quite elegantly on that basis. The proposal did not address
questions of slicing because of argument passing considerations not yet
Extensions were still being considered. In particular, there was
a recognised need for dot product and matrix multiplication operators, and
for various intrinsic functions such as transposition of a square array,
for inversion and for location of the largest element. One criterion
must be the desire to avoid DO-loops whenever possible.
The driving force behind the array extension proposals was the need
to exploit parallel architectures- Much of the power of array processing
extensions currently available arises from the ability to control which
elements were affected. The WHERE statement was a very powerful tool.
Murchland: The emphasis on implied DO-loops conveys a definite
flavour of dense arrays. Wilson: Yes, we are starting there, and will
move on to sparse arrays later.
Clarke: There are in practice problems caused by the values for some
observations being unknown. what are the proposed methods of array i/o?
Wilson: This will follow in due course.
Wilson: Introducing matrix inversion invites controversy. The
problems are of the same nature as those that had to be faced when transfer
functions were first introduced into Fortran. One needs to assure
Dolbear: will we have user functions of type array? Wilson: This
has been left to the extension package. once we start manipulating
slices, a quite considerable apparatus becomes necessary to support
Clarke: Genstat has a heap mechanism for temporary work arrays.
Will Fortran address the storage allocation problem? Wilson: X3J3 has
resolved that a modest degree of dynamic storage allocation is necessary.
Currently, the allocation is compiler-controlled. There is an intention
to consider explicit dynamic allocation. Murchland: Surely one could
simulate a stack in Fortran 66. Dolbear: Not very well. We need to be
able to determine the storage requirement at runtime. Golton: Now we
have virtual storage, do we really need dynamic allocation? Dolbear:
Not all machines have virtual storage. Roberts-Jones: Even with virtual
storage, it can become very difficult to map everything into a single
one-dimensional address space.
Harding: Where are we going with recursion? Wilson: Recursion and
stacks go hand-in-hand in Algol-type languages. In Fortran, there can
be no access to non-locals so that displays are unnecessary. But there is
a problem with entities initialised by the DATA statement. Were they
preset just once or at the start of each invocation? "The ad hoc nature
of Fortran really sticks out here."
Golton: We want dynamic storage allocation now - not way in the future.
Dolbear: Perhaps it isn't yet well enough understood. Golton: I understand
it. I want to use half a megabyte for a few seconds and then release it.
But I can't.
Clarke: There will be problems in passing arrays because the current
mechanism is not adequate. Dolbear: The real problem is with slices.
Perhaps we need a user-defined array successor function.
Wilson: Parallel architectures really demand a fresh approach.
Consider sorting. Once you are able, in parallel, to compare each pair of
consecutive elements in an array and so locate the runs, you can implement
a sort perhaps 100 times faster than Quicksort. we must recognise that
a specification of requirements will not be a recipe for implementation.
Murchland: Surely extensions for parallel hardware give rise to
overheads. Harding: The Cray-1 and the DAP are very different architectures.
Can we afford to have different extensions for each? Roberts-Jones: Do
array extensions involve additional costs for serial processors?
Wilson: No - just the opposite.
Dolbear: Many of these things are already in Basic without apparent
increase of cost, but each extension brings problems - not least the
increasing size of the language and of its manual.
Golton drew attention to the problem of portability caused by differing
word lengths. He felt that one should specify storage rather than
precision. There followed a general discussion on the questions of precision
and range. Murchland wished to see generic functions as in Ada. Clarke felt
that one should only need to specify the algorithm to be used. Dolbear
thought that too ambitious and cited the problems encountered by NAG, such
as with specification of constants. Golton wished to be able to force a
compiler to use differing precisions. Gibson mentioned the problems caused by
too much precision in Euler integration. Harding felt that the real need
was to provide a capability for the unsophisticated user.
Harding wished to see the Group set precise targets as to its work.
What should the Group concentrate on? Should X3J3 be asked how best this
Group might participate in development of the next standard? Clarke felt
that the time was ripe for a further questionnaire to establish the views
of users. He would be willing to collate the replies.
The Secretary reported on the June meeting of the Specialist Groups
It had been decided that BCS'79 should be repeated. There would be
a funfair in 1980 and a second full-scale conference in 1981, either in
early January or at Easter, not necessarily in London. Specialist groups
should now be starting to prepare their presentations.
On the reorganisation of the Society in October, every member
would be encouraged to be affiliated to a specialist group. The implications
of this on the size and cost of mailings seemed to be uncertain.
A letter had been received from Mr W Little, a lecturer at Paisley
College of Technology, suggesting that the group should compile an index
of Fortran 77 implementations and of their deviations from the standard.
It was felt that that such a task was beyond the present resources. Mr
Little also asks for information on "the availability and cost of any
program products which will relabel and/or verify Fortran 66 and/or
Fortran 77 source programs". Can anyone offer advice?
John Wilson, of Leicester University, has the source tape and
documentation of FCVS 78 Version 1.9, a system produced by the US Navy
Federal Cobol Compiler Testing Service to audit implementations of the
Fortran 77 subset language. Copies can be made available for a
nominal charge to anyone sending him a magnetic tape and specifying the
required recording standard (7-track 556 or 800 bpi, 9-track NRZ1 800 rpi,
or 9-track PE 1600 rpi).
[The next meeting was held on 5 November 1979]
FORTRAN IN METEOROLOGY.
Rex Gibson of ECMWF gave a talk on the use of computers in weather
forecasting. His transcript is attached.
METEOROLOGICAL ASPECTS OF FORTRAN
This paper outlines the approach to FORTRAN adopted in
the European Centre for Medium Range Weather Forecasts
(ECMWF) by the Research Department, with particular
reference to the Centre's grid point forecast model.
Wider meteorological programming applications within the
United Kingdom Meteorological Office are drawn on as a
result of the author's experience. An attempt is made
to present reasons for the acceptance of FORTRAN as the
most suitable language for meteorological programming,
and a list of additions to the language, desirable from
a meteorological standpoint, is presented.
2. Meteorological Computer Applications
Figure 1 illustrates the diversity of primary meteorological
data. Observations of various aspects of the weather are
collected at collecting centres throughout the world. Many
of these observations are coded into a digital code, often
in the form of groups of five decimal digits, and distributed
throughout the world via the international Meteorological
Telecommunications Network. Such digital codes were used
long before computers found their place in Meteorology -
they provided a useful international language for the exchange
Secondary data is produced in various forms as a result of
processing the primary data. Primary data is produced at
various intervals, but frequencies are generally between 30
minutes and 12 hours, with a good coverage of global data at
6 hour periods. In consequence the data processing problem
is a very important aspect of meteorological computer applic-
2.2 A Meteorological Operational Suite
Figure 2 is based on a simplified form of the system used
at ECMWF, and illustrates the main components of a typical
meteorological operational suite. Primary data is decoded,
subjected to quality assurance, and archived. An analysis
programme, often in the form of an optimal interpolation
scheme, inserts observed conditions into a background "first
guess" field, which may have been produced by a forecast, or
which could be a climatological field for the month in question.
The result of the data insertion, interpolation and analysis
is a dataset that could be used as input to a numerical fore-
cast model. However, such data is often not well balanced,
and this lack of balance is usually removed by an initialization
procedure. As earlier stated, a good coverage of primary
data is usually available at 6 hour intervals; in
consequence the initialised data is subjected to a 6 hour
forecast, the result of which becomes the new "first guess"
field. When an extended forecast is required, the forecast
is allowed to continue up to the appropriate point.
Data produced by the analysis, initialization, and forecast
is processed to produce plots, data for distribution (in the
case of ECMWF, data to be transmitted to member states),
diagnostic data, and data to be archived.
2.3 Climatological Applications
Climatology is an important branch of Meteorology. The study
of what is normal, and what is extreme can give valuable
guidance to industry, and result in a degree of safety in
building, etc., otherwise not possible. Numerical models
can be designed to simulate the climate and predict the impact
of changes. Such models may, when fully developed, be capable
of predicting the effects of atmospheric pollution, of climat-
ological change on the weather, etc.
The climatology of a particular location or area can only be
studied if the required data is available. This results in
the need for climatological archives which must be "topped
up" with data as they become available. This archive may be
required to provide data by station, by area, by level in the
atmosphere, by periods of time commonly of 30 years span, for
data covering the whole earth. In addition, long range weather
forecasting by fitting techniques demand that analogues of
monthly conditions be archived for as far back in time as
possible. Such analogues can then be compared with those of
the current month so that the subsequent weather for the
matched analogues may be used as a guide to forecasting the
general prospects for next month's weather.
Climatological data may be used to aid the planning of new runways
at airports, to assess stress factors in building, to assist in
the design of oil rigs, to help design smoke stacks so
as to disperse the resulting smoke, and in many other ways
that provide for the benefit of the public and of the
2.4 Other Meteorological Applications
Many other meteorological computer applications exist.
In particular, research into cloud physics, solar radiation,
fluid flow, the physical processes in the atmosphere, atmos-
pheric turbulence, etc., etc. are examples of areas in which
programming of the typical scientific nature has its part to
3. The role of Fortran
3.1 Why Fortran ?
Figure 3 contains a summary of the main reasons for the
choice, if that is the correct word, of FORTRAN as the
most commonly used computer language in Meteorology. An
additional factor not included in the list is the avail-
ability of suitable high level languages on specific computer
The choice of anything but a high level language for general
programming in meteorology would severely restrict the
application of computer processing to many meteorological
problems. In the early days of computing, only low level
languages were used. The manpower required, and the slow
speed of programme development resulting from this approach
meant that only a limited number of tasks of a highly
repetitive nature could be computerised in addition to the
operational suite. Developments within the operational suite
were also slow, as re-coding could prove prohibitively
Due to the size of the data processing problem, and to the
amount of work to be performed by many of the programmes in
a time critical environment, meteorological applications
require very efficient object code. Because of this it is
often necessary to code critical routines in assembler language
Thus interface with such routines must be simple and efficient.
This is not always true for some high level languages, where
dope vectors, setting up special environments, etc. can result
A widely accepted language with future support and good library
facilities restricts even more the choice of language. Changes
in the language similar to the change from Algol 60 to Algol 68
would be unacceptable in terms of software investment.
These reasons leave virtually only one language sufficiently
widely implemented to be acceptable - FORTRAN.
3.2 What Fortran ?
Figure 4 indicates the general approach to the use of
Fortran within the research department of ECMWF. The
ANSI standard is not strictly maintained with regard to
features commonly available on many installations. Some
features more appropriate to the 77 standard than the 66
are adopted where most Fortran 66 compilers are capable of
compiling object code that executes correctly. Care is taken
that features such as zero trip loops execute correctly in
both the 66 and the 77 sense.
It is usual to use OPENR, READR, WRITER, CLOSER, and CHECKR
for random input/output operations, OPENS, READS, WRITES,
CLOSES, and CHECKS for sequential input/output. Resulting
transfer of data is assumed to be asynchronous. The actual
routines may then be coded in highly machine dependent code
to produce the most efficient input/output possible.
3.3 Some features of the Olympus System
LOCATION INTEGER REAL LOGICAL
GLOBAL (COMMON) L,M,N A-G NL
LOCAL I Z IL
ARGUMENTS K P KL
LOOP INDEX J
Figure 5 illustrates the naming convention used in Roberts'
Olympus System. It enables easy recognition of both the type
(real, integer, etc.) and the nature (local, global, dummy
arguments, etc.) of variable names used within a programme
A second property of the Olympus system is as an aid to good
documentation. Routines are divided into chapters and sections
with a numbering system which carries through to the label
numbers of statements, and which provides the means for
cross referencing with external documentation.
Many variables are allocated to named common blocks, and can
thus be accessed globally. This reduces the need for commun-
ication by parameter lists, often an expensive overhead if
the lists are long. For meteorological applications it is
often required to read, process, and write large data records.
These are usually held in blank common, and their size may
often be data related, Using blank common in this way enables
"programmes" to be written as sets of pre-compiled routines
in object code, invoked by calling the master routine from a
4 line main programme which defines a suitable length blank
COMMON B (50000)
Olympus contains a set of utility routines to aid debugging.
Variables can be printed, arrays or array sections can be
printed and annotated without the need to code a single FORMAT
CALL IVAR (SHINTVAL ,INTVAL)
INTVAL = value of intval
to be printed.
Finally, adoption of the general principles of Olympus has
resulted in the creation of well annotated, clear source
code which is relatively easy to maintain and modify,
A sample routine is presented as Figure 6.
3.4 Vector Processing
Meteorological programmers have been keen to use
whatever enhancements have been forthcoming from the
computer manufacturers. With the advent of parallel
processors "hand scheduling" of FORTRAN became popular.
Lengthy processes such as divisions were moved away from
similar processes in the hope of gaining as much processing
overlap as possible. The advent of "loop mode" or "instack"
features associated with fast loop computation for small,
tight loops resulted in use of array referencing, which depended
on repetitive specification of similar subscript expressions
Q; in the knowledge that an optimising compiler would reduce the
resulting object code to below the magic number of instruc-
tions which could be locked into the instruction stack. It
was in this atmosphere that meteorological computer applic-
ations moved into the world of vector processors.
Although much had been said to the contrary, it was our
experience that the Cray Fortran Compiler (CFT) was able to
handle the type of code written for parallel processors and
produce good vector code. Indeed, attempts to open up the
tight loops to enable longer loops of vectorisable instructions
did little if anything to improve efficiency. As CFT regards
inner loops as its target for vectorization, the type of
programme structure often found in code obtained for parallel
processing produces good object code with very little alteration
Some guidelines soon became apparent:-
a) Iterative solutions do not vectorize.
b) Numerical algorithms which yield vector code may not
be the most obvious; sometimes methods previously
discarded as inefficient may yield to vectorization
and produce an efficient vector algorithm.
c) Vector code may not be as efficient as the scalar
code of an unmodified algorithm. Only vector
algorithms that produce results faster should
d) Vector algorithms must produce acceptable results.
Those which do not must be discarded.
CFT provides some aids to vectorization, such as
i) Merge functions. These compute the alternative
result for all values, and merge in the values
required. Care is required not to perform an
illegal operation (e.g. divide by zero) during
the computation of one of the results NOT required.
Also, a merge function may not be as fast as scalar
code where the number of merges is small, and the
amount of computation is large.
ii) Summation, inner products, etc. can be obtained
using special features of Cray-1 hard ware. They
can be invoked using special routines written in
iii) Some CFT library routines are relatively expensive.
Algorithm modification can sometimes lower the cost
e.g. consider Kessler's evaporation formula
E = α1(qsat - q)MR
where α1 = 0 for q > qsat, MR ~ density of rain
This leads to an algorithm for determining the evap-
oration of rain for fraction ap of a grid area with
Ec = ap α1(qsat - q) ( √(σ/α2) × (pc/ap) ) ^ α3
where α1 = 5.44x10-4, α2 = 5.09x10-3, and α3 = 0.5777,
all other variables on the right hand side being available.
Exponentiation is a slow process compared to
square root. Thus it would be desirable if
α3 could be 0.5. Examination of the above
expression yields a reasonable approximation
by changing α1 to 6.94 x 10-4, α2 to 7.35 x 10-3,
and α3 to 0.5. Square root library function can
then be used instead of exponentiation.
4. A Fortran Wish List
Below I present a Fortran wish list containing some features
I would like to see incorporated into Fortran.
An array extension to FORTRAN is a subject about which much
has recently been written and discussed. If it does not come
soon, most users of vector processors will have produced their
own routines, and we will have the usual problems of porta-
bility, non-standard interfaces, etc. How it is implemented
I do not very much care so long as it produces readable code.
I am prepared to write
A (*,*) = B (*,*) * C (*,*)
or A = B * C
or CALL MATMUL (A,B,C)
plus whatever further arguments are required by MATMUL. I
also wish to specify an array process which is clement by
element in nature instead of a DO loop.
Standardisation of input/output has begun with the END
and ERROR exits. Progress should be continued to standardise
sequential and random asynchronous I/O. This would remove
many portability problems. Manufacturers not able to offer.
asynchronous features would implement the routines as
synchronous. Those unable to offer random I/O would simulate
random I/O using sequential processing.
A symbolic register notation using reserved arrays is perhaps
more applicable to Cray Fortran than to the language in
general. The Cray-1 has 8 vector registers each of which is
64 words long. Use of symbolic register notation could convey
information to the CFT compiler concerning results which need
not be stored.
Such results could be retained in a vector register in cases
where it may not be apparent even to a good optimising
compiler that the results are temporary variables. Even with
scalar computation it is a well known fact that many Fortran
compilers make poor use of the registers at their disposal.
A means of conveying suggestions concerning register use could
be a powerful addition to the language, and could be imple-
mented so that the symbolic register variables could be used
as normal variables at the compiler's discretion.
The final area where I would welcome extensions to the language
is that concerned with calling standard or semi-standard routines
There are many low level functions and high level utility
packages commonly available to Fortran on various installations,
e.g. SORT/MERGE, SHIFTL (shift left n bits, where n is supplied),
SHIFTR (shift right n bits), etc. It would be helpful if a
basic set of high level packages were standardised so that
their function would be defined and their interface (arguments)
would be the same on all installations.
FORTRAN, though not the most graceful or grammatically
pure language, has many attractive features. It can
usually be compiled to produce efficient object code; it
is easy to learn and to use; its lack of terminators,
sparsity of reserved words, and use of a basic character
set contribute to the production of relatively bug-free
source code. It has stood the test of time in that the
77 standard is to a large extent a superset of the 66
standard, and downward compatibility is more or less
For meteorologists and many others, FORTRAN has become
virtually the only acceptable high level language. At a
time when many new languages are being developed, and when
some established languages have suffered drastic changes,
the stability of FORTRAN has been one of its chief virtues.
If FORTRAN is to maintain its attractions, three guiding
principles must be adopted when future changes to the
language are made: -
a) The ability to compile efficient object code
must be maintained (or improved).
b) Downward compatibility must be maintained.
c) Features which alienate the user must be
Roberts, K.V. An introduction to the OLYMPUS system.
Computer Physics Communications,
7 (1974), 237-243.