Source-linked AI summary
Automating the Finite Element Method
Anders Logg
TL;DR
The finite element method provides a general framework for discretizing differential equations, but automating it requires parameterization over variational problems and finite elements. This paper reviews algorithms and implementations for that automation, reporting that generated and compiled low-level code can retain generality while competing with specialized codes.
Problem
Finite element implementations often handle only narrow sets of variational problems and elements, while automating the method requires difficult parameterization over both.
Source: §1 · p. 1Method
The paper reviews algorithms and implementations that automatically generate and compile low-level code for a given equation and finite element.
Source: §1 · p. 1Results
Generated and compiled low-level code can realize finite element generality and flexibility while competing with or outperforming specialized, hand-optimized codes.
Source: §1 · p. 1Takeaways & Limitations
The approach makes it possible to develop finite element systems parameterized over equations and elements while targeting the efficiency of specialized codes.
Source: §1 · p. 1Reported element-tensor speedups may overstate whole-simulation gains because assembly, linear solves, and nonlinear iterations also take time.
Source: §9.2.3 · p. 50
Abstract
from arXiv · showhide
The finite element method can be viewed as a machine that automates the discretization of differential equations, taking as input a variational problem, a finite element and a mesh, and producing as output a system of discrete equations. However, the generality of the framework provided by the finite element method is seldom reflected in implementations (realizations), which are often specialized and can handle only a small set of variational problems and finite elements (but are typically parametrized over the choice of mesh). This paper reviews ongoing research in the direction of a complete automation of the finite element method. In particular, this work discusses algorithms for the efficient and automatic computation of a system of discrete equations from a given variational problem, finite element and mesh. It is demonstrated that by automatically generating and compiling efficient low-level code, it is possible to parametrize a finite element code over variational problem and finite element in addition to the mesh.
1 INTRODUCTION
The finite element method offers a general, flexible framework for solving differential equations, but automating it requires code parametrized over both variational problems and finite elements. The paper introduces the automation target and reviews algorithms, implementations, educational uses, and the organization of the work.
1 INTRODUCTION
- The method’s generality and flexible choice of finite elements support a common framework for solving differential equations, while that breadth makes automation difficult.The required parameterization over variational problems and finite elements leaves substantial work to be done by hand.Source: §1 · p. 1
1.1 Automating the Finite Element Method
- The automation target is a machine that turns a discrete variational problem and finite element spaces on a mesh into discrete equations, including the system’s linearization.The paper identifies algorithms and prototype implementations for the key steps.Source: §1.1 · p. 2
1.2 The FEniCS Project and the Automation of CMM
- FEniCS’s FIAT generates basis functions for many finite elements, while FFC generates low-level code to assemble discrete systems from variational problems and finite elements.The project also includes DOLFIN interfaces and components for assembly, finite-element families, and parallel linear algebra.Source: §1.2 · p. 3
1.3 Automation and Mathematics Education
- Puffin, an educational implementation of FEniCS functionality, has been used in courses where first-year undergraduates designed solvers for coupled convection–diffusion–reaction equations.The authors describe this use as supporting students’ understanding of mathematical modeling, differential equations, finite elements, and programming.Source: §1.3 · p. 4
1.4 Outline
- The paper proceeds from a software survey and finite-element introduction through automation algorithms, optimized computation, software engineering, prototypes, examples, and an agenda for further work.It closes with a summary of findings.Source: §1.4 · p. 4
2 SURVEY OF CURRENT FINITE ELEMENT SOFTWARE
The survey groups finite-element systems by automation level and design, and illustrates their variational-problem specifications with Poisson’s equation. Because systems differ in language, philosophy, and capabilities, the examples are not fully uniform.
2 SURVEY OF CURRENT FINITE ELEMENT SOFTWARE
- The survey classifies systems by automation level and design, while noting that their Poisson examples do not all specify exactly the same problem.The survey is limited to selected projects that attracted the author’s attention, excluding most proprietary systems.Source: §2 · pp. 4–5
2.1 Analysa
- Analysa [6, 7] supports direct bilinear-form actions, which may be more efficient than assembling and applying a matrix when only a few actions are needed before reassembly.Analysa defers coupling forms to test and trial spaces until computation of the discrete system.Source: §2.1 · pp. 5–6
2.2 deal.II
- deal.II [12, 13, 11] supplies finite-element tools but leaves users to code quadrature-based element stiffness matrices and their insertion into the global system.This reflects a common library design that provides basic tools without automating assembly.Source: §2.2 · pp. 6–7
2.3 Diffpack
- Diffpack [24, 92] requires users to compute element stiffness matrices but handles quadrature-point loops and insertion into the global matrix.Source: §2.3 · p. 7
2.4 FEniCS
- FEniCS [60, 36] uses FFC [98, 87, 88, 99] to generate low-level code, with the variational problem and finite-element spaces fixed at compile time.Its form language requires the form’s arity to be known when specified.Source: §2.4 · p. 8
2.5 FreeFEM
- FreeFEM [108, 59] offers a C++-based variational-problem language, an integrated development environment, and solution visualization; FreeFEM++ supports only 2D problems in the described version.FreeFEM3D is the separate 3D flavor, while 3D support for FreeFEM++ is described as planned.Source: §2.5 · p. 9
2.6 GetDP
- GetDP [35, 34] parses a declarative problem specification at startup, with variational problems expressed using previously defined function spaces that may include constraints and subspaces.Source: §2.6 · p. 9
2.7 Sundance
- Sundance [103, 101, 102] is a C++ library with automatic discrete-equation generation and symbolic differentiation of variational problems.It emphasizes large-scale PDE-constrained optimization.Source: §2.7 · p. 10
3 THE FINITE ELEMENT METHOD
The section reviews the finite element method’s piecewise-space construction and the algorithmic structure needed to describe it. It explains how local finite elements and mappings define global spaces, including the scope of reference-element mappings.
3.1 Galerkin’s Method
- Galerkin methods with piecewise polynomial spaces form the finite element method, including Petrov-Galerkin and Galerkin/least-squares variants.The method builds on the broader family of weighted residual methods.Source: §3.1 · p. 11
3.2 Finite Element Function Spaces
- A discrete function space is built by piecing local function spaces together across the cells of a mesh.Each local space is defined by a finite element.Source: §3.2 · p. 11
3.2.1 The finite element
- A finite element is a triple comprising a cell K, a finite-dimensional function space PK, and a basis NK for its dual space.The cell is bounded, closed, has nonempty interior, and has piecewise smooth boundary.Source: §3.2.1 · p. 11
3.2.2 The local-to-global mapping
- For each cell, the local-to-global mapping assigns local nodes to global nodes.The mapping determines which global node corresponds to each local node.Source: §3.2.2 · p. 12
3.2.3 The global function space
- Global functions must agree at local nodes mapped to the same global node.Functions may be undefined on cell boundaries unless the constraints enforce continuity there; operations can still be performed on cell restrictions.Source: §3.2.3 · p. 12
3.2.4 Lagrange finite elements
- Lagrange elements place nodes at vertices and edge midpoints to form continuous piecewise polynomials of degrees one and two, respectively.The family uses scalar polynomials of degree at most q on simplices.Source: §3.2.4 · p. 12
3.2.5 The reference finite element
- A reference finite element and cell mappings can generate cellwise spaces, nodes, and basis functions from one shared reference-cell description.The mappings are typically affine or isoparametric, and may differ between cells.Source: §3.2.5 · p. 13
- The simple reference-element construction excludes Hermite, H(div), and H(curl) families; the discussion limits scope to affine or isoparametric elements with point-evaluation nodes.H(div) and H(curl) elements require special mappings of basis functions from the reference element.Source: §3.2.5 · p. 14
3.3 The Variational Problem
The variational problem is posed on discrete test and trial spaces using semilinear and linear forms. Its discretization yields a nonlinear residual system, which reduces to a linear system for linear problems.
3.3 The Variational Problem
- The discrete problem seeks a trial-space function whose semilinear form against every test function equals the linear functional.The forms are typically integrals over the domain or portions of its boundary.Source: §3.3 · pp. 14–15
3.3.1 Nonlinear variational problems
- For nonlinear problems, the discrete equations form a residual system, and a differentiable semilinear form supplies its Jacobian for Newton’s method.The residual entries are Fi(U) = a(U; ˆφi) − L(ˆφi).Source: §3.3.1 · pp. 15–16
3.3.2 Linear variational problems
- For a linear variational problem, the discrete nonlinear system reduces to a linear system with entries Aij = a(ˆφi, φj).These entries also equal a′(U; ˆφi, φj).Source: §3.3.2 · p. 16
3.4 Multilinear Forms
The section treats discrete equations as tensors obtained by evaluating multilinear forms on basis functions and assembling cell contributions. It describes both general tensor structure and the separate tasks of computing local tensors and inserting them globally.
3.4 Multilinear Forms
- Discrete equations for linear and nonlinear problems reduce to evaluating multilinear forms on basis functions.The treatment considers forms of general arity r > 0 over products of discrete function spaces.Source: §3.4 · p. 17
- A form of arity r defines a rank-r tensor, typically sparse, with dimensions determined by the degrees of freedom in its argument spaces.The spaces need not be identical, as in mixed methods; the discussion restricts forms to domain or boundary integrals.Source: §3.4 · p. 17
- Bilinear forms yield stiffness matrices, while linear forms yield load vectors; higher-arity forms can represent weighted Poisson problems.For weighted Poisson, the form can define a rank-three tensor, matrix, or vector depending on which functions are fixed.Source: §3.4 · pp. 17–18
3.5 Assembling the Discrete System
- Assembly computes the global tensor by iterating over mesh cells and adding each cell’s local contribution.For integral forms, the global form is expressed as a sum of element forms.Source: §3.5 · p. 18
- The cellwise assembly loop uses local-to-global mappings to add contributions without explicitly forming the cell-support sets.This avoids constructing the sets of cells on which each basis-function combination is supported.Source: §3.5 · pp. 18–19
- Computing a dense element tensor first can let optimized library routines handle local computation and global insertion as separate operations.The insertion operation adds element-tensor entries to the global tensor using the local-to-global mapping.Source: §3.5 · p. 19
- Sparse-library insertion can improve performance, but adding element tensors may remain costly; local tensor code can be generated and optimized for each multilinear form.A separate implementation is otherwise needed for each form, and is often left to the user.Source: §3.5 · p. 19
3.6 Summary
The automation problem reduces to computing basis values, element tensors, and global assembly for discrete spaces generated from reference elements. The section identifies these as the key steps toward automating the finite element method.
3.6 Summary
- Given element tensors and local-to-global mappings, the global tensor can be computed by the assembly algorithm.The remaining automation tasks include efficiently tabulating reference-element basis functions and evaluating each element tensor.Source: §3.6 · p. 20
4 AUTOMATING THE TABULATION OF BASIS FUNCTIONS
The section replaces explicit nodal-basis formulas with an algebraic construction from a computable prime basis. It extends this construction to polynomial spaces and spaces defined by constraints.
4 AUTOMATING THE TABULATION OF BASIS FUNCTIONS
- Explicit nodal basis functions may be difficult to derive and error-prone to transcribe, motivating their computation through a non-nodal basis.The approach can simplify or enable implementation of complicated finite elements.Source: §4 · p. 21
4.1 Tabulating Polynomial Spaces
- For polynomial spaces, evaluate an orthogonal prime basis at the nodes, then solve a linear system for the coefficients of the nodal basis.For typical reference triangles and tetrahedra, the prime basis and its derivatives have simple recurrence relations.Source: §4.1 · p. 22
4.2 Tabulating Spaces with Constraints
- For constrained spaces, define the space by linear functionals vanishing on a polynomial space, then find a prime basis from the constraint matrix’s nullspace.After finding that basis, compute the nodal basis as before; one example constrains boundary traces to lower-degree polynomials.Source: §4.2 · pp. 22–23
5 AUTOMATING THE COMPUTATION OF THE ELEMENT TENSOR
This section addresses the computation of element tensors by comparing quadrature and tensor-contraction methods and developing an algebra for expressing multilinear forms. It describes canonical tensor representations, their implementation with overloaded operators, and their connection to notation close to the original forms.
5.1 Evaluation by Quadrature
- Quadrature evaluates the element tensor by combining basis-function gradients with quadrature weights and mapping determinants, and suitable quadrature can be exact for polynomial basis functions.The reference-cell basis values may be precomputed, while the stated operation count can be significantly reduced by later methods.Source: §5.1 · p. 24
5.2 Evaluation by Tensor Representation
- For affine mappings, element tensors can be formed by contracting a precomputed, cell-independent reference tensor with a geometry tensor, yielding a Poisson speedup of roughly Nq/d.The representation theorem covers forms in the stated canonical form, and its constructive proof gives an algorithm for computing the representation.Source: §5.2 · pp. 25, 27
5.3 Extension to Non-Affine Mappings
- For non-affine mappings, a tensor-contraction representation remains possible, but its tensor ranks increase and its contraction work grows by a factor Nq.The contraction costs a factor d more than direct quadrature in the stated comparison, though it is more readily optimized.Source: §5.3 · p. 30
5.4 A Language for Multilinear Forms
- A language for multilinear forms can translate each expression into canonical form, from which the element tensor is computed by tensor contraction.The design aims to stay close to mathematical notation while making translation to canonical form straightforward.Source: §5.4 · p. 30
5.4.1 An algebra for multilinear forms
- The algebra for multilinear forms is generated from basis functions using arithmetic, scalar operations, and differentiation, and can express compound linear-algebra and differential operators.For vector- or tensor-valued basis functions, it is generated from their scalar components.Source: §5.4.1 · p. 31
- The algebra represents element tensors in canonical form for multilinear forms expressible as integrals over an element.The passage identifies this representation with canonical form (74).Source: §5.4.1 · p. 31
5.4.2 Examples
- With suitable local basis functions, the canonical element-tensor form can be written in notation close to the multilinear form itself.The section illustrates this with two bilinear-form examples.Source: §5.4.2 · pp. 31–32
5.4.3 Implementation by operator-overloading
- Operator overloading can implement the algebra using basis functions, products, and sums, while indices associate products with tensors in canonical form.Compound operators such as grad, div, rot, and dot can be expressed in terms of basic operators.Source: §5.4.3 · p. 32
6 AUTOMATING THE ASSEMBLY OF THE DISCRETE SYSTEM
Assembly adds each cell’s element tensor into the global tensor using local-to-global mappings. The mappings can be implemented directly for a finite element or generated from a description of its nodes and mesh entities.
6 AUTOMATING THE ASSEMBLY OF THE DISCRETE SYSTEM
- Assembly computes each cell’s element tensor, then adds its entries to the global tensor according to the local-to-global mappings.The mappings provide tuples that distribute each element-tensor dimension onto the global tensor.Source: §6 · p. 33, §6.1 · p. 33
6.1 Implementing the Local-to-Global Mapping
- Implementing mappings separately for each function space can be efficient, while a general-purpose mapping for a range of spaces quickly becomes inefficient.For continuous linear and quadratic Lagrange elements on tetrahedra, the individual implementations require little arithmetic or branching.Source: §6.1 · p. 33, Table 14 · p. 33, Table 15 · p. 34
6.2 Generating the Local-to-Global Mapping
- A node description organized by topological dimension and geometric entity can generate local-to-global mappings; higher-degree shared nodes require consistent entity orientations.For fifth-degree tetrahedral Lagrange elements, edges have two possible orientations and faces have six.Source: §6.2 · pp. 34–35
7 OPTIMIZATIONS
The section reduces element-tensor computation by exploiting tensor structure and dependencies, then arranging those dependencies into efficient computations. The quadratic-triangle Poisson example illustrates how symmetry and a minimum spanning tree can reduce the operation count.
7.1 Tensor Contractions as Matrix–Vector Products
- Flattening tensor contractions enables matrix–vector computation, while batching cells can use matrix–matrix products for typically improved floating-point performance, subject to memory limits.The optimal batch size depends on the problem and architecture, and large geometry tensors may limit it.Source: §7.1 · pp. 37–38
7.2 Finding an Optimized Computation
- Compile-time knowledge of reference-tensor structure allows generated code to exploit dependencies among its vectors and reduce the operation count.The section notes that matrix–vector routines alone may not fully exploit this structure.Source: §7.2 · pp. 38–39
7.2.1 Collinearity
- When two reference-tensor vectors are collinear, their entries can be computed through a shared multiplication rather than separate full inner products.A previously computed entry can be reused to obtain the other.Source: §7.2.1 · p. 39
7.2.2 Closeness in Hamming distance
- Vectors at Hamming distance ρ can be related so that one entry is computed from the other in at most ρ multiply–add pairs.Hamming distance counts the number of differing entries; the direct inner-product cost is the vector length.Source: §7.2.2 · p. 39
7.2.3 Complexity-reducing relations
- The method calls pairwise dependencies that reduce the cost of computing one entry from another complexity-reducing relations, selecting the least-cost relation when several apply.The considered relations include collinearity and closeness in Hamming distance.Source: §7.2.3 · p. 39
7.2.4 Finding a minimum spanning tree
- A weighted graph of reference-tensor vectors uses relation costs as edge weights; its minimum spanning tree gives an optimized, though not necessarily optimal, computation order.Compute the root entry first, then derive remaining entries by traversing the tree.Source: §7.2.4 · p. 40
7.2.6 Extensions
- The reductions use symmetry to avoid computing 15 of 36 tensor entries, and the section notes that ternary or higher-arity relations could reduce operation counts further.The example's optimized computation is shown as a minimum spanning tree in Figure 6.Source: §7.2.5 · p. 41, Figure 6 · p. 43, §7.2.6 · p. 44
7.2.5 A concrete example
- For quadratic-triangle Poisson, tree reuse cuts the 144-pair baseline to at most 17 pairs; symmetry alone computes 21 entries at 3 pairs each (63 total).The tree cost includes at most 14 pairs after computing a root entry in 3 pairs.Source: §7.2.5 · pp. 40–42
8 AUTOMATION AND SOFTWARE ENGINEERING
The section argues that automating finite element computation also requires automating parts of its software realization. It presents code generation as a way to specialize computations and notes the overhead challenge of just-in-time compilation.
8 AUTOMATION AND SOFTWARE ENGINEERING
- Implementing all mathematical concepts directly may be difficult, motivating automatic generation of code for the specific concepts in a given problem.The software design discussion also highlights abstractions such as Mesh, Function, BilinearForm, and FiniteElement.Source: §8 · p. 44
8.1 Code Generation
- A compiler can specialize simulation code for a given variational problem and finite-element choice while generating optimized low-level code.Administrative tasks and special algorithms such as adaptive mesh refinement can remain in a general-purpose library.Source: §8.1 · p. 45
8.2 Just-In-Time Compilation
- Just-in-time compilation should generate and compile code transparently for a problem specification, but its precompilation overhead must remain acceptable.Computing reference tensors can be costly, especially for high-order elements and complicated forms; caching by signature is proposed to reduce that cost.Source: §8.2 · p. 45
9 A PROTOTYPE IMPLEMENTATION (FEniCS)
FEniCS implements automated finite element discretization through FIAT, FFC, and DOLFIN, which handle basis tabulation, form evaluation, and assembly. Its benchmarks show substantial local element-tensor speedups, while the paper notes that total simulation gains depend on how much runtime tensor computation consumes.
9.1 FIAT
- FIAT tabulates basis functions and derivatives, generates quadrature points, and supports constrained polynomial spaces and several predefined element families.Supported families include arbitrary-degree Lagrange and Hermite, Raviart–Thomas, Brezzi–Douglas–Marini, Nedelec, and first-degree Crouzeix–Raviart elements.Source: §9.1 · p. 46
9.2 FFC
- FFC compiles multilinear forms over discrete function spaces into optimized low-level code for evaluating element tensors.Its current optimization skips multiplications by zero reference-tensor entries; an optimizing backend, FErari, was under development.Source: §9.2 · pp. 46, 48, Figure 10 · p. 48, §9.2.2 · p. 50
9.2.1 Form language; 9.2.4 User interfaces
- The FFC form language expresses multilinear forms using standard differential operators, tensor notation, and user-defined operators, and FFC can run as a command-line or Python compiler.Generated output can target C++, ASE, XML, or LaTeX formats.Source: §9.2.1 · p. 48, §9.2.4 · p. 52
9.2.3 Benchmark results
- For test cases 1–4, FFC-generated code using a precomputed reference tensor and tensor contraction achieves speedups of one to three orders of magnitude over quadrature-point-loop implementations, with larger speedups for higher-degree elements.Source: Table 26 · p. 50, §9.2.3 · p. 50
9.2.3 Benchmark results; 9.3.4 ODE solvers
- The reported speedups concern local tensor computation, so total simulation speedup may be smaller; DOLFIN also lacked automatic discretization of time-dependent PDEs.The runtime benefit is significant only when local tensor computation accounts for a significant fraction of total runtime, as can occur with repeated reassembly in nonlinear problems.Source: §9.2.3 · p. 50, §9.3.4 · p. 53
9.3.1 Automatic assembly of the discrete system
- DOLFIN assembles global systems by iterating over mesh cells and calling FFC-generated element-tensor and local-to-global mapping code.Because FFC generates both, DOLFIN can operate with little knowledge of the finite element method.Source: §9.3.1 · p. 53
10 EXAMPLES
The examples demonstrate FEniCS implementations of elasticity, two Stokes formulations, and time-dependent convection–diffusion. They illustrate how finite-element choices and stabilization affect computed solutions.
10.1 Static Linear Elasticity
- A linear-elasticity problem with a gear domain, clamped at two ends and twisted by 30 degrees, produces the displacement shown in Figure 14.The boundary conditions specify the twist.Source: §10.1 · p. 55, Figure 14 · p. 56
10.2 The Stokes Equations
- For Stokes flow, the discrete spaces must satisfy the Babuška–Brezzi inf–sup condition to guarantee a unique solution.The examples use Taylor–Hood elements or a stabilized equal-order formulation.Source: §10.2 · p. 57
10.2.1 Taylor–Hood elements
- Taylor–Hood elements meet the stated space-selection approach by using degree q velocity and degree q −1 pressure approximations; Figure 16 shows the P2–P1 velocity field around a dolphin.The mixed element is specified as the direct sum of vector-valued and scalar Lagrange elements.Source: §10.2.1 · p. 57, Table 28 · p. 57, Figure 16 · p. 60
10.2.2 A stabilized equal-order formulation
- Without stabilization, the equal-order P1–P1 pressure solution oscillates heavily, while the stabilized formulation avoids the inf–sup condition through a modification of the variational problem.The unstabilized image scales oscillations down by a factor of two, so the displayed difference understates them.Source: §10.2.2 · pp. 57–58, Table 29 · p. 58
10.3 Convection–Diffusion
- The convection–diffusion example computes temperature around the dolphin using a velocity field obtained from the Stokes solution and cG(1)cG(1) discretization in space and time.Stabilization is omitted for simplicity, and the right-hand side is approximated by its value at the right endpoint.Source: §10.3 · pp. 58, 61, Figure 17 · p. 60
11 OUTLOOK: THE AUTOMATION OF CMM
The outlook frames finite element discretization as one stage in automating computational mathematical modeling, alongside solution, error control, modeling, and optimization. It describes feedback-based approaches and identifies automatic generation of dual problems as a step toward automated error control and optimization.
11.3 An Agenda for the Automation of CMM
- The proposed automation agenda comprises discretization, discrete solution, error control, modeling, and optimization, with feedback or adaptivity playing a key role.The overall task is to obtain a solution meeting an accuracy requirement with minimal work.Source: §11.3 · pp. 63–64
11.4 The Automation of Discretization
- Automation of discretization translates a continuous model or variational problem into discrete equations, with the finite element method supplying a way to automate this step.The discrete function spaces may also be chosen automatically through feedback control.Source: §11.4 · p. 64
11.5 The Automation of Discrete Solution
- Discrete-system resolution can be selected by feedback to minimize work while meeting an accuracy target, but designing efficient adaptive iterative algorithms remains an open problem.The feedback from computed solutions to iterative solvers is often weak.Source: §11.5 · p. 65
11.6 The Automation of Error Control; 11.6.2 The weak dual problem
- Error control aims to meet a tolerance for an output quantity at minimal computational cost, using adaptive choices informed by residuals and dual solutions.The paper identifies automatic generation and solution of the dual problem from the primal problem as a step needed to automate this process.Source: §11.6 · p. 65, §11.6.1 · p. 66, §11.6.2 · p. 66
11.7 The Automation of Modeling
- Model reduction seeks an average solution on resolvable scales when variation across unlocalized scales makes computation expensive, and constructs a large-scale model from the given model.The text notes that no clear answer has been given for subgrid models of the averaged Navier–Stokes equations.Source: §11.7 · pp. 66–67
11.8 The Automation of Optimization
- Optimization under a model constraint can be formulated through a Lagrangian, yielding primal, dual, and control-stationarity equations.The paper says automating optimization relies on automated solution of the primal and dual problems, including automatic dual-problem generation.Source: §11.8 · p. 67
12 CONCLUDING REMARKS
FEniCS provides an early, partial automation of the finite element method through components implementing algorithms discussed in the paper. As this discretization toolset matures, the authors identify automatic error control as a next research direction.
12 CONCLUDING REMARKS
- FEniCS is presented as an early, partial working system for automating the finite element method and a first step toward automating computational mathematical modeling.The project includes FIAT, FFC, and DOLFIN, which provide reference implementations of algorithms discussed in Sections 3–6.Source: §12 · p. 68
- The authors identify automatic generation of dual problems and error estimates as a planned route toward automating error control.This is among the new research directions emerging as the current discretization-focused toolset matures.Source: §12 · p. 68
- The current toolset focuses mainly on automating discretization, while further research is needed for the remaining steps toward automated computational mathematical modeling.The authors describe the toolset as becoming more mature.Source: §12 · p. 68
NOTATION
The notation defines the model and its global, reference, and element tensors, then specifies the spaces, nodes, indices, mappings, and solution quantities used throughout the paper.
NOTATION
- A denotes the model's differential operator, while A and A0 denote global and reference tensors, respectively; AK is the element tensor.The notation also names flattened matrix or vector representations of the reference and element tensors.Source: NOTATION · p. 75
- The notation distinguishes the mesh cell K from reference cell K0 and defines FK as the mapping from K0 to K.It also defines local-to-global mappings from local node sets to global node sets.Source: NOTATION · p. 75
- The notation specifies dimensions and local or global node sets for the discrete and element function spaces.It also defines Pq(K) as polynomials of degree at most q on K.Source: NOTATION · pp. 75–76
- V and ˆV are the trial and test spaces, with Vh and ˆVh their discrete counterparts; U and u denote the approximate and exact solutions.The notation also identifies e as the error U − u and ϕ as the dual solution.Source: NOTATION · p. 76