In this section, we show how the notion of operatorsÀ and argumentsÁ in (cross-product) spaces map to a software framework. As outlined in the previous section, a large class of solution methods for problems of the formÀ Ã Ä Å Æ Ç , can be reduced to a simple mathematical framework based on finite dimensional linear vector spaces and operators on those spaces. The software framework we propose will closely follow the mathematical model. As a consequence, the obtained software product will be simple and generic as well.
Consider the mathematical framework for spaces and operatorsÀ in more detail. In general, let
È
be the bounded polygonal/polyhedral domain of interest, with smooth enough boundaryÉ
È
. The linear vector spaceÂ Æ ¾ Ê Ë Ì Ì Ì Ë ¾ Í is a cross-product space ofÎ spaces (Î is the amount of degrees of freedom). Each space¾ Ï is spanned by basis functionsÐ Ñ ÏÒ Ó ÒÔ ÖÕ
Ê where Ñ ÏÒ ×
È ØÙ Ú
. An element Ä Û Â is a vector function from
È
toÚ
Í
, and is written asÄ Æ ÜÝ Ê Þ ß ß ß Þ Ý Í à, a vector of component functions. Each componentÝ Ï Û ¾ Ï is a linear combination of basis functions: for allá Û
È Ý ÏÃ á Å Æ Ô Õ â Ò Ö Ê Ý ÏÒ Ã ã Å Ñ ÏÒ Ã á Å ß (6.33) Each elementÝ Ï is associated with a unique scalar vectorä Ï Æ ÜÝ Ï
Ê Þ ß ß ß Þ Ý Ï Ô Õ
à Û
Ú
Ô Õ. At its turn,å denotes the aggregate of these vectors: å Æ Üä Ê Þ ß ß ß Þ ä Í à, andå ÏÒ Æ Üä Ï àÒ . Summarised, we have vector functionsÄ Æ ÜÝ Ê Þ ß ß ß Þ Ý Í à and related vectors of coefficient vectorså Æ Üä Ê Þ ß ß ß Þ ä Í à.
WheneverÎ Æ æ , we use a more standard notation. In this case, the space is¾ , spanned by basis functionsÐ Ñ Ò Ó
Ô
Ò Ö Ê , and elements
Ý Û ¾ are related to coefficient vectorÄ Æ ÜÝ
Ê Þ ß ß ß Þ Ý
Ô
à.
For most finite element computations, the basis functions Ñ ÏÒ of ¾ Ï have local support. How- ever,basis functions have global support in spectral finite elements computations. The local supports, also called elements, are created with the use of a triangulation algorithm.
The next subsections describe NUMLAB’s software components related to the mathematical con- cepts discussed in this section: Grid generation in section 6.5.1, bases generation in section 6.5.2, vec- tor functions in section 6.5.3, and related operators in section 6.5.4.
6.5.1
TheGridmodule
To be able to define local support for the basis functionsÑ Ï Ò later on, we need to discretise the func- tion’s domainÈ
. This is modelled in the software framework by theGridmodule, which covers the function’s domain with elementsç . ThisGridmodule takes aContouras input, which describes the boundaryÉ
È
ofÈ
. The default contour is the unit square’s contour. In NUMLAB, the grid covers regions È
in any dimension (e.g. 2D planar, manifold or 3D spa- tial), and consists of a variety of element shapes, such as triangles, quadrilaterals, tetrahedra, prisms,
hexahedrals,è -simplices (see [68]), and so on. All grids implement a common interface. This inter- face provides a few services. These include: Iteration over the grid elements and their related vertices, topological queries such as the element which contains a given point. The amount of services is a min- imum: Modules which use a grid generator and need more service must compute the required relations from the provided information.
SpecificGridgenerator modules produce grids in different manners. NUMLABcontains Delau- nay generators, simplicial generators, and regular generators, and ”generators” which read an existing grid from a file.
6.5.2
TheSpacemodule
The linear vector spaceé is implemented by the software moduleSpace.Spacetakes aGridand BoundaryConditionsas inputs. The grid’s discretisation in combination with the boundary con- ditions are used to build the supports of its basis functionsê ëì . The default boundary conditions are homogeneous Dirichlet type conditions for all solution components. In general, Dirichlet, Robin, Neu- mann, vectorial of no boundary conditions can be specified per boundary part. Recall that elements in é do not have to satisfy the Dirichlet boundary conditions. Recall that elements ofé do not have to satisfy the essential boundary conditions.
BecauseGridhas a minimal interface, some information – required bySpacefor the construc- tion of the basis functions – is not provided. Whenever this happens,Spaceinternally computes the required information with the use ofGrid’s services. A specificSpacemodule implements a spe- cific set of basis functions, such as constant, linear, quadratic, or even higher order polynomial degree, matched to the elements’ geometry. The interface of the Spacemodule follows the mathematical properties of the vector spaceé presented so far: Elementsí î ï ð é can be added together or scaled by real values. Furthermore, elementsê ëì of
é are functions, andé permits evaluation at pointsñ ð ò of such functions and their derivatives.
It should be kept in mind that elements ofé are functions, not linear combinations of functions. Therefore, the nameSPACEis somewhat misleading. However, for the brevity of demonstration, the nameSPACEwill also be used in the sequel.
In most cases, the required basis functions have local support, also called element-wise support. The restriction of global basis functionê ëì to support
ó is said to be local functionê ëô . In software, this is coded as follows: For space componentõ (soö ë), elementó , and local basis function÷ thereon,j := j(i, r)induces basis functionê ëì . The software implementation is on element-level for efficiency purposes: Given a pointñ ð ò ,Spacedetermines which support ó containsñ for the evaluation of ê ëì ø ñ ù .
6.5.3
TheFunctionmodule
As discussed, a vector functioní ú ò ûü ý þ in a space é generated by ê ëì is uniquely related to a coefficient vectorÿ with coefficients ëì . Based on this observation, NUMLAB software module Functionimplements a vector functioní as a block vector of real-valued coefficientsÿ ëì , combined with a reference to the relatedSpace– which contains related functionsê ëì .
TheFunctionmodule provides services to evaluate the function and its derivatives at a given point ñ ð ò . To this end, bothí ’s coefficient vector and the point ñ are passed to theSpace module referred to byí . At its turn, theSpacemodule returns the value ofí ø ñ ù . This is computed following the definitioní ø ñ ù
ì
ëì ê ëì ø ñ ù , as described in the previous section. The computation of the partial derivatives of a given functioní in a pointñ follows a similar implementation.
Providing evaluation of functions and of their derivatives at given points is, strictly speak- ing, the minimal interface theSpacemodule has to implement. However, it is sometimes convenient to be able to evaluate a function at a point given as an element number and local coordinates within that element. This is especially important for efficiency in the case where one operation is iterated over all elements of aGrid, such as in the case of numerical integration. If theSpacemodule allows evaluat- ing functions at points specified as elements and local element coordinates, the implementation of the numerical integration is considerably faster than when point-to-element location has to be performed. Consequently, we also provided theSpacemodule with a function evaluation interface which accepts an element number and a point defined in the element local coordinates.
6.5.4
TheOperatormodule
As described previously, an operator maps an element to an element . The evaluation computes the coefficients of from the coefficients of , as well as from the bases and of and respectively. Next to the evaluation of , derivatives such as the Jacobian operator of are evaluated in a similar manner. Such derivatives are important in several applications. For example, they can be used in order to find a solution of , with Newton’s method.
The software implementation of the operator notion follows straightforwardly the mathematical concepts introduced in Section 6.4. The implementation is done by theOperatormodule, which offers two services: evaluation of , coded asG.eval(z,x), and of the Jacobian of in point , , coded asG.getJ(y).eval(z,x). To evaluate , theOperator module takes twoFunctionobjects and as input and computes the coefficients using the coefficients and the bases of theSpaceobjects and carry with them. It is important that both the ’input’ and the ’output’ of theOperatormodule are provided, since it is in this way that Operators determine the spaces , respectively .
To evaluate , theOperatorproceeds similarly. Internally, is usually im- plemented as a coefficient matrix, and the operation is a matrix-vector multiplication. How- ever, the implementation details are hidden from the user ( may be computed element-wise, i.e. matrix-free), who works only with theFunctionandOperatormathematical notions.
SpecificOperatorimplementations differ in the way they compute the above two evaluations. For example, a simpleDiffusionoperator may operate on a scalar function and produce a function where ! . A genericLinearoperator may produce a vector of coefficients " where" is a matrix. ASummatoroperator # may take two inputs and # and produce a vector of coefficients $ % $ # %. Remark that the modules implementing theLinearandSummatoroperators actually have two inputs each. In both cases the function is the first input, while the second is the matrix" for theLinearoperator and the operators and # for theSummatoroperator. These values could be as well hard-coded in the operator implementation. In both cases however, we seeOperatoras a function of a single variable , as described in the mathematical framework.
6.5.5
TheSolvermodule
We model the solving of by the moduleSolverin our software framework. Mathemati- cally speaking,Solveris similar to an operator& , where and are function spaces. The interface ofSolverprovides evaluation at functions , similarly to theOperatormod- ule. The implementation of theSolverevaluation operation & should provide an approxi-
mation' to' ( ) * + , - . However,Solverdoes not provide evaluation of its Jacobian, as this may be undesirably complex to compute in the general case.
Practically,Solvertakes as input an initial guessFunctionobject, and anOperatorob- ject. . Its output' is such that. + ' - / , . The operations done by the solver are either vector space operations orOperatorevaluations, or evaluations of similar operators. + ' -. In the actual imple- mentation, this is modelled by providing theSolvermodule with one or more extra inputs of type Solver. In this way, one can for example connect a nested chain of preconditioners to an iterative solver module.
The implementation of a specificSolverfollows straightforwardly from its mathematical de- scription. Iterative solvers such as Richardson, GMRES, (bi)conjugate gradient, with or without pre- conditioners, are easily implemented in this software framework.
The framework makes no distinction between a solver and a preconditioner, as discussed in Sec- tion 6.4. The sole difference between a solver and a preconditioner in this framework is semantic, not structural. A solver is supposed to produce an exact solution of. + ' - / 0 (up to a desired numeri- cal accuracy), whereas the preconditioner is supposed to return an approximate one. Both are imple- mented asSolvermodules, which allows easy cascading of a chain of preconditioners to an iterative solver as well as using preconditioners and solvers interchangeably in applications. Furthermore, the framework makes no structural distinction between direct and iterative solvers. For example, anILU- Solvermodule is implemented to compute an incomplete LU factorisation of its input operator. . TheILUSolvermodule can be used as a preconditioner for aConjugateGradientsolver mod- ule. In the case theILUSolveris not connected to theConjugateGradientmodule’s input, the latter performs non preconditioned computations. Alternatively, aLUSolvermodule is imple- mented to provide a complete LU factorisation of its input operator . . TheLUSolvercan be used either directly to solve the equation. + ' - / , , or as preconditioner for anotherSolvermodule.