The Future of Fortran is Bright … Richard Hanson Fortran is a modern and efficient language that supports many areas of mathematical software and scientific applications. This presentation will outline application samples that are of interest to many in the high performance computing field. These new features of Fortran are the result of diligent work by the Fortran standards working group J3 and their members who appreciate the needs of the math software and application programming community.

Differential-algebraic equations Samples - Sparse linear systems Differential-algebraic equations Parallel Programming with Co-array Fortran My company, Visual Numerics, Inc., has a 37 year history of providing math and visualization software. My work is the math software side of things so I want to present some samples that should interest many of you. These samples arise in the design of math software that I have worked with. The first example is now in the IMSL version 6 Fortran library. My second example listed here will show some of the object-oriented parts of Fortran. The third example will wait until the standard work is completed and compiler vendors add co-array Fortran to their products.

Sparse linear systems: real :: y(:), b(:) Type(Sparse) A … y = A .ix. b Uses derived types and a defined operation, .ix. An LU factorization plus iterative refinement computes the y in a hidden routine. The objects used here are a derived type for A while y and b are floating point arrays . The derived type A contains the matrix in a suitable packed form and other parameters such as tolerances and flags. Supporting this operation is a call to the SuperLU sparse linear solver package. Incidentally this package is written in C. Defining the matrix entries is done with overloaded assignments and reallocation of memory.

Differential – algebraic systems: Solve a system of equations This notation describes a system of n equations for a dynamic n-vector y=y(t). Applications typically must transform the physical problem into this form so that software can be applied to compute y.

Solver needs user input of the math objects in the form of subprograms for: Typically need data with these math objects and may also require optional linear equation solvers and numerical differentiation routines based on the problem size and structure The use of the object-oriented features of Fortran 2003 fits these requirements. It allows one to write library or application code that has a uniform design for with codes that requires user-written routines to complete the software algorithm.

TYPE(DAE_Dope) DAE_Type The DAE solver uses a packaged derived type: TYPE(DAE_Dope) DAE_Type The user extends this type to include problem data: TYPE, extends (DAE_Dope) My_DAE_Type real :: Problem_Data(100) End Type My_DAE_Type The base derived type DAE_Dope has default values of tolerances, choices of linear solvers, flags for numerical differentiation, etc. These would be engineered to allow a user to get started and build understanding without investigating all the parameters of the routine.

The DAE solver and the user-written routine for the math objects refer to the extended derived type as a polymorphic argument: Here is an outline of the user routine: Subroutine F(Y,Yprime,t, DAE_Stuff) … Class(DAE_Dope), intent(InOut) :: DAE_Stuff (Continued …) The DAE solver refers to the {extended} derived type with a class statement. There will be calls to the user code for defining the math objects. That user code refers to the extended type with the class statement. The important point is the visibility of the user’s data within the user-written code. The example used here is to pass a real array. One can extend the type using other kinds of data or derived types.

! Unravel the class object to get user data – Select Type(DAE_Stuff) Type is (My_DAE_Type) … = DAE_Stuff % Program_Data(:) End Select ! Compute F(y,y’,t) … F = … End Subroutine F We are passing user data into a routine that evaluates the function F. There are other issues not shown here that can be provided with a similar framework. It is usually desirable to allow the user to change the name of the routine here called “F” to a name related to an application. The base derived type can be packaged to contain a number of default parameters such as degree of certain interpolation formulas, tolerances, and many others. The user code can change these parameters since we have allowed the variable of class(DAE_Stuff) to be both an input and output argument.

Parallel Programming with Co-array Fortran Syntax is introduced for defining an executing image of a program: This new feature of Fortran 2008 may be the brightest star in the crown of Fortran. For it provides ‘the smallest change required to convert Fortran into a robust and efficient parallel language.' It looks and feels like Fortran and requires Fortran programmers to learn only a few new rules. These rules are related to two fundamental issues that any parallel programming model must resolve, work distribution and data distribution.

Type(Phu) :: z[*] ! Note the brackets[ ] - z is a co-array Real R Character(len=10) scribble End Type Phu Type(Phu) :: z[*] ! Note the brackets[ ] - z is a co-array This example derived type is used because it contains data of two types. The definition of the derived type might be packaged in a module.

if (this_image() == 1) then read(*,*) z do image = 2, num_images() Sync all if (this_image() == 1) then read(*,*) z do image = 2, num_images() z[image] = z ! Broadcast z to all other images end do end if ! The integer intrinsics this_image() and num_images() ! are in the F2008 standard proposal. Sync all is a ! key word that synchronizes the executing program images. Notice something very nice here: There is only one send operation even though the object sent has data of different types. The idea with co-array Fortran is to cover the same ground as MPI-1 but make the program shorter and readable. Each object is strongly typed in Fortran which is an unresolved issue when using MPI with Fortran. Currently Cray, Inc. has a compiler that implements a previous draft version of the proposed standard that is close to the proposal. There is also a pre-processor version done type the HPC group at Rice University. This is apparently based on a previous draft version of the part of the standard. Finally, it appear the CAF provides the opportunity for writing Fortran code that will naturally fit on multi-core systems with a modest number of processors. This code can be easier to read and maintain than alternatives based on message passing or the use of threading packages.

Other notable features of Modern Fortran – Interoperability with C IEEE floating point exception handling Procedure pointers Associate constructs This has been a brush with some of the compelling features of Fortran that are to be available in the near future. Many of you have heard of the (1982) quote: “I don't know what the language of the year 2000 will look like, but I know it will be called Fortran.” (C A R Hoare) To that I would add that the Fortran of today looks little like the Fortran of 30 years ago. But the perception of Fortran, by many, is mired in this long ago time and it is time to abandon that perception. A constraint the J3 working group has always imposed is that standard compilers must remain compatible with past working standard Fortran code. So if one uses Fortran there is the assurance that software of lasting value will be usable by new versions of the compilers. This assures investment in scientific applications that use Fortran.