rksuite 90: Fortran 90 software for ordinary dierential equation initial value problems Abstract

Transcription

1 rksuite 90: Fortran 90 software for ordinary dierential equation initial value problems R.W. Brankin The Numerical Algorithm Group Ltd. Wilkinson House, Jordan Hill Road Oxford, OX2 8DR, UK I. Gladwell Department of Mathematics Southern Methodist University Dallas, TX 75275, USA Abstract We present Fortran 90 software for the initial value problem in ordinary dierential equations, including the interfaces and how Fortran 90 language features aord the opportunity both to address dierent types and structures of variables and to provide additional functionality. A novel feature of this software is the availability of Unix scripts which enable presentation of the software for multiple problem types. Keywords: Fortran 90, ordinary dierential equations, initial value problems, recursion, complex AMS Subject classications: 65-04, 34-04, 65L05, 65L06, 65Y15, 65D30 1 Introduction MODULE rksuite 90 contains Fortran 90 software for the initial value problem (IVP) in ordinary dierential equations (ODEs): y 0 = f(t; y); y(a) = y a where a; t; b 2 R; a < t < b (or b < t < a) and y; f; y a 2 R; R n ; R mn ; C; C n or C mn. In rksuite 90 we have deliberately adopted the integration algorithms of the FORTRAN 77 code RKSUITE though modied the code in many ways to exploit the eciencies and facilities of Fortran 90; see [3] for a fuller account of the design issues in FORTRAN 77 and [1] for the FORTRAN 77 codes and documentation. In [2] we outlined our initial design of the Fortran 90 IVP software concentrating on the language features exploited internally; for example, long names, array syntax used internally, OPTIONAL arguments, the use of MODULEs, INTERFACE blocks, and INTENT speciers, etc. Here we discuss the software, its use, and its transformation to address dierent problem types and the algorithmic changes thus required. It is from features such as the OPTIONAL arguments and the transformations that the user will gain most benets in comparison with the FORTRAN 77 software: An easier-to-use interface, once Fortran 90 is familiar; A somewhat more ecient code for large problems when Fortran 90 compilers produce code similarly ecient to that produced by FORTRAN 77 compilers; A more robust code, far more likely to trap subtle user coding errors at compile time; A code able to deal directly with a wider range of problems types; and A code which the moderately sophisticated Unix user can transform further by modifying the scripts supplied. As in RKSUITE, we provide two procedures to integrate across a range and compute approximations to y. One procedure is used to setup the integration with initial values, range, error requirements and various options. The other integrates across the range and computes approximations to y at user specied points t; for more complicated tasks we provide another procedure which integrates one step at a time. This is initialized using the same setup routine. Associated with the step integrator are procedures for interpolation and resetting the integration range. For use with either integrator are utility procedures which provide diagnostic information and memory deallocation. In Section 2, we describe the interfaces provided in rksuite 90. Our emphasis is on the novel features in ODE software design permitted by the use of Fortran 90 (in contrast to FORTRAN 77). Section 3 discusses three design features. The rst is a novel set of transformational tools to enable various formulations of the IVP to be solved directly without prior user transformation. The second concerns the method of managing global variables in a way which is \multiprocessor safe" and this permits the third, the use of recursion. We provide an example using recursion for the invariant imbedding solution 1

