Michael Metcalf, John K. Reid-Fortran 90_95 Explained-Oxford University Press, USA (1996)

Download Michael Metcalf, John K. Reid-Fortran 90_95 Explained-Oxford University Press, USA (1996)

Post on 12-Apr-2015

9 views

Category:

Documents

1 download

TRANSCRIPT

Fortran90 for Fortran77 ProgrammersClive Page 2002 November 21This document may be found at: http://www.star.le.ac.uk/cgp/f90course/f90.html or .pdf

Contents1 Introduction 1.1 What was wrong with Fortran77? 1.2 Whats New in Fortran90 . . . . 1.3 Benets . . . . . . . . . . . . . . 1.4 Will old code still work? . . . . . 1.5 Fortran90 Compilers . . . . . . . 1.6 The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 4 4 4 5 5 5 5 6 6 6 7 7 8 8 8 9 9 9 10 10 10 11 11 11 12

2 New Look and Feel 2.1 Basic Rules for both free and xed-format . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Free-format layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 New Forms for Specication Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 New Control Structures 3.1 The SELECT CASE Structure . . 3.2 DO, EXIT and CYCLE statements 3.3 DO WHILE statement . . . . . . 3.4 Structure Names . . . . . . . . 3.5 Label-free programming . . . . 3.6 Internal Procedures . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Arrays 4.1 Declaring and Initialising Arrays . . . . . 4.2 Array-valued expressions and assignments 4.3 Array Constructors . . . . . . . . . . . . . 4.4 Array Sections . . . . . . . . . . . . . . . 4.5 Array Intrinsic Functions . . . . . . . . . 4.6 WHERE structure . . . . . . . . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Dynamic Storage 5.1 Automatic Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Allocatable Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

5.3

Pointer arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 13 13 14 15 15 15 16 17 17 17 18 18 18 19 19 19 20 20 21 21 22 22 22 22 23 23 24 24 24 25 25 26 26 26 26 27

6 Modules and Interfaces 6.1 Example dening constants . . 6.2 Module Procedures . . . . . . . 6.3 Public and Private accessibility 6.4 Avoiding name clashes . . . . . 6.5 Pros and Cons of Modules . . . 6.6 Explicit Interfaces . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7 Procedures and Arguments 7.1 Assumed shape arrays . . . . . . . . . 7.2 Keyword calls and optional arguments 7.3 Generic names . . . . . . . . . . . . . 7.4 Recursive procedures . . . . . . . . . . 8 Derived Data Types (structures) 8.1 Accessing Components . . . . . . 8.2 Structure constructors . . . . . . 8.3 Nested Structures . . . . . . . . . 8.4 Pointers as Components . . . . . 8.5 Dened and overloaded operators 9 Input Output 9.1 New OPEN and INQUIRE options 9.2 Internal File I/O . . . . . . . . 9.3 Formatted I/O . . . . . . . . . 9.4 Non-advancing I/O . . . . . . . 10 Character Handling 11 Pointers 11.1 Pointer Rules . . . . . . . . . . 11.2 Array of arrays . . . . . . . . . 11.3 Pointer as alias . . . . . . . . . 11.4 Function may return a pointer 11.5 Dynamic Data Structures . . . 12 Portable Precision

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

13 Other features 13.1 Bit-wise operations on integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Other intrinsic functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Resources 15 Language Progression

2

15.1 15.2 15.3 15.4

Deprecated features . . . . . . . . . . Superseded features . . . . . . . . . . Main New Features of Fortran95 . . . Possible New Features of Fortran2000

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

27 27 27 28

11.1

IntroductionWhat was wrong with Fortran77?

There are no dynamic storage facilities at all. There are no user-dened data types or data structures (except the COMMON block). It was too easy to make mistakes which the compiler could not detect, especially when calling procedures (subroutines or functions). A study of some 4 million lines of professional Fortran showed 17% of procedure interfaces were defective. Programs are less than 100% portable because of a few remaining platform-dependent features. Control structures are poor, so it hard to avoid using GOTOs and labels, often leading to spaghetti code. Archaic features left over from the punched-card era: xed-format lines, statements all in upper-case, variable names limited to 6-characters. In practice programmers are driven to use extensions to Fortran77 Standard which reduce portability.

1.2

Whats New in Fortran90

Free-format source code and many other simple improvements. Arrays as rst-class objects, whole-array expressions, assignments, and functions. Dynamic memory allocation; pointers to allow complex dynamic data structures to be constructed. User-dened data types; existing operators can be overloaded (re-dened) or new ones dened. The MODULE a new program unit which can encapsulate data and a related set of procedures (subroutines or functions). Can implement classes and member functions for object-oriented programming. New control structures: SELECT CASE, CYCLE, and EXIT so labels and explicit jumps are rarely needed. Recursive functions, generic names for procedures, optional arguments, calls with keywords, and many other procedure call options.

3

1.3

Benets

Programs often simpler, and thus easier to maintain. Programs are safer and more reliable because the compiler can detect many more mistake (provided sensible safety features are used). Programs more portable, because very few machine-dependant features remain, and there is little need to use extensions. Parallel processing supported by whole array operations and other features. Fortran77 is a true subset: nothing has been taken out. You can adopt the new features gradually.

1.4

Will old code still work?

