Coordinate Free Programming of

Computational Fluid Dynamics Problems∗

P.W. GrantDepartment of Computer ScienceUniversity of Wales Swansea, UK

M. Haveraaen†

Department of InformaticsUniversity of Bergen, Norway

M.F. WebsterDepartment of Computer ScienceUniversity of Wales Swansea, UK

April 11, 2000

Abstract

It has long been acknowledged that the devel-opment of scientific applications is in need ofbetter software engineering practices. Herewe contrast the difference between conven-tional software development of CFD codeswith a method based on coordinate free math-ematics. The former approach leads to pro-grams where different aspects, such as the dis-cretisation technique and the coordinate sys-tems, can get entangled with the solver algo-rithm. The latter approach yields programsthat segregate these concerns into fully in-dependent software modules. Such consider-ations are important for the construction ofnumerical codes for practical problems. Thetwo approaches are illustrated on the coatingproblem: the simulation of coating a wire witha polymer.

∗This investigation has been carried out with sup-port from the European Union, ESPRIT-IV project21871 SAGA (Scientific computing and algebraic ab-stractions).

†This research was mostly carried out during theauthor’s sabbatical at University of Wales Swansea,throughout the academic year 1997/98.

1 Introduction

Numerical codes for solving numerous impor-tant civil and industrial problems have existedfor many years. A great number of these ex-hibit the problem which in the computer sci-ence community is referred to as software rot— a deterioration of software quality as theprograms have been modified over the years.Currently, there is therefore, a considerableamount of research being undertaken on therestructuring and redevelopment of numericalsoftware and a genuine interest in using mod-ern software engineering practices in the pro-cess, e.g., [BH96, BL97, BPR92, WBPR93,WK92, Ahl97, Ahl99].

Most numerical codes have been devel-oped within applied mathematics communi-ties, and the preferred programming languagehas long been Fortran, in one or other ofits many versions. Fortran was tradition-ally an imperative language with multidimen-sional arrays being the basic type construc-tor and was without type abstraction facili-ties. A change of language, e.g., to functionalor object-oriented does not necessarily involvea basic change in the approach to program-ming numerical codes. However, there aregenuine benefits from changing to languageswith more powerful software structuring con-

1

cepts. These may include an easier transitionto parallel code, as for Fortran–90, High Per-formance Fortran [Sch96] or functional lan-guages, or a more user friendly interface to ad-vanced data representations, as documentedfor object–oriented programming.

It is still the case that numerical softwaredevelopment has stayed within the conven-tional, applied mathematical framework, themain phases of which can be summarised as:

1. model the physical problem;

2. formulate an abstract solver algorithm;

3. discretise in space/time, to transform thecontinuous problem to its discrete coun-terpart;

4. refine the solver, utilising properties ofthe problem (such as symmetries);

5. convert/translate to program code.

This tends to lead to specialised, monolithicprograms that are only usable within therealm for which they were developed. Theyare monolithic in the sense that the whole pro-gram was developed as one unit for one pur-pose. It is often difficult to extract and reuseparts of the software in programs for solvingdifferent, but related, problems.

In this paper we will contrast such a conven-tional development approach with one whichis closer to the underlying pure mathematicalconcepts. The coordinate free developmentprocess consists of the steps:

1. model the physical problem;

2. formulate an abstract solver algorithm;

3. refine the solver utilising properties of theproblem (such as symmetries) at the ten-sor level;

4. translate to program code.

Here the discretisations etc. come in theform of libraries which are linked into thecode. This technique has been proposed in

[MKH96], and its software foundation was ex-plored and further developed in [HMMK92]and [Hav99b]. A case study is presented in[HFJ99].

In this study a detailed worked exampleis presented to highlight and contrast thetwo approaches. This will clarify the con-cepts and differences in reasoning that areused in these two development techniques.Thus, we utilise two pure–bred approaches,being fully aware that conventional develop-ment now normally is combined with andutilises more advanced software developmenttechniques. Few groups have employed theabstraction oriented technique to such a fullextent as we explore it here. However, theneed for higher levels of abstraction have beenindicated in [Ahl97, Ahl99], where the Com-pose project is described. Compose makes useof the C++ class library Overture [BH96] tobuild a framework for extendable PDE solverswhere PDE problems are treated as objects.Also in [WK92] the MAPS system has beenproposed which uses sets and maps on whichto base more abstract types such as grids andmeshes. These can be seen as abstracting thecontinuous level. The concepts of coordinatefree mathematics, as advocated here, providesabstractions at yet a higher level. Hopefully,this presentation may inspire others to try toadvance their software technology from a con-ventional one to higher levels.

The particular example we have chosen todevelop is a coating problem for Newtonianflows. This is outlined in Section 2, where themathematical development leads to a precisealgorithmic formulation at a naturally coordi-nate free level.

The conventional development process inSection 3 begins by describing briefly the fi-nite element method (FEM) where, for sim-plicity, a Cartesian coordinate system is as-sumed. Technical details are then supple-mented at the discrete level. Often differentconsiderations are presented in a disjoint fash-ion, and the reader is expected to merge themin a consistent way. The choice of coordinate

2

Figure 1: Tube Tooling

system has a marked influence on how the op-erators are defined, but this is often glossedover at this stage of the development process.This approach tends to lead to one type ofcode, whether it is expressed in a classicalprocedural language such as Fortran–77, orexpressed using object–oriented or even func-tional languages.

Subsequently, in Section 4 we demonstrate,in more detail, how the coordinate free ap-proach, using tensor mathematics, yields aquite different type of program. The sec-tion introduces the concepts of coordinatefree mathematics, such as tensor fields, de-scribes the Sophus software library which sup-ports these concepts, and shows how theFEM would be realised within this framework.These concepts are then used to develop thesolver for the coating problem at an abstractlevel, but with the technical detail needed todevelop a proper code. This programmingstyle naturally requires the target language tohave template classes, a feature lacking fromeven the more recent versions of Fortran, butwhich are present in C++ [Str97]. This lat-ter language is now increasingly being used bypractitioners in the field of high performancecomputing.

In Section 5 the coating problem is modifiedby changing from the Cartesian coordinatesystem to an axi–symmetric system which isideal for the simulation. The implicationsof such are compared under both program-ming approaches. For the conventional devel-opment technique, this may imply extensivemodification and recoding (if say analyticalintegration is employed), as the change of co-ordinate system has a marked influence on theway the operators are defined. In contrast, forthe coordinate free approach this only entailsa reconfiguration of the solver.

The final section discusses consequences ofthese findings.

2 Outline of the Fluid FlowProblem

The computational fluid dynamics problemused for illustration is that based on a wirecoating flow [HTJTW90]. Here, it is sufficientto consider essentially a Stokesian setting,that of incompressible flow. This is a basisupon which to develop the present methodol-ogy, subsequently to be extended into the non-Newtonian regime. The overall goal, in the

3

solution of such problems, is to predict an op-timal process design by which a coating (poly-mer) of suitable properties may be obtained,e.g. smooth coating with minimal residualstressing. The tooling design employed, istube tooling. This is shown schematically inFigure 1.

The liquid polymer melt undergoes apressure–driven annular flow within the tool-ing die, prior to being dragged by the wirethrough the geometry, as indicated. This de-sign allows the polymer to find a free surfacebetween the die exit and the attachment pointon the wire, involving a drawn–down section.

We begin with the basic partial differen-tial equations (Navier-Stokes) to specify theflow problem, and develop a weak, algorith-mic form, taking into account a semi–implicittime stepping scheme. This solver will thenbe further refined, in subsequent sections, toproduce executable code using the finite el-ement method for both the conventional andcoordinate free development. Iterative and di-rect algebraic solvers, such as Jacobi iterationand Choleski decomposition, will be used fordifferent stages. The former is employed forinverting Mass–matrix based systems, and thelatter for Pressure Poisson Stiffness matricesthat are sparse, symmetric and banded.

2.1 The problem description

The specific type of wire coating problem ofrelevance is defined via input data sets. Thegoverning equations for viscous incompress-ible isothermal flow may be described, in acoordinate independent form, by the gener-alised Navier-Stokes equations

ρ∂u∂t

+ ρ(u · ∇)u −

∇ · (2µ(sym(∇u))) + ∇p = f (1)

with the associated incompressibility con-straint

∇ · u = 0. (2)

The parameters and variables with type infor-mation are specified as follows:

• ρ is the density, a real number,

• u(x, t) is the fluid’s velocity, a vectorfield,

• ∂u∂t is the time derivative of the fluid’s ve-locity, a vector field,

• µ is the viscosity, a scalar field and ingeneral a function of ∇u,

• p(x, t) is the pressure, a scalar field,

• sym( ) is the symmetrisation operation.For a matrix τ , it can be defined bysym(τ) = 1

2(τ + τT ), where T is the ma-trix transpose operator,

• f is an external force acting on the fluid,a vector field,

• ∇ is the spatial derivative, which is usedin several forms:

1. (v ·∇)u, the convective derivative ofa vector field, yields a scaled deriva-tive of the vector field u in the di-rection of the vector field v,

2. ∇p, the gradient, yields a vectorfield when applied to a scalar fieldp,

3. ∇u (gradient) yields a matrix tensorfield when applied to a vector fieldu,

4. ∇·u, the divergence, yields a scalarfield when “dotted” with a vectorfield u,

5. ∇ · τ (divergence) yields a vectorfield when “dotted” with a matrixtensor field τ .

2.2 Non–dimensional form

Rather than adopting the above dimensionalformulation (1) directly, the solver will be

4

based on normalised equations, using a non–dimensional group number, the Reynold num-ber Re = ρu00

µ0. The scaling factors, all real

numbers, are: length scale 0; velocity scaleu0; viscosity scale µ0; and time scale t0. Wealso simplify the presentation, by assuminghereon that f = 0. This yields the formula-tion, for 0 < Re ≤ 1,

Re∂u′

∂t′+Re(u′ · ∇′)u′ (3)

−∇′ · (2µ′(sym(∇′u′))) + ∇′p′ = 0

∇′ · u′ = 0 (4)

where