2 of boundary value problems. Finally we conclude with a brief section discussing the eorts made to provide tags to identify independent variable types for further transformation. An earlier, but almost identical, version of the code and examples has been available publicly for some time; we indicate where, and how it was tested. As we have seen, we use upper case typewriter face letters for the names of xed reserved Fortran 90 words; also we use lower case typewriter face letters for dummy and actual variables, and italicized lower case letters for names of varying words and mathematical variables. We hope by these means to provide markers for those who are unfamiliar with Fortran 90 syntax. 2 The Fortran 90 Interfaces We need a few preliminaries. Throughout, when computing with REAL machine numbers we work in a consistent precision, or KIND in Fortran 90 terminology. This KIND is set as an integer parameter wp used throughout MODULE rksuite 90 and set once in its own MODULE rksuite 90 prec. For procedures to communicate we dene a special derived TYPE which we give the generic name rk comm. Its contents are PRIVATE so as to prevent accidental modication. They include scalars, arrays whose extents depend on the structure of the dependent variables, character variables and logicals. We employ a number of generic terms: (i) type(independent variable) (ii) type(dependent variable) (iii) dimension (iv) TYPE(rk comm) where type and dimension have dierent, but related, meanings to the Fortran 90 terms TYPE and DIMENSION. In the instances created by our Unix scripts, these terms can be interpreted: (i) type(independent variable) is equivalent to REAL of KIND wp. (ii) type(dependent variable) is equivalent to REAL or COMPLEX of KIND wp. (iii) dimension is: absent for a scalar; DIMENSION(:) for a vector; and DIMENSION(:,:) for a matrix; this is used as an attribute for assumed-shape array arguments which are related to the dependent variable(s). When we specify the dimensionality of the result of a function (possibly array-valued) with respect to the dependent variable(s) y we write dimension (y), which is: absent for a scalar; DIMENSION(SIZE(y)) for a vector; and DIMENSION(SIZE(y,1),SIZE(y,2)) for a matrix. (iv) for the types and dimensionalities of dependent variables currently available in rksuite 90, rk comm is equivalent to real complex zero dimensions rk comm real 0d rk comm complex 0d one dimension rk comm real 1d rk comm complex 1d two dimensions rk comm real 2d rk comm complex 2d Otherwise the usual syntax of Fortran 90 applies. Figure 1 is a simple template using the interfaces described below for the usual dependent variable case, a real vector ODE system integrated over a real interval. The precision-dening MODULE rksuite 90 prec is USEd by MODULE rksuite 90. Hence, PROGRAM integrate f derives its precision from USEing MODULE rksuite 90. When f is an array valued FUNCTION, it must have an explicit INTERFACE, which enables checking at compile-time. This INTERFACE can be provided by including the FUNCTION in a MODULE, as in Figure 1, or by including an INTERFACE block in the calling PROGRAM. To ensure use of the correct precision the MODULE define f should also USE the MODULE rksuite 90 prec. MODULE define_f USE rksuite_90_prec, ONLY:wp! get precision of rksuite_90 CONTAINS REAL(KIND=wp), INTENT(IN) :: t REAL(KIND=wp), DIMENSION(:), INTENT(IN) :: y REAL(KIND=wp), DIMENSION(SIZE(y)) :: f f =...! evaluate f END MODULE define_f PROGRAM integrate_f USE rksuite_90! access rksuite_90 2

