An abstract data-type technique forscientific softwareby T. J. O'Neill and Prof. L. M. Delves

Numerical computation forms a substantial partof the total of world computing, and, as a result,large amounts of money are spent on theproduction, modification and maintenance ofscientific software. A methodology based on anabstract data-type technique for algorithmicdesign has the potential to reduce numericalsoftware development costs. This paperdescribes the abstract data-type development ofGEM2, a package for solving two-dimensionalsingle/coupled real/complex elliptic partialdifferential equations using the global-elementmethod. We show that the abstract design of theGEM2 package, together with the use of anextensible implementation language (Algol 68),yields a family of packages able to handle avariety of problems but based on a single sourcecode. Development and maintenance costs arereduced by this approach; we show that, at leastin this case, run time efficiency is unimpaired.

1 Introduction

An abstract data-type representation of an algorithm is adescription of the algorithm in terms of objects whose proper-ties are only specified in so far as they are relevant to thealgorithm. A classical example is a decreasing-order sortalgorithm: for any set of objects, it is sufficient to be able to tellwhether two such objects, A and B, satisfy the condition A > B,and no other property of the objects is relevant.

If a programming language supports the abstract data-typeconcept, then a single implementation of such an algorithmmay be used by any set of objects, and for each set it is neces-sary to provide only a coded definition of the operator '>'. Forarrays of reals, integers and character strings, the NumericalAlgorithms Group (NAG) library provides separate sort routines,each with its own documentation, example and stringent pro-gram. Clearly, if these could be replaced by a single abstractdata-type routine it would be advantageous.

Abstract data-type representations have been proposed forlow-level vector/matrix operations (Ref. 1), for which the appro-priate level of abstraction is obvious. However, it is argued inRefs. 2-4 that the advantages of abstraction increase with thesize and complexity of the problem, and that several levels ofabstraction are usually possible for more complex instances.Ref. 3 supports this argument with regard to numerical quadra-

80

ture packages, and shows how the size of a quadrature librarycan be drastically reduced by the consistent use of abstractdata-type techniques.

We believe that similar advantages accrue in many otherareas of numerical software; but the use of Fortran as the primelanguage for scientific work has perhaps led to a neglect of thetechnique. We consider here a further case study in the use ofabstract data-type techniques: the production of software forthe solution of partial differential equations. Finite-element andfinite-difference general-purpose packages for such problemsare widely used, but are expensive to develop and maintain.

We have developed a package, GEM2, which is an ellipticsolver based on the global-element method (Refs. 5-8). Wedescribe here the way in which abstract data-type techniqueswere used in the development of GEM2 and the advantageswhich accrued from this. We believe that the results demon-strate quite convincingly the advantages of the abstract tech-nique, and of the use of extensible languages, for scientificsoftware.

2 The mathematical problem

Over an arbitrary region R, the global-element method solveselliptic partial differential equations of the form

-V.A(x,a(x))VC/(x) + B(x,U(x))U(x)+ C(x,G(x)).VU(x) = G(x,a(x)) x e R

