BRITISH COMPUTER SOCIETY - FORTRAN SPECIALIST GROUP.

MINUTES of a Meeting held at British Computer Society, London, on Monday

3RD September 1979

PRESENT:

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.

MATTERS ARISING:

        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

(Technical).

FINANCIAL REVIEW:

        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.

X3J3 ACTIVITY.

        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

general plan.

        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

Event handling

Processor directives

Procedure interfaces

Generic functions

Precision

Bit data type

Environmental inquiry

Data structures

Character data extensions

Language architecture

Core criteria

Rules for applications modules

Applications module management

The obsolete module

Outline of [new draft standard] document

Program form

Character set

Input/output enhancements

ARRAY EXTENSIONS.

        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

resolved.

        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

regularity.

        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

argument passing.

        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.

PRECISION.

        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.

GROUP OBJECTIVES.

        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.

BCS BUSINESS.

        The Secretary reported on the June meeting of the Specialist Groups

Committee.

        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.

OTHER BUSINESS.

        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

J.K. GIBSON

1. Introduction

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.

2.1 Data

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

of information.

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-

ntions.

2.2 A Meteorological Operational Suite

Figure 2.

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

economy.

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

play.

3. The role of Fortran

3.1 Why Fortran ?

Figure 3.

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

installations.

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

expensive.

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

in difficulties.

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.

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

VARIABLE NAMES

LOCATION               INTEGER              REAL              LOGICAL

GLOBAL (COMMON)        L,M,N                A-G               NL

                                            O,Q-Y

LOCAL                  I                    Z                 IL

DUMMY

ARGUMENTS              K                    P                 KL

LOOP INDEX             J

Figure 5

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

section.

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 area

e.g.

COMMON B (50000)

CALL MASTER

STOP

END

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

statement

e.g.

CALL IVAR (SHINTVAL ,INTVAL)

causes

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.

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

be used.

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

assembler language.

iii) Some CFT library routines are relatively expensive.

Algorithm modification can sometimes lower the cost

e.g. consider Kessler's evaporation formula

E = α₁(q_sat - q)M_R

where α₁ = 0 for q > q_sat, M_R ~ density of rain

This leads to an algorithm for determining the evap-

oration of rain for fraction a_p of a grid area with

convective rain:-

E^c = a_p α₁(q_sat - q)  ( √(σ/α₂) × (p^c/a_p) ) ^ α₃

where α₁ = 5.44x10^-4, α₂ = 5.09x10^-3, and α₃ = 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

α₃ could be 0.5. Examination of the above

expression yields a reasonable approximation

by changing α₁ to 6.94 x 10^-4, α₂ to 7.35 x 10^-3,

and α₃ 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.

Figure 7

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.

5. Conclusions

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

maintained.

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

avoided

References

Roberts, K.V.  An introduction to the OLYMPUS system.

Computer Physics Communications,

7 (1974), 237-243.