The Problem

This chapter introduces the GoF strategy pattern along with a Fortran-specific, enabling pattern: surrogate. In scientific programming, one finds context for a strategy when the choice of numerical algorithms must evolve dynamically. Multiphysics modeling, for example, typically implies multi-numerics modeling. As the physics changes, so must the numerical methods.

A problem arises when the software does not separate its expression of the physics from its expression of the discrete algorithms. In the Lorenz system, for example, equation (4.5) expresses the physics, whereas equation (4.6) expresses the discretization. Consider a concrete ADT that solves the same equations as the abstractions presented in Section 6.2 and extends the integrand ADT but requires a new time integration algorithm. The extended type must overload the integrate name. This would be a simple task when changing one algorithm in one particular ADT. However, when numerous algorithms exist, one faces the dilemma of either putting all possible algorithms in the parent type or leaving to extended types the task of each implementing their own algorithms. Section 7.3 explains the adverse impact the first option has on code maintainability. The second option could lead to redundant (and possibly inconsistent) implementations.

The Lorenz equation solver described in Chapter 6 uses explicit Euler time advancement. That solver updates the solution vector at each time step without explicitly storing a corresponding time coordinate.