where A(x,(I(x)) is a positive definite symmetric matrix, andC(x,U(x)) is a vector. On the region's boundary 8R, CJ(x) issubject to any piece-wise combination of the following types ofcondition:

Dirichlet:

D(x,C/(x))tf(x) = G,(x,a(x)) xe 8K,

Mixed/Neumann:

A(x,C/(x))Va(x).n(x) = G2(x,a(x))C/(x) + G3(x,tf(x)) xe 8R2

Periodic:

(I(x) = U(x+ a) x e 8/?3 and x + a e 8ft,

and

A(x,a(x))VC/(x).n3(x) = [n3(x).n4(x)]/\(x +a,U(x + a))VU(x + a).n4(x + a)

where

bR = 8R, -1- bR2 + 8R3 -I- 8/?4

8ft, = {x + a x e 8R3 and a constant}

Software Engineering Journal May 1987

3 A summary of the method 5 The abstraction

Using the global-element method, the region is split into a smallnumber of sub-regions ('global elements'), each of which ismapped on to a standard shape. The solution is approximatedby a product expansion in the mapped variables of each ele-ment. The expansion coefficients are computed as the station-ary point of a suitable functional, some terms of which are usedto impose implicitly both the boundary conditions and con-tinuity across element interfaces. Convergence is achieved byincreasing the degree of the expansion in each element ratherthan the number of elements; thus the method may be viewedas providing a variable-order finite-element technique.

The problems which had to be solved can be exemplified bylooking at the description of the geometric region, over whichthe differential system is to be solved. In two dimensions, we canrepresent a point by a real vector of length two, holding theco-ordinates of the point; in Algol 68 we introduce the typedeclaration

MODE POINT = [1 : 2JREAL;

and this declaration appeared in the original version of GEM2.Also included were type declarations for the built-in error esti-mate:

4 Initial decisions

MODE ERRORESTIMATE = STRCJCT(BOOL reliable, REAL error);

(which is a record containing an estimate of the error and a flagfor the case that the estimate is itself suspect), and for the

The algebra of the method (Ref. 6) is not simple, and the solution to the problem:

MODE SOLUTION = STRC1CT(REF[]REF[,]REAL expansion, REF[]ERRORESTIMATE error);

resulting numerical algorithm is more complex than thatneeded for a fixed-order finite-element scheme. The originalversion of GEM2 was written to provide a vehicle for testing themethod on a variety of problems. To ease both implementationand maintenance, it was decided to write it in the programminglanguage Algol 68. This language is extensible in that it providesboth user-defined types and user-defined operations on thosetypes; hence a reasonably abstract and structured approach tothe implementation could be used. A partial differential equa-tion package handles objects such as

ELEMENT. SIDE, DIFFERENTIAL-OPERATOR,BOUNDARY-CONDITION, SOLUTION

Declarations of these and other types appear in the GEM2 code,together with definitions of standard operations on those types.These are then used to construct a (fairly) direct description ofthe detailed algorithm given in Ref. 6.

This initial version of GEM2 was written to handle a single real

which contains a vector of error estimates — one for eachelement in the grid used — and a vector of matrices, each ofwhich describes the solution in a given element via a 'mappedChebyshev' expansion (see Ref. 6 for details).

Here we note the occurrence of the MODE REAL in each ofthese type declarations: it represents a failure to think abstractly.We must distinguish between the variation uses of REAL,because in a more general context they are not all valid; forexample, the solution may be complex or vector valued.

When we look at the basic mathematical structures of thesingle/coupled real/complex family of equations denotedabove, it is obvious that we need one level of abstraction for theregion and a second for the solution, and that the abstraction forthe left-hand terms A(x,(I(x)), B(x,U(x)) and C(x,C/(x)) is relatedto that of the solution. The abstract data-type representation forboth levels may be handled by a pair of data types: one toidentify the space's underlying set of numbers, and the other todenote the dimensionality. Accordingly, we use the data typeERROR for the representation of an error, the related pairCOORD and POINT for the region, and the related pair FIELDand SCAL for the solution:

MODE POINT = [1 : 2]COORD;MODE ERRORESTIMATE = STRUCT(BOOL reliable, ERROR error);MODE SOLUTION = STRUCT(REF[ ]REF[,]SCAL expansion, REF[ )ERRORESTIMATE error);

differential equation. To develop a 'production' version capableof handling two-dimensional coupled complex equations, therewere two standard alternatives:

• Re-write the program to handle coupled complex equa-tions, accepting the run time overheads when only a single realequation was involved.• Develop and maintain separate versions for each class ofproblem, accepting the increased maintenance and develop-ment costs.

Neither approach seemed practical and, since we had alreadymade use of the Algol 68 ability to support the abstract data-typeconcept, we decided instead to explore the possibility ofemploying a software design which would treat the unknownfunction generically; i.e. except for the definition of a smallnumber of non-generic operations on specific data types, weaimed for a generic code that would not make assumptionsabout either the dimensionality or the real/complex nature ofthe solution space. This was not the case in the original version,which had hard-wired in it many assumptions specific to asingle real equation which were not valid for complex or cou-pled equations.

Software Engineering Journal May 1987

The data type ERROR will usually be REAL; the data typeCOORD represents the underlying geometry, and may be typi-cally (SHORT/LONG) REAL. Similarly, FIELD may be (SHORT/LONG) REAL/COMPLEX, and, given a Q-dimensional solution,SCALwillbeaQ-vectorofFIELDor, if Q = 1 (a single equation),will be FIELD (to avoid the overheads of carrying around vectorsof length one).

The right-hand term G(x,CI(x)) must conform to the solution(I{x); hence it must deliver a SCAL object. Furthermore, so thatthe equation's left-hand side will similarly conform, the P x Pelements of A(x,CI(x)), the term B(x,CI(x)) and the P elements ofC(x,CI(x)) must deliver an object which can operate on the SCALsolution. In this context, the only relevant object, represented bythe data type OPSCAL, is a Q x Q matrix of FIELD.

The array specification POINT = [ 1 : P]COORD is used for amulti-dimensional region (i.e. P >\). However, in the one-dimensional case it is more efficient computationally to employthe scalar specification POINT = COORD. Similarly, the arrayspecifications SCAL = [1 : Q]FIELD and OPSCAL =[ 1 : Q,l : Q]FIELD are used for coupled equations (i.e. Q > 1),while the scalar specifications SCAL = FIELD and OPSCAL =FIELD are adopted for a single equation. Note that for the datatypes COORD and FIELD the inclusion of SHORT/LONG indi-cates that a choice of number precision is envisaged, and that

81

the boundary condition terms G](x,(J(x)) and G3(x,C/(x)) mustdeliver SCAL objects, while D(x,C/(x)) and G2(x,(l(x)) must yieldOPSCAL ones.

6 The generic file

As noted above, the original version of the package was specifi-cally designed to solve a two-dimensional single real equation,and was written in terms of the data types REAL andPO1NT=[1 : 2]REAL. Since it is a relatively easy exercise toidentify the geometry variables and to replace REAL by thedata type COORD, the abstract data-type representation of theregion will not be discussed further. The development ofthe abstract data-type representation of the solution and of theterms defining the equation and boundary conditions forthe two-dimensional family of problems was, however, a verysubstantial task. It was necessary to:

• decide whether objects (all initially defined as REAL) shouldbe REAL, FIELD, SCAL or OPSCAL objects• discover where properties of the REAL field had beenimplicitly used (for example r* = r1)• identify and re-structure portions of the code where a givenoperation had been defined for classes of objects, some ofwhich convert to SCAL and the rest to OPSCAL.

The re-design and re-implementation took about three man-years, but, while the effort involved was considerable, it wassmall in comparison with the effort of implementing a 'coupledequations' version from scratch. The resulting package con-tains two parts. The first, which we refer to as the generic file,contains the major part of the code; it is couched in terms of thedata types FIELD, SCAL and OPSCAL, and defines the code forthe abstract version of the two-dimensional global-elementalgorithm and user interface. The second part, which we refer toas the non-generic file, contains low-level definitions and oper-ations for a particular instance of the package, for example for nsingle real equation.

7 The non-generic files

The operations used in the generic file are those which arenatural for the family of problems being considered. Theseoperations are generic; i.e. they do not depend directly upon theimplementation used for the modes SCAL, FIELD and OPS-CAL. However, their definitions in turn generally call on innerbasic micro-operations which are needed to define the larger-scale ones. These basic operations are non-generic, and mustbe tailor-made to a particular specification of the abstract data-types FIELD, SCAL and OPSCAL. We illustrate with an example.GEM2 provides a facility for the user to add two solutions: a validfragment of a user program is

SOLUTION si, s2, s3;

si : = s2 + s3;

The definition of the operator' + ' for two SOLUTION variablesmay be written in abstract form, i.e. in a form independent of theunderlying modes SCAL and ERROR. We need (see the modedefinition for a SOLUTION given above) to add two sets ofexpansion coefficient matrices; two variables of type ERROR;and to decide what to do if either error is not reliable (thenneither is their sum!). The elements of the coefficient matricesare of type SCAL; hence we need to call here on two micro-operations:

SCAL + SCAL and ERROR + ERRORThese depend on the representation used for SCAL andERROR; the latter is uniform for all versions of GEM2 which weuse (it is mapped on to REAL), but the former necessarilydepends on whether we are generating a single real or a coupledcomplex package. With this in mind, we consider two alternativeapproaches for implementing these basic operations inAlgol 68. A limited abstract approach would be to adopt the'uniting' facility of the language, and hence declare the abstractdata types (modes in Algol 68) as follows:

MODE FIELD = UNION(REAL,COMPLEX);MODE SCAL = UNION(FIELD,REF[ ]F1ELD);MODE OPSCAL = UNION(FIELD,REF[,]FIELD);

where the constituents of SCAL and OPSCAL apply to the singleand coupled cases, respectively. To perform a non-genericoperation on an object of united mode, the program would haveto determine the object's actual mode prior to taking the appro-priate course of action. This function is carried out by a 'con-formity' clause, which includes both a test and an action foreach mode of the given union. Although these features appearsuperficially attractive, their inclusion in the code would betedious and their execution expensive.

The more efficient true abstract approach, which we apply,does not employ Algol 68 unions. Instead, we use a family (onemember per problem type) of non-generic files. Together with aparticular specification of the abstract data types, each non-generic file contains a few hundred lines of code defining thebasic operations needed. The specification of the abstract datatypes and the number of lines of code in the non-generic file foreach problem type and, also, the number of lines of code in thegeneric file are illustrated in Table 1.

A dialect of Algol 68, namely Algol 68-RS, is available to us ona DEC VAX 11/780 and, in the coupled cases, we need toovercome this language's restriction on the transput of arrays ofOPSCAL objects to and from backing storage. Consequently,several procedures and operators, other than those defining thebasic operations, have had to be included in every non-genericfile. This additional code would not be needed if full Algol 68 wasavailable, so the Table 1 figures for the lines of code in the non-generic files are slightly higher than necessary.

8 Instantiating the code

For a particular specification of the abstract data types,instantiation is effectively the following three-stage process:

Table 1 Size-of the generic and non-generic files for variousversions of GEM2

Problem type

Single realSingle complexCoupled realCoupled complexGeneric file

FIELD

REALCOMPLEXREALCOMPLEXFIELD

Data typesSCAL

REALCOMPLEXREF[]REALREFfJCOMPLEXSCAL

OPSCAL

REALCOMPLEXREF[,]REALREF[,]COMPLEXOPSCAL

Linesof code

126126438464

7469

82 Software Engineering Journal May 1987

Table 2 The solution ofincreases

Point

ABCDEFGH0

Solution [

0.091.35972

500.0500.0

0.082.98952

273.36394317.06325

0.01 Predicted error 1

Degree=3

0.06.2

-36.6-18.8

0.0-6.116.78.9

-17.430.7

the Motz

Degree=4

0.0-1.8-1.9

1.10.0

-4.51.41.4

-1.54.3

problem

Degree=5

0.0-1.4E-1

6.8E-12.2E-1

0.0-8.2E-2

2.1E-12.0E-29.6E-2

1.1

as the degree N

Degree=6

0.01.9E-11.7E-1

-4.2E-20.0

-7.4E-2-2.2E-2-2.8E-2-2.1E-2

2.1E-1

Degree=7

0.02.0E-2

-8.9E-2-2.0E-2

0.0-4.7E-3-1.1E-2

5.0E-3-7.0E-3

8.6E-2

first, the generic file is combined with the relevant non-genericone to form a source code; secondly, the source code is com-piled; and thirdly the resulting object code is made available to auser program. In the programming language Adat, an instantia-tion is effected by a user program at compile time (see forexample, Refs. 2 and 3). However, an Algol 68 instantiation takesplace at pre-compile time and, at compile time itself, the userprogram is linked to the library file in which the object code hasbeen stored. Currently, we have instantiated the code for asingle real equation (with long and short arithmetic), coupledreal equations, a single complex equation and coupled complexequations.

9 An example

To exemplify the methodology, we apply the package GEM2 toa problem, due to Motz (Ref. 9), which considers the Laplaceequation over a cracked square isotropic plate, and whosesolution is subject to Dirichlet and Neumann boundary condi-tions. Portrayed by Fig. 1, the plate is the square YBCZ, and thecrack runs along OA. Using symmetry about the x-axis, it isnecessary to consider only the top half of the square. Then wesolve the Laplace equation

V2u(x,t/) = 0

in the region ABCD, with the solution u(x,y) being subject to theboundary conditions

u(x,y) = 0 on OA (Dirichlet)u(x,y) = 500 on CD (Dirichlet)Vu.n(x,y) = 0 on AB, BC and DO (Neumann)

To handle the varied nature of the boundary conditions, and thepoint singularity (the approximate solution is known to behavelike r1/2 at the origin O), we sub-divide the rectangle ABCD intothe six elements shown. The elements are arbitrarily numbered,and the three sectors are included so as to isolate, and treat, thepoint singularity.

Although this is actually a single real problem, we have com-puted approximations to the solution using all the currentinstantiations of GEM2. Table 2 gives the value of the solution atthe corners of the elements, and for degrees three through toseven the maximum discrepancy of the solution less the com-puted approximation at these points is included. Despite theabrupt change of direction of the normal derivative at the cornerB, the variation of the boundary condition types and the pointsingularity at the origin O, these tabulated values demonstratethe rapid convergence of the method.

Since GEM2 yields error predictions, Table 2 also includesthe absolute error prediction for each degree, and these providegood estimates for the maximum errors of the computedapproximations. Note that all tabulated values, rounded to thedecimal place given, were obtained identically by the original

t Ada is a trademark of the CIS Government Ada Joint Program Office.

Software Engineering Journal May 1987

version and by each instantiation, and that all calculations wereperformed on an ICL 1906S computer.

The timings, given in Table 3 in terms of seconds, refer to thetotal time taken to obtain the approximation. The first row wasyielded by the original single real version in May 1980 (prior tothe abstract re-design), and all others refer to instantiations ofthe current generic code. For this problem, we see that the newsingle real instantiation is marginally faster than its originalcounterpart (even though the latter made use of machine-coded operators!) and that it is over ten times faster than thecoupled complex instantiation. Hence the implementation ofthe abstract data-type technique has provided not only a fastersingle real solver, but also a capability for solving a family ofproblems.

10 Conclusion

So far as we are aware, GEM2 is the most substantial instance ofan abstract data-type technique yet constructed, and as a roughmeasure of its success we make the following observations.

First, the project demonstrates the advantage of usingabstract data-type techniques to develop parallel versions of aprogram for similar classes of problem. Indeed, to solve furtheranalogous problems, one need only provide new non-genericfiles for the basic operations. For example, a need for greaterprecision for single real equations would be satisfied by theprovision of a non-generic file using the abstract data-typespecification FIELD = SCAL = OPSCAL = LONG REAL.

Secondly, even in the coupled complex case, the non-genericcode for the basic operations currently forms less than 6% ofthe entire source code to be compiled during instantiation. Thisproportion will decrease with the addition to the package of new

(-1.DB

(-I.-I)Y

E 0 H(-0.5,0) (0.5.0)

C(U)

ZC1.-1)

Fig. 1 Geometry of the cracked square isotropic plate considered inthe Motz problem

83

Table 3 Times, in seconds, for various versions of thepackage

Version

May, 1980 §Single realSingle complexCoupled realCoupled complex

Degree=3

15.010.82413.11970.08977.472

Degree=4

21.013.79718.460

149.634158.647

Degree=5

29.421.02533.487

203.047225.689

Degree=6

50.036.22463.867

293.423334.447

Degree=7

120.194.029

162.4781077.4421276.703

§ Includes the use of machine-coded operators.

facilities, written in terms of the abstract data types, since only afew new basic operations will have to be provided.

Thirdly, as demonstrated by the above example, the ability tosolve coupled and/or complex equations does not penalise therun time efficiency for a single real equation. In fact, the newsingle real instantiation runs faster than the original tailor-madeversion. Furthermore, the friendly and easy-to-use user inter-face of the original version was substantially improved by there-design, since the abstract data-type objects manipulated bythe code are those in terms of which the user thinks. Clearly,these are a bonus of both the programming design and thelanguage choice.

Finally, we conclude that (at least in this instance) theapproach yielded greatly increased functionality with no observ-able loss of efficiency. The effort required was decidedly non-trivial, but (we believe; we have no hard figures) less than wouldhave been needed by a traditional re-write.

11 Acknowledgment

This work was supported in part by CISAERO grant DAJA45-82-C-0010 to the University of Liverpool, to which we are grate-ful for the provision of computing facilities.

12 References

1 Van der MEULEN, S. C, and VELDHURST, M.: Torrix: a program-ming system for operations on vectors and matrices'. Centre forMathematics and Computer Science Tract, Amsterdam, Nether-lands, 1978

2 DELVES, L. M., and PCJRSGLOVE, C. J.: 'Ada generic facilities inscientific subroutine libraries', in FORD, B., and ROGERS, M. (Eds.):'Scientific Ada' (Cambridge University Press, 1986)

3 DELVES, L. M., and PCJRSGLOVE, C. J.: 'A generic Gauss quadraturepackage'. Proceedings of SIG-Ada Conference, Paris, France, May1985

4 DELVES, L. M.: 'Abstract data-types for numerical software'. Pro-ceedings of Conference on Problem Solving Environments for Sci-entific Software, Sofia-Antipolis, Bulgaria, July 1985

5 DELVES, L M., and HALL, C. A: 'An implicit matching principle forglobal element calculations', Journal of Institute of Mathematics &its Applications, 1979, 23, pp. 223-234

6 DELVES, L M., and PHILLIPS, C: A fast implementation of the globalelement method', ibid., 1980, 25, pp. 177-197

7 PHILLIPS, C, DELVES, L. M., and O'NEILL, T. J.: 'GEM2 — a pro-gram package for elliptic partial differential equations', in Tools,methods and languages for scientific and engineering computation'(North-Holland, 1983)

8 O'NEILL, T. J.: The global element method and complex coupleddifferential problems'. Ph.D. Thesis, University of Liverpool, Liver-pool, England, 1984

9 MOTZ, H.: 'Treatment of singularities of partial differential equationsby relaxation methods', Quarterly Journal of Applied Mathematics,1946, 4, pp. 371-377

Dr. T. J. O'Neill was formerly and Prof. L. M. Delves is with the Depart-ment of Statistics & Computational Mathematics, University of Liver-pool, Victoria Building, Brownlow Hill, PO Box 147, Liverpool L69 3BX,England. Dr. T. J. O'Neill is now with the Department of Mathematics,Statistics & Computing Science, University of New England, Armidale,NSW 2351, Australia.

84 Software Engineering Journal May 1987