• u′ = u/u0 is the fluid’s dimensionless ve-locity,

• ∇′ is the spatial derivative after normali-sation (using an adjusted metric from itsdimensional counterpart),

• µ′ = µ/µ0 is the dimensionless viscosity,a scalar field,

• p′ = p/p0 is the dimensionless pressurescaled by a pressure factor, a scalar field.

In addition, the simplification also dependson the following relationships between the pa-rameters:

u0t0 = 0; p0 = µ0u0/0.

This is ensured via choice of u0, 0 and µ0. Forclarity, the prime notation is discarded subse-quently. In the steady coating problem con-sidered, Reynold numbers tend to be small,of typical value Re ≈ 10−4. This is due tothe large levels of viscosity involved in thesepolymer melt flows.

The particular test problem considered isannular in configuration and hence two di-mensional. The weak formulation presentedin Section 2.6, is valid for two or three dimen-sions, and any geometry. The annular coor-dinate configuration is detailed in Section 5.1illustrating the complexity involved in chang-ing coordinate systems.

2.3 Time-discretisation and strongform of equations

We now derive the initial equations whichlead to the matrix equations (26 – 28) inSection 3. A semi–discretisation of Taylor–Galerkin/pressure correction form is appliedto (3) and solution vectors un and pn intro-duced at discrete time tn for constant timeinterval ∆t.

A set of difference equations is now estab-lished which can be used to solve for un+1 andpn+1 in terms of un and pn. We first take anapproximation to ∂u

∂t in (3) by considering thehalf interval (tn, tn+1/2):

2Re∆t

(un+1/2 − un) = s(un) −∇pn (5)

where s(u) = ∇ · (2µsym(∇u)) −Re(u · ∇)u.Here, a Taylor–Galerkin approach is

adopted of two–step form that addresses theconvective aspects of the problem. For a fullexplanation of this well–established techniquesee [TW87, HTJTW90, Don84, ZLMP85].

In order to obtain the solution at time steptn+1, we identify the target equation

Re

∆t(un+1 − un) (6)

= s(un+1/2) − ((1 − θ)∇pn + θ∇pn+1)

where 0 ≤ θ ≤ 1. Here, we have taken a θ rulepressure gradient approximation and evalu-ated s at un+1/2 (we actually take θ = 1/2,and so, this is a Crank–Nicolson formulation).However, since (6) does not separate un+1 andpn+1 we introduce an intermediate free vari-able u∗, as the solution of

Re

∆t(u∗ − un) = s(un+1/2) −∇pn. (7)

Note that with u∗ also satisfying

Re

∆t(un+1 − u∗) = θ(∇pn −∇pn+1), (8)

it follows that un+1 will satisfy (6) as re-quired. It is implied that the velocity un at

5

all times tn, must satisfy the incompressibilityconstraint expressed by equation (4). By ap-plying the divergence operator ∇· to equation(8), we derive the associated auxiliary equa-tion

Re

∆t∇ · u∗ = θ∇ · ∇(pn+1 − pn). (9)

This Poisson equation for the pressure dif-ference over a single time step completes theproblem specification. The four vector equa-tions (5), (7), (9) and (8), will subsequentlygive rise to matrix equations once spatial dis-cretisation has been conducted. This we out-line in Section 3.

Rearranging the equations yields the fol-lowing strong formulation consisting of threesteps. The first step splits into two mathemat-ically similar substeps, following a predictor–corrector pattern (two–step Taylor–Galerkin).The substeps 1a and 1b calculate the halfstepun+1/2 and the auxiliary u∗ approximationsto the velocities.

• Step 1a

2Re∆t

(un+1/2 − un) = ∇ · (2µ sym(∇un))

−Re(un · ∇)un −∇pn (10)

• Step 1b

Re

∆t(u∗ − un) = ∇ · (2µ sym(∇un+1/2))

−Re(un+1/2 · ∇)un+1/2 −∇pn (11)

• Step 2

θ∇ · (∇(pn+1 − pn)) =Re

∆t(∇ · u∗) (12)

• Step 3

Re

∆t(un+1 − u∗) = −θ∇(pn+1 − pn) (13)

These steps are iterated from an initial guessto produce a steady state solution.

2.4 Initial and boundary conditions

The system of equations of the previous sec-tion are solved by imposing appropriate initialconditions on the domain Ω,

u(x, 0) = u0(x)p(x, 0) = p0(x),

where ∇ · u0 = 0, and appropriate boundaryconditions on Γ as

u = g1(x, t) on Γ1 (14)n · σ = g2(x, t) on Γ2.

Here Γ = Γ1 ∪ Γ2 encloses the domain Ω, n isthe unit outer normal on Γ, g1(x, t) representsthe velocity vector prescribed on Γ1, g2(x, t)designates the traction vector prescribed onΓ2, and σ is the total Cauchy’s stress tensor.For an incompressible Newtonian viscous fluidwe have in a Cartesian coordinate system

σij = −pδij + µ0(∂ui

∂xj+∂uj

∂xi)

where µ0 is a Newtonian fluid viscosity andδij the unit tensor. The coating problem is asteady flow and boundary conditions of typeΓ1 only are assumed. In the most generalstatement of the problem free surfaces withsteady traction boundary conditions wouldapply.

Since there is no restriction on the choice ofboundary conditions for u∗ (a free variable),we may equate u∗ to un+1 on the completeboundary Γ. The implication from such achoice and step 3 is that ∇(pn+1 − pn) shouldvanish on Γ. Also, the boundary conditionsat step 3 are clearly prescribed. For steadyboundary condition problems of immediaterelevance, such assumptions are exact. Fortransient instances, assuming smoothness intime for pressure, would indicate accuracy toa first order in this variable at least, and henceto a second order in velocity from (13). Thisargument maintains the overall order of thescheme [vK86]. We shall see below, in thevariational form of the problem, that natural

6

homogeneous Neumann boundary conditionsemerge from step 2 and these are a distinct ad-vantage to this scheme [HTJTW90, HTW91].

2.5 Semi–implicit form of solver

With a Crank–Nicolson treatment of diffusionterms we derive a semi–implicit time steppingscheme of second order accuracy. This allowsa wider window of stability above an explicitimplementation and thus permits the useof practical working time steps [HTJTW90,HTW91, vK86]. Such advantages continuethrough to more complex non–Newtonian set-tings, where inertial influences via Reynoldsnumber are low, in contrast to elastic effects(for further details see [MTW98]). In step 1a,the term un in the viscous term of the explicitscheme is replaced by the average at tn+1/2

and tn. After rearranging, so that un+1/2 ap-pears in the difference term un+1/2−un on theleft hand side only, we obtain for the modifiedstep 1a′

2Re∆t