3 USE define_f! access f TYPE(rk_comm_real_1d) :: comm! the communication structure REAL(KIND=wp) :: t_start=..., t_end=..., y_start(...)=(/.../), & tolerance=..., thresholds(size(y_start))=(/.../), & t_want, t_inc=..., y_maxvals(size(y_start)), & t_got, y_got(size(y_start))) INTEGER :: flag CALL setup(comm,t_start,y_start,t_end,tolerance,thresholds) DO! Loops until t_end reached t_want = t_want + t_inc IF (t_want > t_end) EXIT! Assumed t_inc positive CALL range_integrate(comm,f,t_want,t_got,y_got,flag=flag)! If optional argument flag omitted never exits range_integrate IF (flag /= 1) EXIT! flag = 1 successful exit PRINT*,' t = ',t_got,' y = ',y_got END DO CALL statistics(comm,y_maxvals=y_maxvals)! optional call PRINT*,' y_maxvals = ',y_maxvals END PROGRAM integrate_f Figure 1: Template for integration - declarations etc. omitted 2.1 The setup and range integrate procedures setup initializes the computation, so is normally called only once; its specication is in Figure 2. A call to setup must precede the rst call to range integrate or step integrate. Any subsequent call to setup reinitializes the computation. The argument comm is an instance of TYPE(rk comm), t start, t end specify the range of integration [a; b], and y start the initial conditions y a. tolerance, thresholds dene the error requirements. More precisely the integration procedures ensure that the local error e in the computed solution y of SIZE magnitude y satises ABS(e) / MAX(magnitude y,thresholds) tolerance componentwise. If the OPTIONAL arguments in setup are omitted, the default is to select a moderate order integration method (equivalent to method=`m'), the integrator range integrate (task=`r'), automatic computation of the initial step (h start=0.0 wp), printing error messages (message=.true.), and no global error assessment (error assess=.false.). SUBROUTINE setup(comm,t start,y start,t end,tolerance,thresholds, & method,task,error assess,h start,message) TYPE(rk comm), INTENT(OUT) :: comm type(independent variable), INTENT(IN) :: t start, t end type(dependent variable), dimension, INTENT(IN) :: y start REAL(KIND=wp), INTENT(IN) :: tolerance REAL(KIND=wp), dimension, INTENT(IN) :: thresholds CHARACTER(LEN=*), OPTIONAL, INTENT(IN) :: method, task LOGICAL, OPTIONAL, INTENT(IN) :: error assess, message type(independent variable), OPTIONAL, INTENT(IN) :: h start Figure 2: Specication of setup range integrate computes approximations to the solution at user specied points; its specication is in Figure 3. The array function argument f denes the ODEs as in f; t want species where the solution is required, and y got, yderiv got return the solution, derivative at t got. In a successful integration t got = t want. Otherwise t got is the value of the independent variable where the integration halted; OPTIONALly the error message and the value of flag indicate the diculty. The program terminates on any error unless flag is provided when it returns with flag set to an error reporting value. Problems that may be reported include: too small a step size was required to satisfy the error requirements, the global error assessment (where activated) ceased to be reliable, too many f evaluations have been used, or stiness was detected. RECURSIVE SUBROUTINE range integrate(comm,f,t want,t got,y got,yderiv got,flag) INTERFACE type(independent variable), INTENT(IN) :: t 3

4 type(dependent variable), dimension, INTENT(IN) :: y type(dependent variable), dimension(y) :: f END INTERFACE type(independent variable), INTENT(IN) :: t want type(independent variable), INTENT(OUT) :: t got type(dependent variable), dimension, OPTIONAL, INTENT(OUT) :: INTEGER, OPTIONAL, INTENT(OUT) :: flag y got, yderiv got 2.2 Utility procedures Figure 3: Specication of range integrate The utility procedures can be used in conjunction with either integrator. global error reports the global error assessment if this option is selected in setup (via error assess); its specication is in Figure 4. rms error reports, for each component of the solution, an assessment of the global error so far in the integration. For a successful integration the components of rms error will usually be a moderate factor of tolerance. max error reports the maximum contribution to this assessment and t max error the rst point where max error was observed. SUBROUTINE global error(comm,rms error,max error,t max error) REAL(KIND=wp), dimension, OPTIONAL, INTENT(OUT) :: rms error REAL(KIND=wp), OPTIONAL, INTENT(OUT) :: max error type(independent variable), OPTIONAL, INTENT(OUT) :: t max error Figure 4: Specication of global error statistics reports on the cost and performance of the integration; its specication is in Figure 5. total f calls, step cost and num succ steps report respectively the number of f evaluations used so far (excluding any used for global error assessment), the number of f evaluations required to take a single step with the selected method, and the number of successful steps taken so far. waste reports the fraction of attempted steps which failed to meet the local error requirement. A \large" fraction indicates the problem may be \sti" or the solution may have discontinuities in a low order derivative. h next reports the step size the integrator plans to use for the next step. y maxvals reports the componentwise largest value of ABS(y) computed at any step in the integration so far. It may be used in exploratory computations to determine a suitable setting for thresholds. SUBROUTINE statistics(comm,total f calls,step cost,waste,num succ steps, & h next,y maxvals) INTEGER, OPTIONAL, INTENT(OUT) :: total f calls, step cost, num succ steps REAL(KIND=wp), OPTIONAL, INTENT(OUT) :: waste type(independent variable), OPTIONAL, INTENT(OUT) :: h next REAL(KIND=wp), dimension, OPTIONAL, INTENT(OUT) :: y maxvals Figure 5: Specication of statistics For each of global error and statistics, at least one of the OPTIONAL arguments must be present. That is we require that the call has an action, as a call without an action probably constitutes a user error. Either subroutine may be called at any time in the integration between calls to the integrators. Procedure garbage collect has a single argument of TYPE rk comm and is provided to enable ecient use of memory. It should be called after completion of each completed or failed integration and prior to any re-use of the same instance of an argument in a new integration. 2.3 step integrate and associated procedures step integrate is designed for tasks requiring close monitoring of the integration; its interface is in Figure 6. To ease use, less common demands are handled by the auxiliary procedures interpolate and reset t end. step integrate integrates the solution one step at a time from t start toward t end. Arguments comm, f, flag are as described for range integrate. y now, yderiv now report the solution, derivative at t now. If the integration has not been successful t now, y now, yderiv now retain their values at the end of the previous step. 4

5 RECURSIVE SUBROUTINE step integrate(comm,f,t now,y now,yderiv now,flag) INTERFACE type(independent variable), INTENT(IN) :: t type(dependent variable), dimension, INTENT(IN) :: y type(dependent variable), dimension(y) :: f END INTERFACE type(independent variable), INTENT(OUT) :: t now type(dependent variable), dimension, OPTIONAL, INTENT(OUT) :: y now, yderiv now INTEGER, OPTIONAL, INTENT(OUT) :: flag Figure 6: Specication of step integrate Procedure reset t end is used to reset the end of the integration range, for stepping to output points using step integrate; its specication is in Figure 7. The argument t end new redenes the end of the range. reset t end should be used in preference to reinitializing using setup. It cannot be used to redene the direction of integration. SUBROUTINE reset t end(comm,t end new) type(independent variable), INTENT(IN) :: t end new Figure 7: Specication of reset t end In general, the most ecient way to compute the solution at specied points is to use interpolate; its specication is in Figure 8. It uses information calculated over the step just taken and may require additional evaluations of f in that step. (The number of additional evaluations required on any one step is xed for any number of output points.) t want species the value of the independent variable where a solution value is required. Approximations to the solution, derivative are returned in y want, yderiv want. At least one of y want, yderiv want must be present so that the call has an action. RECURSIVE SUBROUTINE interpolate(comm,f,t want,y want,yderiv want) INTERFACE type(independent variable), INTENT(IN) :: t type(dependent variable), dimension, INTENT(IN) :: y type(dependent variable), dimension(y) :: f END INTERFACE type(independent variable), INTENT(IN) :: t want type(dependent variable), dimension, OPTIONAL, INTENT(OUT) :: y want,yderiv want Figure 8: Specication of interpolate The availability in rksuite 90 of an interpolant with an internal power series storage mechanism permits a relatively straightforward attempt at event location. In [6], we described a robust technique for a limited event location capability, for problems commonly solved by inverse interpolation. It describes a FORTRAN 77 event location code that can be used \side-by-side" with any FORTRAN 77 stepby-step integrator with the appropriate type of power series interpolant in the equivalent of a reverse communication scheme. Equally, it could be used side-by-side with step integrate since FORTRAN 77 is a subset of Fortran Internal Design of rksuite 90 The major programming language and algorithmic design issues for the initial release of rksuite 90 were discussed in [2]. This nal version contains three sets of changes: the treatment of a variety of dependent variables via transformations, the handling of global variables, and permitting recursion. 3.1 Dependent Variables Almost all IVP solvers treat the case t 2 R; y 2 R n. As a result a user whose problem naturally has a solution y 2 R or R mn or a complex equivalent, is forced to recast the problem in R n, a possibly 5

6 error prone task with a potentially inecient result. We have treated these cases directly, aiming to maintain just one copy of the base software. We restrict the independent variable so that t 2 R, but we have isolated the specications of local variables of type(independent variable) to ease production of future codes with t in another eld. We consider three aspects of this problem: the type of, the shape of, and the arithmetic operations involved with the dependent variable. We start from the software for y 2 R n. In the code for y 2 R n we have identied with a tag (a special in-line comment) all declarative sections of the code involving dependent variables. (We have used IMPLICIT NONE so that every entity has been declared.) This tag automatically identies all dependent variable quantities with an associated rank. However there are other quantities in the code which must have the same shape as the dependent variables. A further special tag has been inserted into the declarative sections to identify these. This tagging partially addresses the questions of type and shape of the variables, as mentioned above. For the arithmetic aspect we have examined all assignments involving dependent variables. Throughout, we have ensured that array assignments a = :::b + :::c are used. That is extents are not specied since the arrays are always conformable. We nd that: all divisions involve real conformable divisors; multiplications of dependent variable quantities involve a real scalar multiplier; the intrinsic ABS is used to return real quantities (magnitudes); the intrinsic MAX is used on real conformable quantities; and the intrinsics MINVAL, MAXVAL are used on real quantities. All operations involving y 2 R n require no transformation to address y 2 C n. Similarly, almost all assignments involving arrays require no transformation when considering y 2 R and y 2 R mn. The exceptions are expressions using the intrinsics MAXVAL, MINVAL, SUM which must take array arguments and are therefore inappropriate for y 2 R. Instances of these intrinsics have been specially tagged so that they can be transformed. We have created sed scripts exploiting the tags for use in a Unix environment to: 1. create a complex version from a real version 2. create a 2d version from a 1d version 3. create a 0d version from a 1d version Two minor diculties are addressed in the scripts. The rst involves using the ALLOCATE statement to assign internal workspace via pointers. The exact extents of the arrays to be allocated must be supplied and depend on the shape of y. We have inserted special tags so that the `1d to 2d' script can add the second dimension of appropriate size, and the `1d to 0d' script can remove the dimension information and allocate the equivalent scalar pointer. A residual problem in the scalar case is that some of the elemental array intrinsics used do not permit scalar arguments, requiring a work-around in the sed script. The second diculty arises in the internal procedures implementing a stiness check. A nonlinear power method is used to estimate eigenvalues of the Jacobian of f. It requires computation of inner products. For y; z 2 R n this inner product is simply y T z. However for y; z 2 C n the inner product is y T z. The quantity (y T z) is also required. Unfortunately the Fortran 90 elemental intrinsic CONJG requires an argument of type COMPLEX. In a complex arithmetic version of the code there are two places where CONJG is required. As before we have inserted tags so that the `real to complex' script can make the appropriate edit. Note that for y; z 2 R mn or C mn the inner product remains well dened in Fortran 90 since the matrix-matrix multiplication is performed elementally. To derive a generic code, we restructured the stiness check to use complex arithmetic even in the real arithmetic case (e.g., in a quadratic equation solver). After these changes, the results for y 2 R n are identical to those computed using the codes described in [1] and [3]. When solving problems with y 2 R or y 2 C, the usual denition of stiness (for systems) does not apply. However, it is still possible for a scalar ODE to be sti. Consider y 0 (t) = k(y(t)? p(t)) + p 0 (t); y(0) = A with solution y(t) = (A? p(0))e kt + p(t); see page 384 of [5]. If p(t) is smooth and slowly varying and k is large and negative this problem is sti. We have solved this problem using rksuite 90 for p(t) = cos(t); A = 0 and k =?10 n ; n = 1; 2; 3; : : :. Stiness is agged for all n > 2 on long enough ranges of integration. So the default mechanisms in the stiness check work here. Similarly, in RKSUITE and rksuite 90 these mechanisms work both for dependent variable arrays of length one and for scalars. The alternate versions of rksuite 90 are produced using a further Unix script provided with the Fortran 90 software. The user has the option of generating any individual version or all six. The version(s) are bundled in a generic interface which hides the number of interfaces. That is, the user sees just one each of setup, range integrate, etc. The Fortran 90 compiler determines the specic version by the dierences in types of the arguments in each generic interface. Particularly, the type of rk comm is used to determine which instance to use if there are no other dierences. 6

7 3.2 Global Variables In RKSUITE global variables were passed in COMMON or, for those of length depending on n, in an unspecied work array passed as an argument between procedures. In the rst version of rksuite 90 the same information was kept in PRIVATE (global variables) in a MODULE. This is natural in Fortran 90 but is not \multiprocessor safe" (nor is COMMON) and hence also unsuitable for multithreading environments as separate copies of the global variables cannot be made. So, we have reverted to the traditional \packed work array" approach using the derived TYPE rk comm for passing global information between procedures. A user (or system) may declare as many instances of TYPE(rk comm) as required. A side eect of the change in handling of global variables is to permit simultaneous (side-by-side) integrations to be performed in the same program. 3.3 Recursion The approach adopted for global variables also enables recursive calls to the integrators. Hence a differential equation can be dened in terms of the solution of other dierential equations. For example, recursion permits the direct evaluation of multidimensional quadrature using just the one-dimensional integration procedure dened by rksuite 90. It also permits solving invariant imbedding problems in a natural (though inecient) way. Consider the boundary value problem y 00 (t)? y(t) = 0; y(0) = 1; y 0 (T ) =?e?t with general solution y(t) = C 1e t + C 2e?t. The boundary conditions force C 1 = 0; C 2 = 1. Forward or backward shooting will be unsuccessful for large T due to the exponential solution behavior, but invariant imbedding may be used. As shown on page 68 of [4], an invariant imbedding method consists of (i) Integrate together the ODEs (ii) Find ^x by solving (iii) Integrate ODE u 0 (t) = 1? u(t) 2 ; v 0 (t) =?u(t)v(t); t 2 [0; T ]; u(0) = 0; v(0) = 1: \backwards" from t = T to t = 0. u(t )^x = e?t? v(t ): x 0 (t) = u(t)x(t) + v(t); x(t ) = ^x; t 2 [0; T ] The solution of the boundary value problem is y(t) = u(t)x(t) + v(t). To solve (iii), we need the solutions of (i) everywhere. Probably the most ecient approach would be to save the interpolants for u(t) and v(t) everywhere on [0; T ] and evaluate as necessary when solving (iii). This may be achieved by saving copies of rk comm on every step when using step integrate. Then, the saved copies are used in reverse order in calls to interpolate when integrating (iii). A more elegant, and much more expensive, approach is to use recursion calling step integrate to solve (iii) and calling range integrate for (i) from the function dening the ODE for (iii); a template is given in Figure 9. (Note that range integrate calls step integrate so this is a recursive call.) 4 Conclusions and Availability We have developed software to solve initial value problems when the dependent variables y 2 R, R n, R mn, C, C n, or C mn and the independent variable t 2 R. It would be a simple matter to address y of dimension greater than two. We have identied and tagged those parts of the declarative sections which involve quantities of the type dependent variable and independent variable. This should facilitate the creation of initial value solvers with variables in elds dierent to those already considered. For example, it is relatively straightforward to address t 2 C integrating along a complex straight line; indeed we have a version for this case produced by a further Unix script transformation, not included with rksuite 90. In contrast, modifying the software for integration along an arc requires further transformational tools to incorporate the denition of the arc and to measure distance along it (corresponding to a Fortran 90 intrinsic in the simple straight line cases); hence it requires a variation of the interface. To address other elds, we must redene various operations (such as addition, multiplication by a real scalar, a magnitude function, and an inner product). Implementation could be achieved by overloading the operators (using overloading procedures, with all the associated overhead). The interpretation of stiness in these cases requires careful rethinking. Indeed, our complex straight line version has an automatically produced stiness check but it is not clear that it monitors what is usually considered to be stiness. 7

8 MODULE forward USE rksuite_90_prec CONTAINS FUNCTION g(t,y) g(:) = (/ 1.0_wp - y(1)**2, -y(1)*y(2) /) END FUNCTION g END MODULE forward MODULE backward USE rksuite_90 USE forward TYPE(rk_comm_real_1d) :: comm_f! Type for forward integration REAL(KIND=wp) :: u, v CONTAINS u = 0.0_wp; v = 1.0_wp; y_start_f(:)= (/u, v/) t_end_f = t; twant = t IF (t_end_f /= t_start_f) THEN CALL setup(comm_f,t_start_f,y_start_f,t_end_f,tol,thresh_f) CALL range_integrate(comm_f,g,twant,t_got_f,y_got_f,yderiv_got_f) CALL collect_garbage(comm_f) u = y_got_f(1); v = y_got_f(2) END IF f = u*y + v END MODULE backward PROGRAM invar_imbed USE backward! Note uses forward and rksuite_90 TYPE(rk_comm_real_0d) :: comm_b! Type for backward integration! The forward integration CALL setup(comm_f,t_start_f,y_start_f,t_end_f,tol,thres_f,method='h') twant = t_end_f CALL range_integrate(comm_f,g,twant,t_got_f,y_got_f,yderiv_got_f) CALL collect_garbage(comm_f)! The backward integration y_start_b = (exp(-t_end_f) - y_got_f(2))/y_got_f(1) CALL setup(comm_b,t_start_b,y_start_b,t_end_b,tol,thres_b, & task='s',method='h') DO CALL step_integrate(comm_b,f,t_now_b,y_now_b) PRINT*,' t = ',t_now_b,' sol = ',u*y_now_b+v, ' true = ',exp(-t_now_b) IF (t_now_b == t_end_b) EXIT END DO END PROGRAM invar_imbed Figure 9: An invariant imbedding example - declarations etc. omitted 8

9 The package comprises the base software (for y 2 R n ), the Unix scripts to generate alternate versions, the documentation, and several example programs, including some using the alternate versions. The rst version of the software has been available on netlib (at netlib@research.att.com and its various mirror sites) in directory ode/rksuite and in the NAG Fortran 90 software repository at This software has been available and has been accessed frequently since mid The authors have received no error reports. The codes were developed using the NAGWare f90 compiler and tested on a variety of platforms using this compiler. They have also been tested using the latest versions available to us of the following: the DEC OSF/1 Fortran 90 compiler, the Cray CF90 compiler and the IBM AIX XL FORTRAN Compiler/6000. Acknowledgement The authors thank Jeremy Du Croz and the anonymous referees for their suggestions on improving the presentation of this paper. References [1] R.W. Brankin, I. Gladwell and L.F. Shampine, \RKSUITE: a Suite of Runge-Kutta Codes for the Initial Value Problem for ODEs", Softreport 92-S1, Math. Dept., Southern Methodist University, Dallas, Texas, U.S.A, 1992, (also available by anonymous ftp from Southern Methodist University and from netlib in directory ode/rksuite). [2] R.W. Brankin and I. Gladwell, \A Fortran 90 Version of RKSUITE: An ODE Initial Value Solver", Annals of Numer. Math., 1 (1994), [3] R.W. Brankin, I. Gladwell and L.F. Shampine, \RKSUITE: A Suite of Explicit Runge-Kutta Codes", pp of \Contributions to Numerical Mathematics" (ed. R.P. Agarwal), WSSIAA 2, World Scientic Press, [4] G.H. Meyer, \Initial Value Methods for Boundary Value Problems: Theory and Application of Invariant Imbedding", Math in Sci. and Eng., 100, Academic Press, [5] L.F. Shampine, \Numerical Solution of Ordinary Dierential Equations", Chapman and Hall, [6] L.F. Shampine, I. Gladwell and R.W. Brankin, Reliable Solution of Event Location Problems for ODEs, ACM Trans. Math. Software 17 (1991) pp