Yes if it used only Standard Fortran77 or extensions which are now part of Fortran90. But common extensions to Fortran77 which were not included in Fortran90 include: Tab-formatted source-code lines change tabs to spaces, maybe use free-format. Data type declarations like INTEGER*2 and REAL*8 new syntax better but more complicated. Hexadecimal, octal, and binary constants in expressions allowed only in DATA statements. VAX data structures Fortran90 structures have dierent syntax. Functions like %VAL in subprogram calls the new dynamic memory facilities are much better. Expressions in formats (e.g. FORMAT(F.3) can do this indirectly with internal-le I/O. Some OPEN options such as ACCESS=APPEND change to POSITION="APPEND". Function name clashes Fortran has no reserved words, but problems may arise one of your external function names matches that of an intrinsic function. There are 75 new ones, and names to avoid now include: ALL, ANY, COUNT, HUGE, KIND, MAXVAL, MERGE, MINVAL, PACK, RANGE, SCALE, SCAN, SIZE, SUM, TRIM, and UNPACK. This problem can be avoided by declaring your function to be EXTERNAL wherever necessary. Static storage assumption Fortran77 compilers generally used static storage for all variables, so SAVE statements could be omitted with impunity. Most Fortran90 systems use static storage only when required (variables given an initial value, or has an explicit SAVE attribute). Otherwise local variables in subprograms will not be preserved after control returns, and missing SAVE statements may cause problems.

1.5

Fortran90 Compilers

Wide choice for PC/Windows and most Unix platforms, one or two for PC/Linux, VMS and Macintosh. They tend to be more expensive than for Fortran77, and not all are as ecient or stable. The following are available free: F for Linux is another subset, free for Linux from Imagine1 http://www.imagine1.com/imagine1 A translator from Fortran90 to Fortran77 can be obtained free for Linux from Pacic-Sierra Research http://www.psrv.com (but it has many limitations). The subsets supported by ELF90 and F are slightly dierent: both support all the modern features of Fortran90 and leave out all the obsolete stu, so they are not suitable for legacy code. GNUs free compiler, g77, is suitable for legacy code and runs on many platforms, but supports only a few of the new features of Fortran90. 4

1.6

The Future

Fortran95 was formally adopted as the ISO Standard in November 1997. It adds only a few new features (e.g. a way of specifying initial values for data structures). The rst Fortran95 compilers have already started to appear and many more are likely to appear by the end of 1998. Fortran2000 is currently being dened: major new features are likely to include full support for objectoriented programming, and syntax for inter-operability with C.

2

New Look and Feel

Use of lower-case and long variable names already a common extention to Fortran77; free-format layout is a more radical change. Examples here will use UPPER CASE for Fortran keywords and intrinsic functions, lower case for userchosen names. This is not a recommended convention, just for clarity in these notes.

2.1

Basic Rules for both free and xed-format

Lower-case letters may be used, but Fortran is case-insensitive (except within quoted character constants). Symbolic names can be up to 31 characters long, and names may include underscores as well as digits: temperature_in_fahrenheit = temperature_in_celsius * 1.8 + 32.0 Semi-colons separate two or more statements on the same line: sumx = 0.0; sumy = 0.0; sumz = 0.0 End-of-line comments start with an exclamation mark (but must not be in column 6 of xed-format code). nday = mjd(year, month, day) ! convert to Modified Julian Date Character constants may be enclosed either in a pair of apostrophes or double-quote marks making it easier to embed the other character in a string: WRITE(*,*) "If it aint broke dont fix it" Relational operators may be given in old or new forms: old form: new form: .GE. >= .GT. > .EQ. == .NE. /= .LE. 1.0e-5) CALL iterate(x, xmin) END DO

7

3.4

Structure Names

Names may be given to DO-loops, IF-blocks, or CASE-structures helps readability when they are deeply nested, and required to EXIT from (or CYCLE around) anything other than the innermost loop. outer: inner: sum = 0.0 DO j = 1,ny ! sum values until zero encountered DO i = 1,nx IF(array(i,j) == 0.0) EXIT outer sum = sum + array(i,j) END DO inner END DO outer

Note that structure names like inner do not have the drawbacks of statement labels because it is not possible to jump to them using a GO TO statement.

3.5

Label-free programming

Statement labels should be avoided because each one marks the site of a jump from elsewhere, and thus makes it harder to see the execution sequence. Label-free programming is now feasible in many cases: 1. DO-loops with END DO no longer need labels, and error-handling can mostly use EXIT or RETURN. 2. Computed-GO TO should be replaced by SELECT CASE. 3. FORMAT statements can be replaced by a format string in the READ or WRITE statement itself, e.g.: WRITE(unit, "(A,F10.3,A)") "flux =", source_flux, " Jansky"

3.6

Internal Procedures

Generalisation of statement functions no longer limited to one line: SUBROUTINE polygon_area(vertices) ! an external procedure IMPLICIT NONE ! applies throughout !... area1 = triangle_area(a, b, x) !... area2 = triangle_area(x, c, d) !... CONTAINS ! internal procedures follow... REAL FUNCTION triangle_area(a, b, c) ! internal procedure REAL, INTENT(IN) :: a, b, c REAL :: s ! local variable in the function s = 0.5 * (a + b + c) triangle_area = sqrt(s * (s-a) * (s-b) * (s-c)) END FUNCTION triangle_area END SUBROUTINE polygon_area Rules for internal procedures: May be subro...

Recommended

View more >