(un+1/2−un)−∇·(µ sym(∇(un+1/2−un))

= 2∇·(µ sym(∇(un))−Re(un ·∇)un−∇pn.(15)

Step 1b is treated in a similar manner, whereun+1/2 in the viscous term is replaced by theaverage of un and u∗, yielding step 1b′

Re

∆t(u∗ − un) −∇ · (µ sym(∇(u∗ − un)) =

2∇ · (µ sym(∇(un)) −∇pn −Re(un+1/2 · ∇)un+1/2. (16)

The semi–implicit solver is then describedby (15), (16), (12) and (13).

2.6 Weak formulation

The weak variational formulation of the prob-lem is now derived. We use two sets of testfunctions: a class of quadratic vector shapefunctions v ∈ V and a class of scalar shapefunctions q ∈ Q. Both sides of equations (15),

(16) and (13) are dotted with the vector shapefunctions v and the scalar test functions q aremultiplied into the algorithmic step 2, equa-tion (12).

The results are integrated over the wholedomain Ω and simplified, via integration byparts. This reduces second–order derivativesfrom the integrands to first–order and pres-sure gradients to order zero in the definingvelocity equations. Further simplification isachieved using the divergence theorem whichgives rise to the integrals over the boundaryΓ.

From (15) step 1a′′ becomes:

2Re∆t

∫Ω(un+1/2 − un) · vdΩ +∫

Ωµ sym(∇(un+1/2 − un)) · ∇vdΩ

=∫

Γ(µ sym(∇(un+1/2+un))·v−pnv)·ndΓ−

2∫

Ωµ sym(∇(un)) · ∇vdΩ −

Re

∫Ω((un · ∇)un) · vdΩ +

∫Ωpn(∇ · v)dΩ

In a similar manner, starting from equation(16), we obtain step 1b′′:

Re

∆t

∫Ω(u∗ − un) · vdΩ +∫

Ωµ sym(∇(u∗ − un)) · ∇vdΩ =∫

Γ(µ sym(∇(u∗ + un)) · v − pnv) · ndΓ −∫

Ω2µsym(∇(un)) · ∇vdΩ +

∫Ωpn∇ · vdΩ −∫

ΩRe(un+1/2 · ∇)un+1/2 · vdΩ

Step 2′′ becomes:

θ

∫Ω∇(pn+1 − pn) · ∇qdΩ −

θ

∫Γ(∇(pn+1−pn)·n)qdΓ =

−Re∆t

∫Ω(∇·u∗)qdΩ

7

and step 3′′:

Re

∆t

∫Ω(un+1 − u∗) · vdΩ =

θ

∫Ω(pn+1−pn)∇vdΩ−θ

∫Γ(pn+1−pn)(v·n)dΓ

Finally, all surface integrals are equated tozero. This is in accordance with the details ofthe boundary conditions as expressed in Sec-tion 2.4. The test functions used will vanishon the boundary Γ1, where the velocities areprescribed, as indicated in equation (14) andfor the coating problem considered, it is as-sumed there are no traction boundary contri-butions.

In step 2 of the algorithm, the surface in-tegral can be removed since ∇(pn+1 − pn) istaken to vanish over the whole of Γ, as dis-cussed in Section 2.4. In addition, due to im-position of fixed Dirichelet boundary condi-tions on un+1 − u∗, we can ignore the associ-ated surface integrals over Γ2 for the pressurefields again owing to the choice of test func-tions. The weak formulation can thus be ex-pressed through the following set of equations:Step 1a:

2Re∆t

∫Ω(un+1/2 − un) · vdΩ +∫

Ωµ sym(∇(un+1/2 − un)) · ∇vdΩ =

− 2∫

Ωµ sym(∇(un)) · ∇vdΩ −

Re

∫Ω((un · ∇)un) · vdΩ +

∫Ωpn(∇ · v)dΩ

(17)

Step 1b:

Re

∆t

∫Ω(u∗ − un) · vdΩ +∫

Ωµ sym(∇(u∗ − un)) · ∇vdΩ =

− 2∫

Ωµsym(∇(un)) · ∇vdΩ −

Re

∫Ω(un+1/2·∇)un+1/2·vdΩ+

∫Ωpn∇·vdΩ

(18)

Step 2:

θ

∫Ω∇(pn+1 − pn) · ∇qdΩ =

−Re∆t

∫Ω(∇ · u∗)qdΩ (19)

Step 3:

Re

∆t

∫Ω(un+1 − u∗) · vdΩ =

θ

∫Ω(pn+1 − pn)∇ · vdΩ. (20)

This completes the development of the vari-ational formulation of the problem. This willbe used as the starting point for the discreti-sation over space both for the conventionaldevelopment, in Section 3, and for the coordi-nate free approach, in Section 4, both leadingto implementable simulations.

3 Conventional SoftwareDevelopment andDiscretisation

This section describes the conventional ap-proach for numerically solving equations (3)and (4). The domain over which the solutionis required is first triangulated into a finite–element mesh with nodes at the vertices andmid points of the edges. The weak formula-tion, as presented in section (2.6), is used toderive a set of matrix equations relating thevalues of the velocities and pressure at themesh nodes. This is presented initially withina Cartesian coordinate framework.

3.1 The finite element method

We now obtain the fully discretised equa-tions using the finite element method (FEM).The total number of nodes and vertex nodesin the mesh are denoted by mv and mp re-spectively. Two sets of spatial shape func-tions, V and Q are employed. V = ϕj |j =1, . . . ,mv is a set of piecewise quadratic

8

functions (quadratic on each element) andQ = ψj |j = 1, . . . ,mp is a set of linearfunctions (linear on each element). A shapefunction is associated with a node, it is con-tinuous, takes on the value 1 at its node and 0at the other nodes of its compact support. Ithas local support, in the sense that the shapefunction is non-zero only on the elements bor-dering to its node. A vector field is now ap-proximated by un ≈

∑mvj=1 U

nj ϕj and a scalar

field by pn ≈∑mp

j=1 Pnj ψj , where the super-

script n denotes evaluation at time step n, asbefore.

The finite element interpolants are thensubstituted in equations (17 – 20) and appro-priate test functions v and q chosen to pro-duce a set of matrix equations.

Taking the first equation (17) we have:

mv∑j=1

[2Re∆t

∫Ωϕj(U

n+1/2j − Un

j ) · vdΩ +

∫Ωµ sym(∇(Un+1/2

j − Unj )ϕj)) · ∇vdΩ

]=

−mv∑j=1

[2

∫Ωµ sym(∇ϕjUn

j ) · ∇vdΩ +

Re

∫Ω((Un · ∇)ϕjUn

j )) · vdΩ]+

mp∑k=1

(∫

Ωψk(∇ · v)dΩPn

k ). (21)

It is convenient to represent all the vectors Uj ,in R

3, j = 1 · · ·mv, as one combined columnvector U of size 3mv, thus

U = (U11, U12, · · · , U1mv , U21, U22, · · · ,U2mv , U31, U32, · · · , U3mv)

T

where Ulj is the xl-component of Uj for l =1, · · · , 3.

We consider the various types of integralswhich appear in equation (21). The first termis of the form:

mv∑j=1

∫ΩφjUj · vdΩ.

Expanding Uj using the standard Euclideanbasis vectors e1, e2, e3 leads to

3∑l=1

mv∑j=1

∫ΩφjUljel · vdΩ.

The Galerkin method is adopted by choos-ing the test functions to be generated by theshape functions V . Letting ϕl

j = ϕjel andtaking as test functions v = ϕm

i for m =1, · · · , 3 and i = 1, · · · ,mv yields the follow-ing 3mv terms

3∑l=1

mv∑j=1

∫Ω

ϕlj · ϕm

i dΩUlj .

Taking the above as elements of a 3mv columnvector, it clearly can be represented as thematrix–vector product MU where M has theblock structure

M =

M11 M12 M13

M21 M22 M23

M31 M32 M33

where

Mlmij =

∫Ω

ϕlj · ϕm

i dΩ. (22)

Evidently Mlm = 0 for l = m and Mll are allidentical and given by

Mllij =

∫ΩϕiϕjdΩ.

This matrix M is the mass matrix.To deal with the second term in (21), after

expanding Uj in terms of the basis vectors,we consider

3∑l=1

mv∑j=1

∫Ωµ sym(∇(Uljϕ

lj)) · ∇vdΩ.

This yields the 3mv terms

3∑l=1

mv∑j=1

∫Ωµ sym(∇(Uljϕ

lj)) · ∇ϕm

i dΩ.

9

As a vector this latter term can be expressedas SU and writing S in block form (Slm), eachblock is determined by

Slmij =

∫Ωµ sym(∇(ϕl

j)) · ∇ϕmi dΩ. (23)

S is referred to as the diffusion matrix. Notethat S is symmetric and in particular (Sml) =(Slm)T .

The next expression in (21) to consider is

3∑l=1

mv∑j=1

∫Ω((U · ∇)ϕl

jUlj) · vdΩ

(where U =∑mv

k=1 ϕkUk) producing a 3mv

vector which can be written N(U)U where

N(U)lmij =

∫Ω((

mv∑k=1

ϕkUk · ∇)ϕlj) · ϕm

i dΩ.(24)

N(U) is called the convection matrix.The final term in (21) has the form

mp∑k=1

(∫

Ωψk(∇ · v)dΩPn

k ),

yielding the 3mv termsmp∑k=1

(∫

Ωψk(∇ · ϕm

i )dΩPnk ).

Since ∇ · ϕmj = ∂ϕj

∂xmfor m = 1, · · · , 3, the

above can be represented as LP , where

L =

L1

L2

L3

and the entries of each block are defined as

Lmik =

∫Ωψk

∂ϕi

∂xmdΩ for m = 1, · · · , 3.(25)

LT is then the associated incompressibilitymatrix.

Using the above, the desired matrix equa-tion for a discretised version of step 1a is:

(2Re∆t

M + S)(Un+1/2 − Un) =

LPn − (2S +ReN(Un))Un. (26)

Equations (18) and (20) can be discretisedin a similar manner yielding the equations(27) and (28) for steps 1b and 3.

(Re

∆tM + S)(U∗ − Un) = LPn − 2SUn −

ReN(Un+1/2)Un+1/2. (27)

Re

∆tM(Un+1 − U∗) = θL(Pn+1 − Pn). (28)

For discretising step 2, we have, substitut-ing in equation (19)

θ

mp∑k=1

∫Ω∇ψk · ∇qdΩ(Pn+1

k − Pnk ) =

−Re∆t

3∑l=1

mv∑j=1

∫Ω(∇ · ϕl

j)qdΩU∗lj .

Here we take Q as the set of test functions toobtain the following set of mp equations:

θ

mp∑k=1

∫Ω∇ψk · ∇ψidΩ(Pn+1

k − Pnk ) =

−Re∆t

3∑l=1

mv∑j=1

∫Ω

∂ϕj

∂xlψidΩU∗

lj .

To express the left hand side, we introducethe pressure stiffness matrix K

(Kij) = (∫

Ω∇ψj · ∇ψidΩ) (29)

then, step 2 becomes

θK(Pn+1 − Pn) =−Re∆t

LTU∗. (30)

Equations (26), (27), (30) and (28) thenconstitute the matrix representation of theproblem. It is important to realise that theintegrands appearing in the definitions of M,K, and L can all be evaluated analyticallysince the functions ϕi and ψk are of a simpleform, and so the matrix elements are knownat the start of the computation.

10

3.2 Solving the Equations

Equations (26), (27) and (28) are solved usingJacobi iteration. Although the mass matrixM is generally very large, it is not necessary tostore such a matrix explicitly, and in practice,only the element sub–block matrices Me needbe constructed. The iteration takes the form:

X(r+1) = X(r) −

ωD−1mel∑e=1

LTe MeX(r)

e − ωD−1B (31)

where D is a chosen diagonal form and ω is apositive relaxation factor [HTW91, DTW92].

The direct Choleski method is employed tosolve the pressure difference equation (30).The decomposition must be performed onlyonce at the outset of the time–stepping pro-cedure. This leads to an efficient implemen-tation.

Termination for steady state is determinedby using an 2–norm on the difference be-tween the velocity vectors at consecutive timesteps and halting when this is less than somethreshold tolerance.

3.3 A discussion of relevant codingtechniques

The exposition above is at a very basic datalevel, expressed in the form of vectors and ma-trices. The form is imperative in style — dothis, then do that, update the variables andrepeat until termination — this is suitable forimplementation in any of a number of lan-guages. The preferred choice among scientificprogrammers would be a dialect of Fortran,typically Fortran–77, but Fortran–90 is be-coming more popular, see the survey [Hop97].The program developed in this section hasbeen implemented in Fortran-90 and amountsto about 15, 000–20, 000 lines of code.

Several authors have followed this styleof software development for Object–Orientedlanguages such as C++ and more recentlyJava. This typically results in classes rep-resenting vector and matrix operations with

BLAS like routines. The general impression isthat there is little gained over the use of For-tran from the conceptual point of view, eventhough the increased emphasis on software en-gineering principles that these projects have,often is beneficial for the quality of the code –especially when compared to dusty deck For-tran.

A variation on this is the use of the Diff-pack software package [BL97]. It is a supportenvironment for the development of object-oriented numerical software, and has embod-ied many good software engineering featuresand practices. The tendency is for Diffpackcode to be closer to the numerical algorithmallowing the software developer to focus moreclearly on the numerical aspects of the taskthan that experienced by a Fortran program-mer. However, Diffpack’s approach to numer-ical software development is still basically theconventional one outlined above, making thechoice of discretisation and coordinate sys-tems explicit in the code.

More applicative implementations usingfunctional languages have also been tried[GSWZ95]. In these cases also the focus ison basic data structures and operations onthem. The benefits of using function calls andrecursion rather than variable updates and it-eration show more in a greater readiness forautomatic parallelisation (see the papers andapproaches in [Szy91]) than in the way thecode is structured in the large. However, asfor object–orientation, developers working inthis area tend to put more emphasis on goodsoftware practices than does the classicallytrained Fortran programmer.

4 Coordinate FreeMethodology

In the coordinate free methodology we writethe program code based directly on the con-cepts present in the abstract algorithm as de-veloped in Section 2.6. For this we need anunderstanding of these abstract mathematical

11

concepts, together with their software reali-sation and support. Then implementing thenumerical solver becomes straightforward.

In this section we first briefly present thenotions of tensors and coordinate freeness, in-troducing the necessary notations and termi-nology. An outline is then given of the Sophuslibrary and it is indicated how the finite ele-ment method (FEM) may be implemented inSophus. Finally, we show how the solver forthe coating problem can be implemented us-ing Sophus.

4.1 Coordinate free mathematics

The concepts from algebra and coordinatefree mathematics sketched here are giventhorough treatment in the books [Lan95,Sch80].

Plain numerical types, such as the realnumbers, are often abstracted as fields orrings. Given a ring R, we may define, for anyinteger n ≥ 0, n-positional numerical typesover R, commonly known as n-dimensionalvectors v ∈ Rn. For any n, the set of n-dimensional vectors v form a vector space V .(Strictly speaking, this is a module, and onlya vector space when R is a field. However, toavoid confusion with the usage of module incomputing we shall use the term vector spacebelow).

Given a basis B = b1, . . . ,bn, a vectorv ∈ V can be identified by its coordinates v =(a1, . . . , an), i.e., ring elements a1, . . . , an ∈R, such that v = a1 ∗ b1 + . . . + an ∗ bn.Note that there is a distinction between a vec-tor v ∈ V as an n-positional numerical type,and its coordinates v with respect to a basisB ⊆ V , even though the latter also may beconsidered an n-positional numerical type. Itis only when using the normalised Cartesiancoordinate system that the data values v = v.The normal representation for vectors is rela-tive to some coordinate system, but then carehas to be taken to interpret coordinates v onlyrelative to that coordinate system.

The collection M of linear mappings from

vector spaces V to W form a vector space.If V = Rm and W = Rn, for m,n ≥ 0,we know that the linear mappings from V toW can be represented as n by m matrices,which we also may regard as (nm)-positionalnumerical types, or, in other words, as (nm)-dimensional vectors. Using the tensor prod-uct ⊗ we may combine a basis B for an m-dimensional vector space V with a basis B′

for an n-dimensional vector space W to forma basis B ⊗B′ for the (nm)-dimensional vec-tor space M of linear mappings from V to W .This means that any linear mapping ∈ M isexpressible using a linear combination of thebasis vectors bi ⊗ b′j , for bi ∈ B ⊆ V andb′j ∈ B′ ⊆ W (this does not imply that ev-ery vector can be expressed by v ⊗ w forv ∈ V and w ∈ W ). If V = R then the tensorproduct reduces to the ring-vector product.

Covectors v ∈ V ∗ are (n1)-dimensional vec-tors which take n-dimensional vectors v′ ∈V to 1-dimensional vectors (ring elementsv(v′) ∈ R). There is an operation ∗ : V →V ∗, dualisation, which takes a vector and re-turns a covector. The inner product, or thedot product v · v′ of vectors v,v′ ∈ V is de-fined by v · v′ = v∗(v′).

Normally we have to do computations on avector v ∈ V on its coordinate representationv relative to a coordinate system B ⊆ V . It isimportant that changing the basis of the vec-tor space V should not change the effect ofoperations on the vector v ∈ V . This can beachieved by making the operations, such asthe dot product and dualisation ∗, aware ofwhich basis is being used. Then appropriatecorrective action may be taken in the compu-tations, and we may use operations on vec-tors independently of coordinate system, thusachieving coordinate free mathematics.

Our tool for doing this is the notion of ten-sors. Given a ring R, an integer b ≥ 1, ab-dimensional vector space V with basis vec-tors B ⊆ V , then tensor spaces T (k)

R,B are then-dimensional vector spaces where n = bk,for some k ≥ 0. It is easy to see that the

12

ring itself is the tensor space T(0)R,B for any

b. The tensor product of a (bk1)-dimensionaltensor τ1 ∈ T

(k1)R,B and (bk2)-dimensional ten-

sor τ2 ∈ T(k2)R,B is a (bk1+k2)-dimensional ten-

sor (τ1 ⊗ τ2) ∈ T(k1+k2)R,B . The dot prod-

uct of two tensors τ1, τ2 ∈ T(k)R,B is a tensor

(τ1 · τ2) ∈ T(0)R,B.

We need to distinguish between the tensorspaces and also on how they are formed withvector and covector components. This givesus many distinct tensor spaces for any bk di-mensions, k > 0, providing a distinct slice forevery combination of covectors and vectors inthe formation of T (k)

R,B. In conventional nota-tion these slices are distinguished using upperand lower indices. Making certain that thecovector and vector components match up, wemay apply one tensor as a linear mapping toanother tensor. Specifically this notion carriesdown to b-dimensional tensors T (1)

R,B (applyingcovectors to vectors) and 1-dimensional ten-sors T (0)

R,B (multiplication of ring elements).

4.2 Scalar, vector and tensor fields

For a ring or field R, such as the set of realnumbers, given a set X, the set FX→R offunctions f : X → R forms a ring with, forany f, g ∈ FX→R, multiplication defined by(f · g)(x) = f(x) · g(x) for all x ∈ X, additionby (f+g)(x) = f(x)+g(x) for all x ∈ X, andso forth. The ring FX→R is called a scalarfield. We may consider every ring elementa ∈ R as a scalar field a ∈ FX→R by defininga(x) = a for every x ∈ X. Scalar fields FX→R

may be used in the constructions of vectorspaces and tensor spaces, yielding the notionsof vector fields VX→R, with basis E ⊆ VX→R,and tensor fields T

(k)FX→R,E , for every k ≥ 0.

A scalar field assigns a different value to ev-ery point in X. A vector field likewise maychange throughout X, such that every pointof X is assigned a vector with different direc-tion and magnitude. The basis vectors for avector field may thus define any kind of curvi-

linear coordinate system, including Cartesianand cylindrical.

For X a vector space over the ring R, thenX will be included in VX→R in the same wayas R is included in FX→R. And, as before,there are inclusions from FX→R to T

(0)FX→R,E

and from VX→R to T(1)FX→R,E .

If the set X satisfies the properties of beinga manifold, i.e., it has the notions of direc-tion and proximity, we may define non–trivialderivation operations on the scalar field. Typ-ically X will be a b-dimensional vector spacewith basis vectors B ⊆ X, such as the 3-dimensional space in which most physics takesplace. We may then define partial derivatives∂f∂x of the scalar fields f ∈ FX→R along anyvector x ∈ X. The partial derivative willalso be a scalar field since it changes through-out X, so ∂f

∂x ∈ FX→R. Knowing the partialderivatives along the basis vectors B is suf-ficient to compute the derivatives along anyvector in X. If X is a b-dimensional vec-tor space this forces the vector field VX→R

to have b dimensions, and the basis E forthe vector field will then have b linearly inde-pendent b-dimensional vectors. At the levelof tensor fields T (k)

FX→R,E we may now definemany derivation operations, all of which maybe computed from the partial derivatives onthe scalar field FX→R.

For a scalar field f ∈ FX→R, an integrationa =

∫Ω fdX of f for a subdomain Ω ⊆ X with

basis vectors B ⊆ X yields a ring element a ∈R. Scalar field integration gives rise to tensorfield integration α =

∫Ω σdX for σ ∈ T

(0)FX→R,E

yielding values α ∈ R.Derivation and integration operations on

tensor fields, like the dot product, depend onthe choice of basis E for VX→R.

We may now treat all symbols in the equa-tions of Section 2.6 as tensors and coordinatefree operations on tensors. Some of the de-scriptions in Section 2.1 are now explainedin the more general tensor setting. Let ussummarise the operations we need, after thesimplification of the solver, and assuming the

13

appropriate tensor slices:

• sym(σ) is the tensor symmetrisation op-erator taking a tensor σ ∈ T

(k)FX→R,E to

a tensor in the symmetrical subspace ofT

(k)FX→R,E .

• +, − are the tensor field addition andsubtraction operations taking a pair oftensor fields from T

(k)FX→R,E to a tensor

field in T(k)FX→R,E .

• a ∗ τ is the scalar-tensor field multipli-cation taking a ∈ T

(0)FX→R,E and τ ∈

T(k)FX→R,E to a tensor field in T

(k)FX→R,E .

Note that a ∗ τ = a ⊗ τ . Normally wewrite aτ for a ∗ τ .

• σ ·τ is the tensor field dot product takingtensor fields σ, τ ∈ T

(k)FX→R,E and return-

ing a scalar field in T(0)FX→R,E .

• ∇ is the spatial derivative, which is usedin several forms:

1. (v · ∇)σ, the convective derivative,yields a tensor field in T

(k)FX→R,E for

the derivation of the tensor field σ ∈T

(k)FX→R,E in the direction of the vec-

tor field v ∈ T(1)FX→R,E ,

2. ∇σ, the gradient, yields a tensorfield in T

(k+1)FX→R,E when applied to a

tensor field σ ∈ T(k)FX→R,E , thus it

takes a scalar field to a vector fieldand a vector field to a matrix field,

3. ∇ · σ, the divergence, yields a ten-sor field in T (k)

FX→R,E when applied to

a tensor field σ ∈ T(k+1)FX→R,E , thus it

takes a matrix field to a vector fieldand a vector field to a scalar field.

•∫Ω σdX integration of a tensor field σ ∈T

(0)FX→R,E over a subdomain Ω ⊆ X yields

a ring element in R.

There is an important distinction betweentensor fields T (k)

FX→R,E based on the tensor con-struction using scalar fields as the ring, andtensor fields T : X → T

(k)R,B which directly

assign a tensor to every point x ∈ X. Theformer allow us to build advanced tensor op-erations, such as derivation operations, fromscalar field operations, such as the partialderivatives. The latter require us to imple-ment the advanced tensor operations directlyin terms of the (discretised) representation ofX, see the discussion in [Hav99b][Section 4.2].As is evident, the former, which we have cho-sen, give a clear separation between discretisa-tion methods for the scalar field and the spa-tial derivation operations at the tensor level.The latter force a tensor field implementationfor each discretisation.

4.3 A framework for a tensor basedlibrary

The Sophus library framework describes a li-brary architecture for providing the abstractmathematical concepts from PDE theory asprogramming entities. This means that anypiece of a program, or even any module inthe library, may be coded using any of theabstractions defined. At compile time, imple-mentations for each of the abstractions will bechosen, such that no circular dependencies onthe implementations occur. This means that,e.g., a mesh implementation may build on an-other mesh implementation, but that the lat-ter mesh cannot be built on the former mesh.The Sophus framework is based on the notionsof manifold, scalar field and tensor field, whilethe implementations are based on the con-ventional numerical algorithms and discreti-sations. The Sophus framework is structuredaround the following concepts:

• Basic n-dimensional mesh structureswith a ring R as template argument.These are like rank n arrays (i.e., with nindependent indices) with element typeR, but with general map operations, i.e.,

14

performing an argument function for ev-ery element. It also has specific opera-tions like +, − and ∗ mapped over allelements (much like Fortran-90 array op-erators) as well as the ability to add, sub-tract or multiply all elements of the meshby a scalar in a single operation. Thereare also operations for shifting meshesin one or more dimensions. Operationslike multidimensional matrix multiplica-tion @ and linear equation solvers such asCholeski decomposition and Jacobi iter-ation may easily be implemented for themeshes.

Not all mesh implementations will pro-vide all operations. Some implementa-tions may be more specialised, e.g., as-suming a sparse mesh or a mesh withcertain symmetries. Other implementa-tions may provide fully general paralleland sequential implementations that canbe used interchangeably, allowing easyporting between computer architecturesof any program built on top of the meshabstraction.

• Manifolds X. These are sets with a no-tion of proximity and direction. Theyrepresent the physical space Ω ⊆ Xwhere the problem to be solved takesplace.

• Scalar fields FX→R. They describe themeasurable quantities of the physicalproblem to be solved. As the basic layerof “continuous mathematics” in the li-brary, they provide the partial derivationand integration operations. Also, twoscalar fields on the same manifold maybe pointwise added, subtracted and mul-tiplied.

The different discretisation methods,such as the finite difference and finite el-ement methods, provide different designsfor the implementation of scalar fields.Scalar fields are typically implementedusing the mesh structures with reals for

the ring to store the data. Not all meshoperations are relevant in this context, soit is possible to choose mesh implementa-tions that, e.g., do not support equationsolvers or matrix multiplication, whenconfiguring implementations for a pro-gram.

• Tensors T(k)FX→R,E . These provide coor-

dinate free mathematics based on theknowledge of the coordinate system E,whether it is Cartesian, axi–symmetricor general curvilinear. The tensor classprovides the general differentiation andintegration operations, based on the par-tial derivatives and integrals of the scalarfields. Tensors also provide operationssuch as componentwise addition, sub-traction and multiplication, as well astensor product, composition and appli-cation.

The implementation is based on the basicmesh structures, with scalar fields as thering parameter. Thus tensor operationsare formed from expressions on scalarfields performed by the mesh classes.Again, many operations of the mesh arenot needed, allowing more specialisedmesh implementations to be used. Forinstance, equation solvers are not needed,while matrix multiplication algorithmsare important.

• Equation administrators. These are ab-stractions containing collections of scalarand tensor fields with the purpose ofbuilding the matrices and vectors used todescribe sets of linear equations, such asthose needed for implicit time steppingschemes. These matrices and vectors donot represent coordinate free propertiesof a physical system, but abstract the im-portant properties of linear equations.

Equation administrators are also imple-mented using mesh structures with ten-sor fields or reals as the ring, as appro-priate. Here operations like matrix mul-

15

tiplication and matrix equation solversare important, and relevant mesh imple-mentations must provide these. Also, ad-ditional properties like symmetries andblock diagonal structures may be ex-ploited by appropriate mesh implemen-tations.

In general a partial differential equation pro-vides a relationship between spatial deriva-tives of tensor fields representing physicalquantities and their time derivatives. Givenconstraints in the form of the values of thetensor fields at a specific instance in timetogether with boundary conditions, the aimof a PDE solver is to show how the phys-ical system will evolve over time, or whatstate it will converge to if left by itself. Us-ing Sophus, the solvers are formulated on topof the coordinate–free layer, forming an ab-stract, high level program for the solution ofthe problem.

4.4 The finite element method inSophus

The finite element method presented in Sec-tion 3.1, is now redeveloped in a more abstractmanner suitable for implementation in the So-phus approach. In this more general setting,the method is based on the observation thatgiven a manifold X with basis B ⊆ X anda ring R, a scalar field p ∈ FX→R, may beapproximated by a sum p ≈

∑g∈G Pg · g for

scalar fields g ∈ G ⊆ FX→R, termed shapefunctions, and scalars Pg ∈ R. The larger theset G, the better the approximation, but thiswill increase computation times since largerdata sets will have to be computed. For nu-merical reasons, different scalar fields shouldbe approximated by different shape functionsets, but if these different discretisations areto be used in the same expressions, the dif-ferent sets of shape functions must be coordi-nated.

This coordination is achieved by splittingthe domain X into a set E of disjoint elements

e ∈ E , such that ∪e∈E e = X and for eachelement designate a fixed set of integrationpoints. A scalar field’s value at an integrationpoint represents its average value in a subre-gion of the element. In a 2-dimensional casethe domain may typically be split into trian-gles, the choice adopted in Section 3.1. Forthe FEM, the shape functions are continuouswithin elements and have small support, i.e.,are non-zero only for a few elements. This isnormally restricted further, so that the func-tions g ∈ G take their maximum value 1 ∈ Rat exactly one point – the nodal point – in thedomain X, and are non-zero only on those el-ements adjacent to that point (referred to asthe domain of local compact support for g).Also, a shape function is 0 at the nodal pointsof all other shape functions within its collec-tion. These are the same constraints as usedin the conventional approach presented in Sec-tion 3.1.

The shape functions g ∈ G are normallychosen so that the partial derivatives ∂g

∂x ∈FX→R for x ∈ B ⊆ X and the integral∫e gdX ∈ R on an element e ⊆ X may be

computed analytically. In Section 3.1, for ex-ample, these were chosen to be either linearor quadratic functions. Since the differentia-tion and integration operations are linear withrespect to R, we have that

∂p

∂x≈

∑g∈G

Pg ·∂g

∂x∫ΩpdX ≈

∑e∈E

(∑g∈G

(Pg ·∫

egdX)

)

In the variational form, all expressions involv-ing the scalar fields are integrated in eachPDE equation. This means we do not needto approximate the scalar field or tensor fieldexpressions as such, but rather their effecton the integrals. The values at the integra-tion points provide such an approximation,so these are the only values we really need touse when computing scalar field expressions.This also implies that elements and integra-tion points are the only coordination needed

16

between scalar fields. Each scalar field maybe based on different sets of shape functionsfor that matter.

4.5 Developing a solver for thecoating problem

Recall, that for the coating problem we areworking with a subdomain Ω ⊆ X of thephysical 3-dimensional world X. The tensorfields are T

(k)FX→R,E , where R is the set of re-

als, E = e1, e2, e3 ⊆ VX→R are the stan-dard basis vectors, and k = 0 (scalar fields),k = 1 (vector fields) or k = 2 (matrix fields).In the variational form of the equations forthe solver in Section 2.6 we are using scalarfields q ∈ Q ⊆ T

(0)FX→R,E and vector fields

v ∈ V ⊆ T(1)FX→R,E as test functions for the

integrals.The coordinate free, variational form, of the

solver equation steps (17 – 20) for the coatingproblem need some refinement to serve as analgorithm for an actual computation. Lookingat the left hand sides of the equations we seethere are three problems to address:

• The integrals compound the value ofscalar fields into a scalar, so we need torestore the unknown scalar fields on theleft hand side from these scalars (steps 1,2 and 3).

• The vector fields representing the veloc-ity are “dotted” with a vector field, soonly information about the magnitude ofthe left hand side vectors is known, withno information about the direction (steps1 and 3).

• The symmetrisations of ∇u are “dotted”with ∇v terms, thus intermixing infor-mation concerning all components of thevector u, so that not even the magni-tude of the unknown vectors are explic-itly available (step 1).

The above is a more abstract view than thatindicated in Section 2.6. But, as in the con-ventional case, the solution to these problems

is to generate more equations at each step,by choosing appropriate sets of test functions,so that we get enough scalars to computethe unknown scalar and vector fields. Howto achieve this becomes increasingly involved.We relate the techniques to the individualsteps of the algorithm, starting with the sim-plest cases.

• Step 2: a scalar field integrated to areal value. If we approximate the scalar-field (pn+1 − pn) ∈ T

(0)FX→R,E by a sum∑

g∈G(Pn+1g −Pn

g ) · g for scalars (Pn+1g −

Png ) ∈ R and shape functions G ⊆

T(0)FX→R,E , we may move the scalars out

of the derivation and integration expres-sions. We may then reformulate step 2to

∀q ∈ Q

[θ

∑g∈G

(Pn+1g −Pn

g )(∫

Ω∇g·∇qdX) =

−Re∆t

∫Ω(∇ · u∗)qdX

].

This gives us a system of equations with|Q| right hand sides1

Bq =−Re∆t

∫Ω(∇ · u∗)qdX

for each q ∈ Q. It has |G| unknowns(Pn+1

g − Png ) for g ∈ G. The |Q| × |G|

integrals on the left hand side are in-dependent of the variables of the prob-lem, so we may define a mesh matrixKq,g =

∫Ω ∇g · ∇qdX for g ∈ G, q ∈ Q

(this is a matrix with data elements fromR, and is not a tensor structure but just amesh–of–R structure). This correspondsto the pressure stiffness matrix K from(29). Ensuring that |Q| = |G|, the un-knowns are uniquely determined, and wemay solve the system θK@(Pn+1−Pn) =B using a suitable matrix solver.

Assuming that Png is known it is easy

to find Pn+1g once the system is solved

1For a set X the notation |X| means the cardinalityof X.

17

and the (Pn+1g − Pn

g ), for g ∈ G, havebeen found. Calculating the scalar fieldpn+1 ∈ T

(0)FX→R,E will be simplified if G

is taken to be the shape functions usedin the discretisation of the scalar fieldsp ∈ FX→R as described in Section 4.4.This also ensures that we will not loseany accuracy by the approximations ofpn+1 in the system of equations.

• Step 3: a vector field compounded toscalar field and then integrated to a realvalue. We may represent the unknownvector (un+1 −u∗) ∈ T

(1)FX→R,E as the lin-

ear combination u1 ∗e1 +u2 ∗e2 +u3 ∗e3

of basis vectors e1, e2, e3 ∈ E ⊆ T(1)FX→R,E

and scalar fields u1, u2, u3 ∈ T(0)FX→R,E .

Then the equation becomes

∀v ∈ V

[Re

∆t

3∑i=1

(∫

Ωui ∗ ei · vdX) =

θ

∫Ω(pn+1 − pn)(∇ · v)dX

].

Now we can restore the scalar fields usingthe technique of shape functions g ∈ G′

as above, giving the following system ofequations for each v ∈ V

Re

∆t

∑g∈G′

(3∑

i=1

(Un+1(g,i) − U∗

(g,i))(∫

Ωgei · vdX)

)

= θ

∫Ω(pn+1 − pn)(∇ · v)dX.

We choose G′ as the shape functions forthe discretisation of the scalar field com-ponents for u ∈ T

(2)FX→R,E . Then we en-

sure that |V | = 3|G′| so that we havethe same number of equations |V | as un-knowns, which is |G′| times the numberof dimensions. This time the matrix onthe left hand side becomes Mv,(g,i) =∫Ω gei · vdX, for g ∈ G′, i ∈ 1, 2, 3 and

v ∈ V . We need to treat (g, i) as one in-dex in order to have M be a normal ma-trix. This corresponds to the mass ma-trix M from (22).

• Steps 1a and 1b: symmetrisation withvector field compounded to scalar fieldand then integrated to a real value. Usingthe same technique as above, we may eas-ily separate the unknowns from the first(explicit) part of the left hand side terms.This also separates the unknowns fromthe symmetrised term since symmetrisa-tion is linear with respect to scalar multi-plication. Then we may reformulate step1a to, ∀v ∈ V

∑g∈G′

( 3∑i=1

(Un+1/2(g,i) − Un

(g,i))

∫Ω(2Re∆t

gei·v+µ sym(∇(gei))·∇v)dX)

=

− 2∫

Ωµ sym(∇un) · (∇v)dX −

Re

∫Ω((un·∇)un)·vdX+

∫Ωpn(∇·v)dX

with equation matrix M ′ = 2Re∆t M + S,

and step 1b to, ∀v ∈ V :

∑g∈G′

( 3∑i=1

(U∗(g,i) − Un

(g,i))

∫Ω(Re

∆tgei·v+µ sym(∇(gei))·∇v)dX

)=

− 2∫

Ωµ sym(∇un) · (∇v)dX −

Re

∫Ω((un+1/2 · ∇)un+1/2) · vdX +∫

Ωpn(∇ · v)dX

with equation matrix M ′′ = Re∆tM +

S, where Sv,(g,i) =∫Ω µ sym(∇(gei)) ·

∇vdX. Here S is the diffusion matrixS from (23). This provides us with aug-mented matrices compared with step 3,but otherwise with the same number ofequations and the same number of un-knowns as in step 3 above.

Note that we do not need to build counter-parts to the incompressibility matrix L in (25)

18

nor the convection matrix N in (24). This ispossible since those represent right hand sides,and thus are implied by the tensor expressionsin this approach.

We will use the Galerkin simplification onthe resulting systems of equations by choosingscalar field test functions Q = G ⊆ T

(0)FX→R,E

and vector field test functions V = g ∗ e|g ∈G′, e ∈ E ⊆ T

(1)FX→R,E . Normally, we will

not choose G = G′, as there are different nu-merical constraints on the pressure p and thevelocity u.

Combining this information, we arrive atthe final coordinate free algorithm for thecoating problem. The collections of shape andtest functions may be kept in a mesh datastructure. We may then use the mesh mapoperations to generate the right hand sidesand left hand side matrices. This eliminatesthe need for explicit loops for the generationof the equations. Then we employ the matrixsolvers written for the mesh classes to find theunknowns. The algorithm repeats the follow-ing steps until time–stepping convergence cri-teria are met, given initial values for Un andPn:

Calculate un from Un;Calculate pn from Pn;Step 1a: solve for Un+1/2 − Un in

M ′@(Un+1/2 − Un) =(∫Ω

−2µ sym(∇un)·(∇v)−Re((un·∇)un)·v+

pn(∇ · v)dX)

v∈V

Calculate un+1/2 from Un+1/2 −Un, Un

and G′;Step 1b: solve for U∗ − Un in

M ′′@(U∗ − Un) =(∫Ω

−2µ sym(∇un) · (∇v) −

Re((un+1/2·∇)un+1/2)·v+pn(∇·v)dX)

v∈V

Calculate u∗ from U∗ − Un, Un and G′;

Step 2: solve for Pn+1 − Pn in

θK@(Pn+1 − Pn) =(∫Ω

−Re∆t

(∇ · u∗)qdX)

q∈Q

Calculate pn+1 from Pn+1 −Pn, Pn andG;Step 3: solve for Un+1 − U∗ in

Re

∆tM@(Un+1 − U∗) =(∫

Ω

θ(pn+1 − pn)(∇ · v)dX)

v∈V

Set Un as Un+1 −U∗ plus U∗ and ensur-ing boundary condition;Set Pn as Pn+1−Pn plus Pn and ensur-ing boundary condition;

Recall that the velocity values at the bound-aries are prescribed, hence we must ensurethat these values remain unchanged at everystep. The matrix K will be banded and sparseand the equations in step 2 can be solved us-ing Choleski decomposition. The matrices M ,M ′ and M ′′ are very large. With a carefulchoice of elements and using orthogonal basisvectors, i.e., i = j implies ei · ej = 0, matrixM can be reduced to a banded form. Jacobiiteration will be a useful technique for solvingthe equations in steps 1 and 3. The element–by–element construct and solve procedure andmatrix conditioning provide such a choice.

For this problem appropriate choices fortest and shape functions are

• for Q = G: functions which reside at thevertices of the elements, and are linearwithin each element, and

• for V = G′: functions which reside atthe vertices and mid-points of the edgesof the elements, and are quadratic withineach element.

Note that the mesh classes are used for manydistinct purposes in the solver:

• in the implementation of the scalar field,

19

• in the implementation of the tensors,

• for storing the set of test functions, and

• for data matrices K and M , M ′ and M ′′.

In a configuration of the solver program dif-ferent implementations of the Mesh class maybe chosen for each of these different purposesin order to reduce storage requirements, im-prove run–time efficiency and provide parallelexecution.

Testing for convergence is performed usingthe L2 norm for velocities and pressure.

Coding this algorithm as a computer pro-gram is now straightforward if a library withthe concepts of the Sophus framework is avail-able. We have not fully implemented this ap-plication in Sophus yet, but based on experi-ence with this framework [HFJ99] the follow-ing seems reasonable: The PDE solver wouldbe written as a procedure, and based on thedetailed exposition above this should only beabout 100-200 lines of code, including test fortermination. Additional procedures to inputdata sets, set up the data and output the re-sults will increase the solver module code sizeto about 1, 000 lines of code. The code neededfor a simple user interface, I/O file handlingand configuration of the PDE solver typicallylies around 1000 lines of code as well. Thusa complete solver and configuration may bewritten in less than 2000 lines of code.

4.6 A discussion of relevant codingtechniques

The coding technique we advocate is basedon notions of data abstraction and encapsula-tion. These may take the form of the classconstruct in object–oriented languages likeC++ [Str97], Eiffel [Mey92], GJ [BOSW98]and Java [GJS96], type abstraction and func-tors in applicative functional languages likestandard ML and Haskell, or packages in im-perative languages like Ada and Fortran-90.The reuse of modules such as Mesh in both the

implementation of scalar fields and the imple-mentation of tensors requires template classesor generic packages, as present in Ada, C++,Eiffel, standard ML, Haskell and GJ.

The structuring mechanism does not forceany specific coding practice for implementingthe algorithms. Thus both applicative styles,as supported by functional languages, andmore conventional styles that modify vari-ables for reuse of storage may be used. Thelatter encompasses imperative styles, whichare typical of Fortran, Ada and C++, andobject-oriented styles, which are supported byC++, Eiffel, GJ and Java. Within each groupone may favour languages which allow oper-ators and overloading. This supports a morealgebraic notation by making it possible todefine scalar field and tensor operations withinfix syntax and names like +, ∗, −, / etc.Support for this can be found in diverse lan-guages as C++, standard ML and Fortran-90.Only standard ML allows user defined infixoperator names, the other languages only sup-port a limited set of names which is quicklyexhausted by the plentitude of tensor levelunary and binary operators.

We have developed Sophus using C++ inan imperative, object–oriented manner. Thismeans that the programmer may have fullcontrol over creation of temporary variablesand reuse of storage by modifying the val-ues of variables. This style tends to favourmachine efficiency. The development of thecoordinate free algorithm above has an im-perative flavour in its sequencing of opera-tions and iteration over the main equationsfor the PDE solver. Sophus also allows alge-braic style expressions by utilising the oper-ator overloading permitted by languages likeC++ and Fortran-90. This seems to have anegative effect on execution time efficiency,but provides a greater ease of programmingwhich may improve software development ef-ficiency. Sophus can easily be reimplementedin other languages which support the neces-sary abstraction mechanism. If the emerg-ing Fortran-2000 supports templates it would

20

seem a suitable language for this style of pro-gramming.

The tensor oriented package RHALE++[BPR92, WBPR93] is also implemented inC++ using an object–oriented, imperativestyle. This package differs from Sophus byimplementing vector and tensor fields directlyon the manifold, instead of lifting the scalarfield. The package Overture [BH96] doesnot provide tensor abstractions but providesthe scalar field abstractions (the continuouslevel). Compose [Ahl97, Ahl99] adds equa-tion handlers on top of these, but the tensorlevel is still lacking.

5 Modifying the Problem

The quality of a software developmentmethodology and programming style can bestbe evaluated by checking how easy it is tomodify and upgrade programs. For the coat-ing problem one such modification is thechange of coordinate system, motivated bythe annular nature of the problem. Us-ing cylindrical coordinates the data sets maybe reduced to two–dimensional scalar fields.Cylindrical coordinates have z–axis at thecentre of the wire, r–axis as radial distancefrom the z–axis, and θ-axis as azimuthal ro-tation angle of an rz–plane. The data fieldswill vary only along the r– and z–axis, beingconstant along the θ–axis. Thus all partialderivatives with respect to θ vanish, and thereis no need to store information for this axis.

5.1 Conventional case

We now describe the formulation using cylin-drical coordinates, where we take an axi-symmetric geometry which would be a typ-ical situation for the coating problem. A con-centricity assumption is adopted for the par-ticular coating problem being considered, sou = (ur, 0, uz). The integration over the do-main becomes specific for any particular ge-

ometry, so∫Ωf(x)g(x)dΩ ≡ 2π

∫r

∫zf(r, z)g(r, z)rdzdr,

and similarly for the vector and tensor innerproducts. In cylindrical coordinates, using vfor a vector and s for a scalar, and the partic-ular assumptions of the problem,

∇ · v =1r

∂

∂r

(rvr

)+∂vz

∂z,

∇s = δr∂s

∂r+ δz

∂s

∂z,

where δr and δz are unit vectors in the r andz directions, respectively, and

∇ = δr∂

∂r+ δθ

1r

∂

∂θ+ δz

∂

∂z. (32)

With the above definitions, the operators inthe variational formulation of the problem (17– 20) can be replaced to yield a formulation incylindrical coordinates. For example the dyad∇u can be evaluated, using equation (32) andproperties of unit vectors δr, δθ and δz, to be;

∇u =

∂ur

∂r 0 ∂uz∂r

0 urr 0

∂ur∂z 0 ∂uz

∂z

. (33)

By expanding the Uj in terms of the basevectors δr, δθ and δz and using as test func-tions ϕr

i = ϕiδr and ϕzi = ϕiδz we arrive at

the following expression for the S matrix:

S =[

Srr Srz

(Srz)T Szz

]

where

Slmij =

∫Ωµsym(∇ϕl

j)∇ϕmj dΩ (34)

and l,m ∈ r, z. Using (33) we have

sym(∇ϕr) =

2∂ϕ∂r 0 ∂ϕ

∂z

0 2ϕr 0

∂ϕ∂z 0 0

21

and

sym(∇ϕz) =

0 0 ∂ϕ

∂r0 0 0∂ϕ∂r 0 2∂ϕ

∂z

.

Substituting in (34) we can express the com-ponents of S as follows:

Srrij = 2π

∫r

∫z

[2∂ϕi

∂r

∂ϕj

∂r+ 2

ϕiϕj

r2+

∂ϕi

∂z

∂ϕj

∂z

]rdzdr,

Srzij = 2π

∫r

∫z

[∂ϕi

∂r

∂ϕj

∂z

]rdrdz,

Szzij = 2π

∫r

∫z

[2∂ϕi

∂z

∂ϕj

∂z+∂ϕi

∂r

∂ϕj

∂r

]rdzdr.

In a similar way, the remaining system ma-trices, defined in axi–symmetric cylindricalcoordinates are given by;

Mij = 2π∫

r

∫z

[ϕiϕj

]rdzdr, (35)

N(V )ij =

2π∫

r

∫zϕi

mv∑=1

[ϕlV

r

∂ϕj

∂r+ϕlV

z

∂ϕj

∂z

]rdzdr,

(36)

Kkl = 2π∫

r

∫z∇ψk · ∇ψlrdzdr, (37)

L1li = 2π

∫r

∫zψl∂φi

∂rrdzdr,

L2li = 2π

∫r

∫zψl∂ϕi

∂zrdzdr. (38)

Here V r and V

z are the nodal velocity com-ponents in radial (r) and axial (z) directionsrespectively.

5.2 Coordinate free case

The solver for the coating problem was pre-sented in a coordinate free notation in Sec-tion 4.5. This means that the solver is inde-pendent of coordinate system, and need notbe changed when moving to cylindrical coor-dinates. However, the configuration must bealtered to provide the tensor class with thedefinition of the appropriate coordinate sys-tem and the scalar fields must be reduced to2-dimensional form. These changes will onlyaffect a few lines in the configuration mod-ule, assuming that the necessary modules arepresent in the Sophus library.

The changes in configuration sketchedabove may not be sufficient to gain optimalspeed for the axi–symmetric problem. Thereason is that, unless the tensor class has beenoptimised for axi–symmetry, it will still acti-vate all the computations of a 3-dimensionalproblem. This can be reduced if a specificaxi–symmetric version of the tensor class isimplemented. Such an implementation maytake 1000–4000 lines of code, but need not bewritten from scratch.

6 Discussion

In this paper, we have presented two differ-ent approaches to developing numerical soft-ware. The first, the conventional methodol-ogy, is that followed by the majority of thenumerical programming and applied mathe-matical community. The other approach, ad-vocated here, is an abstraction method usingon coordinate free mathematics.

We can view the two methods as indicatedin Figure 2. Both methods start with themathematical formulation on the left. Theconventional method then drops down to themachine level (left downward arrow and bot-tom horizontal arrow). In the coordinate freemethod, all development takes place at theabstract level, and the library modules linkdown to the machine level (top horizontal ar-row and dotted right vertical arrow).

22

PDE AbstractAlgorithm

Scalar fields, tensors

AbstractProgram

discretisation

library

DiscretisedAlgorithm

Arrays, Matrices

DiscretisedProgram

Figure 2: Coordinate free versus conventional methodology.

We observe here one symptom of a culturaldivide between the field of programming the-ory and numerical analysis. This divide doesnot simply depend on the individual prob-lems each community normally addresses, butgoes deeper, and depends on the way we rea-son about problem solving and programming.This can be seen in the different methodolog-ical approaches to solving a complex problemlike the coating problem and its implementa-tion using the finite element method (FEM),as illustrated in this paper. This indicatesthat for the abstraction method to be ac-cepted by the numerical community would re-quire new training and instruction. Thus onlya gradual transition to coordinate free numer-ics and other abstraction oriented methodolo-gies is to be expected.

From a programming theory viewpoint,there is a definite need to present the coatingproblem at the abstract level as far as possi-ble. Only after all the technical details havebeen exposed at that level, should the discreti-sation technique be introduced as an orthogo-nal issue. Here the FEM should be exposed al-gorithmically, not solely on its mathematicalmerits as an approximation technique. If thisis done properly, the change of coordinate sys-tems, such as switching from Cartesian to axi–symmetric will be orthogonal to both the de-tailed exposition of the abstract mathematicalalgorithm and the discretisation technique.

The two methodological approaches to the

presentation of the problem as discussed inthis paper, are exposed in the manner thesoftware development is handled.

Conventional software development in thefield of computational modelling typicallycommences with some partial differentialequation (PDE). This is then refined into anabstract algorithm, and then experience andinsight is used to transform to a discretisedversion of the algorithm. Further refinementtakes place at the discrete level, and the lan-guage being used allows for the elementarydata types of arrays and matrices. We thenarrive at a sequential program, that may befurther refined into a parallel program.

The software development methodology wepropose would also start with the step of con-verting from a PDE to an abstract algorithm.The departure then lies in the further devel-opments that would stay at a mathematicallevel, yielding an abstract program. This maythen be linked together with a software librarysuch as Sophus, yielding either a sequential ora parallel program without any further signif-icant modification.

The two different development strategiesgive vastly different software characteristics.First, consider the relative sizes of code pro-duced by the two approaches. The conven-tional Fortran code for our case study totalsapproximately 18, 000–19, 000 lines of code.In contrast, the exposition of the coating pro-gram and its detailed pseudocode is well be-

23

low 1, 000 lines of code, with an estimate ofthe size of the final coded application pro-gram being approximately 2, 000 lines2. Tak-ing lines of code as a measurement of the de-velopment costs, which is the basis for costestimating models like COCOMO [Boe81], wefind an overwhelming reduction in code devel-opment costs for the coordinate free method-ology compared to the traditional methodol-ogy.

Second, consider the modifiability andadaptivity of the resulting software. Theconventional development produces one ap-plication, and reuse of components from thissoftware will be incidental. The Sophus Li-brary framework is designed for reuse andto be incrementally implemented. Basicallythe solver for a new problem relies on theconcepts defined by the Sophus library inter-face. When configuring the program, relevantmodules from the library are reused, but ifthe library lacks an implementation with cer-tain characteristics, such a code may be de-veloped and integrated into the library. Thecost of implementing a discretisation fromscratch, i.e., defining the manifold with asso-ciated point set and scalar field, we estimateas requiring approximately 4, 000 lines of code[HFJ99]. Adding a new discretisation tech-nique for an existing manifold corresponds todeveloping only 1, 000–2, 000 lines of code. Itshould also be recalled that all implementa-tion of the same abstraction, such as that ofscalar fields, have the same interface. So thatgiven two different scalar field discretisations,we may interchange them within the same ap-plication program with little adaptation.

The above observations and statistics in-

2This comparison may seem quite unfair since weare comparing unstructured Fortran code without theuse of libraries with estimates of highly structuredC++ code using library modules. The comparisonis still relevant, as we are comparing the outcome oftwo different development methodologies. We are notdiscussing whether code can be structured in one lan-guage or not in another, nor the general availabilityof libraries and how these may be used in differentlanguages.

dicate that the abstraction oriented method-ology promoted in this paper may well im-prove computational modelling productivitydramatically. An added bonus is that suchan approach supports easy transition betweensequential and parallel versions of the code[Hav99a].

Traditionally, applied mathematicians andnumerical analysts have been sceptical inadopting programming languages other thanFortran. This is mainly due to a fear of ef-ficiency loss in their codes. This no longerseems the case, as a language such as C++and the use of abstractions in many cases, hasbeen shown to be comparable in efficiency toFortran, see [ABC+97, Rob96, VJ97]. This isdeemed highly encouraging for emerging ab-straction oriented implementations of numer-ical solvers. Unfortunately, the resulting effi-ciency seems sensitive to memory layout andother factors which are difficult to control.However, a source–level transformation tool,such as CodeBoost [DHH99], can be invalu-able in this respect. It makes it possible tosystemise experiments with various data lay-outs and other transformations of the code.It is clear that several pilot implementations,with execution speed comparable to conven-tional Fortran code, of different problems isneeded to convince a larger proportion of thenumerical community of the benefits of ab-straction oriented methodologies.

A further open question, clearly relevant tothe practitioner, is to what extent this man-ner of writing programs affects numerical er-ror propagation. There is no reason to expectit to be worse than for conventionally devel-oped programs, but the ease with which onemay change discretisation technique may leadto situations where an inappropriate discreti-sation technique is being used. One possibil-ity to prevent this from happening, is to pro-vide the scalar fields with some “certificate”of their numerical properties at the abstractlevel.

24

References

[ABC+97] Erlend Arge, Are MagnusBruaset, Phillip B. Calvin,Joseph F. Kanney, Hans PetterLangtangen, and Cass T. Miller.On the numerical efficiency ofC++ in scientific computing.In Morten Dæhlen and AslakTveito, editors, NumericalMethods and Software Tools inIndustrial Mathematics, pages91–118. Birkhauser, Boston,1997.

[BH96] D.L. Brown and W.D. Henshaw.Overture: An advanced object-oriented software system formoving overlapping grid compu-tations. Technical Report LA-UR-96-2931, Los Alamos Na-tional Laboratory, 1996.

[BL97] Are Magnus Bruaset andHans Petter Langtangen. Acomprehensive set of toolsfor solving partial differentialequations; Diffpack. In MortenDæhlen and Aslak Tveito,editors, Numerical Methods andSoftware Tools in IndustrialMathematics, pages 61–90.Birkhauser, Boston, 1997.

[Boe81] B.W. Boehm. Software Engi-neering Economics. Prentice-Hall, 1981.

[BOSW98] Gilad Bracha, Martin Odersky,David Stoutamire, and PhilipWadler. Making the futuresafe for the past: Addinggenericity to the Java program-ming language. In Proceed-ings of the Conference on Ob-ject Oriented Programming Sys-tems, Languages, and Applica-tions (OOPSLA ’98), 1998. See

also URL http://www.cs.bell-labs.com/∼wadler/pizza/gj/.

[BPR92] K. G. Budge, J. S. Peery,and A. C. Robinson. High–performance scientific comput-ing using C++. In USENIXC++ Technical ConferenceProceedings, pages 131–150.USENIX Association, August1992.

[DHH99] T.B. Dinesh, Magne Haveraaen,and Jan Heering. An algebraicprogramming style for numeri-cal software and its optimisa-tion. Scientific Programming, toappear(0):22, 1999.

[Don84] J. Donea. A Taylor–Galerkinmethod for convective transportproblems. Int. J. Numer. Meth.Engng., 20:101–119, 1984.

[DTW92] D. Ding, P. Townsend, and M.F.Webster. Iterative solutionsof Taylor–Galerkin augmentedmass matrix equations. Int. J.Num. Meth. Eng., 35:241–253,1992.

[GJS96] J. Gosling, B. Joy, and G. Steele.The Java Language Specifica-tion. Addison–Wesley, 1996.

[GSWZ95] P.W. Grant, J.A. Sharp, M.F.Webster, and X. Zhang. Ex-periences of parallelising finiteelement problems in a func-tional style. Software – Practiceand Experience, 25(9):947–974,September 1995.

[Hav99a] Magne Haveraaen. Abstractionsfor programming parallel ma-chines. Scientific Programming,to appear(0):18, 1999.

25

[Hav99b] Magne Haveraaen. Algebraicsoftware methodologies for sci-entific computing. ScientificProgramming, to appear(0):40,1999.

[HFJ99] Magne Haveraaen,Helmer Andre Friis, andTor Arne Johansen. For-mal software engineeringfor computational modeling.Nordic Journal of Computing,6(3):241–270, 1999.

[HMMK92] M. Haveraaen, V. Madsen, andH. Munthe-Kaas. Algebraic pro-gramming technology for partialdifferential equations. In Pro-ceedings of Norsk InformatikkKonferanse NIK’92, pages 55–68. Tapir, Norway, 1992.

[Hop97] T.R. Hopkins. Is the quality ofnumerical subroutine code im-proving? In Arge, Bruaset,and Langtangen, editors, Mod-ern Software Tools for Scien-tific Computing, pages 311–324.Birkhauser, Boston, 1997.

[HTJTW90] D.M. Hawken, H.R. Tamaddon-Jahromi, P. Townsend, andM.F. Webster. A Taylor–Galerkin–based algorithm forviscous incompressible flow. Int.J. Num. Meth. Fluids, 10:327–351, 1990.

[HTW91] D.M. Hawken, P. Townsend,and M.F. Webster. Numericalsimulation of viscous flows inchannels with a step. Comput-ers Fluids, 20(1):59–75, 1991.

[Lan95] Serge Lang. Algebra. AddisonWesley, 1995.

[Mey92] B. Meyer. Eiffel: The Language.Prentice-Hall, 1992.

[MKH96] H. Munthe-Kaas and M. Hav-eraaen. Coordinate free nu-merics — closing the gap be-tween ‘pure’ and ‘applied’ math-ematics? Zeitschrift furAngewandte Mathematik undMechanik, ZAMM, 76(1):487–488, 1996. Special issueICIAM/GAMM 95, “NumericalAnalysis, Scientific Computing,Computer Science”, Proceed-ings of ICIAM’95, The Third In-ternational Congress on Indus-trial and Applied Mathematics.

[MTW98] H. Matallah, P. Townsend,and M.F. Webster. Recov-ery and stress–splitting schemesfor viscoelastic flows. J.Non-Newtonian Fluid Mechan-ics, 75:139–166, 1998.

[Rob96] Arch D. Robison. C++ getsfaster for scientific comput-ing. Computers in Physics,10(5):458–462, 1996.

[Sch80] Bernard Schutz. Geometri-cal Methods of MathematicalPhysics. Cambridge UniversityPress, 1980.

[Sch96] Robert S. Schreiber. An in-troduction to HPF. In Guy-Rene Perrin and Alain Darte,editors, The Data Parallel Pro-gramming Model, volume 1132of Lecture Notes in ComputerScience, pages 27–44. Springer,1996.

[Str97] Bjarne Stroustrup. TheC++ Programming Language.Addison-Wesley, 3rd edition,1997.

[Szy91] B.K. Szymanski. Functionalprogramming applied to numeri-cal problems. ACM Press, New

26

York / Addison Wesley, Read-ing, Mass, 1991.

[TW87] P. Townsend and M.F. Webster.An algorithm for the three di-mensional transient simulationof non-newtonian fluid flow. InG.N. Pande and J. Middleton,editors, Transient/DynamicAnalysis and Constitutive Lawsfor Engineering Materials, 1987.T12/1.

[VJ97] Todd L. Veldhuizen and M. EdJernigan. Will C++ be fasterthan Fortran. In YutakaIshikawa, Rodney R. Olde-hoeft, John V.W. Reynders,and Marydell Tholburn, editors,Scientific Computing in Object-Oriented Parallel Environments,volume 1343 of Lecture Notes inComputer Science, pages 49–56.Springer, 1997.

[vK86] J. van Kan. A second–order accurate pressure correc-tion scheme for viscous incom-pressible flow. SIAM J. Sci StatComput, 6(9):870–891, 1986.

[WBPR93] M. K. W. Wong, K. G. Budge,J. S. Peery, and A. C. Robinson.Object–oriented numerics: Aparadigm for numerical object–oriented programming. Com-puters in Physics, 7(5):655–663,1993.

[WK92] Roy D. Williams and SteveKarmesin. MAPS: An efficientparallel language for scientificcomputing. Technical report,Caltech, 1992.

[ZLMP85] O. C. Zienkiewicz, R. Lohner,K. Morgan, and J. Peraire.High speed compressible flowand other advection dominated

problems of fluid mechanics.In R. H. Gallagher, G. F.Carey, J. T. Ogden, and O. C.Zienkiewicz, editors, Finite El-ements in Fluids, vol 6, chap-ter 2, pages 41–88. Wiley, 1985.

[Ahl97] Krister Ahlander. An extend-able PDE solver framework.Technical report, Dept. of Sci-entific Computing, Uppsala Uni-versity, Uppsala, sweden, 1997.

[Ahl99] Krister Ahlander. An ex-tendable PDE solver withreusable components. InVladimar V. Kudriavtsev andChris R. Kleijn; contribut-ing editor Satoyuki Kawano,editors, ASME 2nd Interna-tional Symposium on Com-putational Technologies forFluid/Thermal/Structural/Chemical Systems with Indus-trial Applications, volume 397-1of PVP (Pressure Vessels andPiping), pages 39–46. Amer-ican Society of MechanicalEngineers; New York, N.Y.,1999.

27