- Application layer: solvers for PDEs such as a seismic simulator, SeisMod, or a coating problem.
- Tensor layer: handles coordinate systems, matrices and vectors and general differentiation operators.
- Scalar field layer: numerical discretisations such as finite differences and finite elements with partial derivatives.
- Mesh layer: implements grids for sequential and parallel HPC machines.

To exemplify the differences between SAGA software methodologies and
traditional software methodologies we will briefly present a computational fluid dynamics
case study. This involved developing a solver for a **coating problem** in
axio-symmetric form, with the use of the finite element method (FEM) as
numerical discretisation technique.
The case study revealed a cultural gap between the traditional thinking,
where everything is made explicit when approaching a computational
modelling problem, and the thinking needed for a more algebraic approach,
where the focus is on the abstract mathematical level. This mathematical
level is directly supported by the Sophus library
abstractions.

This development strategy can be summarised in the figure below, where we see that parallelisation of the code involves further modification of the whole system.

The upper level represents reasoning at the coordinate free, continuous mathematics level. This level is abandoned as soon as the solver strategy has been formulated. The mental gap occurs when taking into account coordinate systems and discretisations. All further refinement now takes place on the concrete level, using machine oriented primitives directly.

Choice of coordinate systems involves selection of the appropriate tensor module from the library. If an axio-symmetric version is not present it will have to be developed. This development is independent of the rest of the solver, and a new tensor module typically involves 1000-5000 lines of code.

The introduction of discretisation technique is again an orthogonal issue. If an FEM implementation is not part of the library, an independent development of such a module has to take place. A new discretisation technique typically involves a library module containing 1000-5000 lines of code.

This development strategy can be summarised in the figure below, where we see that parallelisation of the solver is also a matter of choice of library modules.

Here the development at the abstract level also includes writing the program code. This is possible since we match the mathematical concepts with software abstractions from the Sophus library. The library modules then bridge the gap down to the machine level. If a desired module is missing from the library, it is developed and coded independently of the rest of the solver application.

The SAGA approach focuses on the abstract mathematical development, and a solver at this level typically remains at 2000 lines of code, even when all technical details are exposed.

We may summarise this difference in the following diagram.

The lines of code have been added to indicate the size of the code one needs to worry about at different key stages. We have also included the cost of writing a missing library module in the transition to a working program on the right.

We see here that the amount of code one needs to be concerned with during a
development process may decrease to about a tenth of the traditional code
size when using algebraic software methodologies. This represents a
tremendous saving in software development costs, and a dramatic increase
in flexibility to test out new solver schemes.
Crucial to this improvement is the use of a library of interchangeable
software modules carefully tuned to match the abstract mathematical
concepts. The abstractions also allow switching between sequential and
parallel HPC versions of the solver without the need for reanalysing or
rewriting the software.

These pages last updated June 2005 ©2005 Magne Haveraaen, University of Bergen, Norway.

SAGA contact address.

Main SAGA WWW page.