the fenics project version 1publications.lib.chalmers.se/records/fulltext/228672/... ·...

Archive of Numerical Softwarevol. 3, no. 100, pages 9–23

c© 2015

The FEniCS Project Version 1.5

Martin S. Alnæs1, Jan Blechta2, Johan Hake3, August Johansson4,Benjamin Kehlet5, Anders Logg6, Chris Richardson7, Johannes Ring8, Marie

E. Rognes9, and Garth N. Wells10

1Simula Research Laboratory, [email protected] University in Prague, [email protected]

3Simula Research Laboratory, [email protected] Research Laboratory, [email protected]

5Simula Research Laboratory, [email protected] University of Technology and University of Gothenburg, [email protected]

7University of Cambridge, [email protected] Research Laboratory, [email protected]

9Simula Research Laboratory, [email protected] of Cambridge, [email protected]

Received: May 28th, 2015; final revision: December 1st, 2015; published: December 7th, 2015.

Abstract: The FEniCS Project is a collaborative project for the development of innovativeconcepts and tools for automated scientific computing, with a particular focus on the solution ofdifferential equations by finite element methods. The FEniCS Project consists of a collection ofinteroperable software components, including DOLFIN, FFC, FIAT, Instant, mshr, and UFL. Thisnote describes the new features and changes introduced in the release of FEniCS version 1.5.

1 Overview

FEniCS version 1.5 was released on 12th January 2015. This article provides an overview of thenew features of this release and serves as a citable reference for FEniCS version 1.5. The FEniCSsoftware can be downloaded from the FEniCS Project web page at http://fenicsproject.org.

The FEniCS software consists of a collection of interoperable components. These are, in alpha-betical order, DOLFIN, FFC, FIAT, Instant, mshr, and UFL. In addition, FEniCS includes the codegeneration interface component UFC, which is now technically a part of FFC. All FEniCS compo-nents, except mshr, are licensed under the GNU LGPL. Due to upstream dependencies, mshr islicensed under the GNU GPL. The components are released simultaneously with the same majorand minor version numbers, making it straightforward for users to find compatible versions ofthe components. The version number of packages that may be unchanged are still incrementedto avoid divergence of version numbers.

http://fenicsproject.org

10

2 New features

2.1 Parallel computing

The performance of parallel computations with DOLFIN continues to be enhanced. Notableenhancements and new features in the 1.5 release include:

• switch to local (process-wise) degree-of-freedom indexing; for more details see subsec-tion 2.9;

• full support (including from Python) for problems with over 232 dofs via complete supportfor 64-bit indices;

• substantial improvements in performance scaling and memory use for degree-of-freedommap construction;

• new parallel mesh refinement strategy;

• support for overlapping mesh ‘ghost’ layers in parallel;

• interior facet integrals are now supported in parallel, which enables discontinuous Galerkinmethods in parallel;

• improvements in parallel IO using HDF5.

DOLFIN has been used to solve the Poisson equation with over 12 billion degrees of free-dom [Richardson and Wells, 2015] on 24576 cores on a Cray XC30.

Improvements have been made to decrease the load on the filesystem during just-in-time com-pilation, which can be a bottleneck on large machines. Further effort is required to address thewell-known issue of importing Python modules on parallel computers.

A memory corruption issue during forks on OFED-based (InfiniBand) clusters has been trackeddown. Users of OFED machines are advised to read the Instant README file and export theINSTANT_SYSTEM_CALL_METHOD environment variable.

2.2 New mesh refinement strategy

A new refinement algorithm has been adopted for DOLFIN, following the work of Plaza andCarey [2000]. This algorithm uses edge bisection to subdivide the marked triangles of a Mesh,be they the cells themselves in two dimensions, or the facets of tetrahedra in three-dimensions.The subdivision is chosen so as to maximize the internal angles of the new triangulation, thusmaintaining mesh quality after multiple refinements; see Figure 1. Edges which are markedfor refinement propagate between processes in parallel, whilst the refinement operation is local,resulting in good scaling.

2.3 Mesh generation: the new mshr component

The mesh generation functionality of FEniCS, except for simple meshes like UnitSquareMesh andUnitCubeMesh, has been moved to a new FEniCS Component named mshr. The motivation for thischange is twofold: first, to simplify the list of dependencies and reduce the amount of resources(CPU time and memory usage) for building DOLFIN (by moving the CGAL dependency to mshr);and second, to simplify the addition of new features to the new meshing component. Currently,both CGAL and Tetgen are available as mesh generation backends for mshr.

Much like the old meshing interface in DOLFIN, the new mshr interface allows simple generationof meshes from Constructive Solid Geometry (CSG) descriptions, as demonstrated by the examplelisted below. The generated mesh is shown in Figure 2.

Archive of Numerical Software 3(100), 2015 c© by the authors, 2015

The FEniCS Project Version 1.5 11

Figure 1: Tetrahedron refined multiple times, whilst preserving mesh quality.

Figure 2: A mesh generated from a CSG description in FEniCS. The left image shows the surfaceof the generated tetrahedral mesh while the right image shows a volume rendering in which thesubtracted sphere in the center is visible.

Python code1 from dolfin import *2 from mshr import *34 # Define geometry5 box = Box(Point(0, 0, 0), Point(1, 1, 1))6 sphere = Sphere(Point(0, 0, 0), 0.3)7 cylinder = Cylinder(Point(0, 0, -1), Point(0, 0, 1), 1.0, 0.5)8 geometry = box + cylinder - sphere9

10 # Generate mesh11 mesh = generate_mesh(geometry , 16)

Through a combination of simple CSG primitives and Boolean operations (and, or, negation),meshes can be created for geometries ranging from simple domains like the canonical L-shapeddomain, to relatively complex geometries. Figure 3 shows a pair of meshes generated using mshr.

c© by the authors, 2015 Archive of Numerical Software 3(100), 2015

12

Figure 3: Meshes generated from CSG geometries using the new FEniCS mesh generation com-ponent mshr.

Figure 4: Multimesh solution of the Stokes problem on two overlapping non-matching meshes.

2.4 Multimesh finite element methods

Multimesh finite element methods (CutFEM) are finite element methods posed on two or morepossibly non-matching meshes. The formulation of multimesh finite element methods involvesthe formulation of variational problems on function spaces composed by regular function spaceson the intersecting meshes. Continuity between meshes is imposed using Nitsche’s methodand stability ensured by adding suitable stabilization terms (ghost penalties) to the variationalproblem.

FEniCS 1.5 adds support for the formulation of multimesh methods, including automatic andefficient computation of mesh-mesh intersections, quadrature rules for cut cells and interfaces, andexpression of integrals that typically appear in the formulation of multimesh/CutFEM methods.Figure 4 shows results for a Taylor–Hood formulation for the Stokes problem on two overlappingand intersecting meshes; a boundary-fitted mesh embedding a propeller-shaped hole, whichoverlaps a fixed background mesh; for details see Johansson et al. [2015].

The FEniCS interface to multimesh finite element methods currently requires a user to define theintegrals in terms of the newly added custom_integral interface. This new interface enablescode generation for integrals expressed on arbitrary domains, among them cut cells, interfaces,and overlaps, as illustrated by the following UFL code for expression of a multimesh formulationof Poisson’s equation:



Python code1 # Define custom measures (simplify syntax in future versions)2 dc0 = dc(0, metadata={"num_cells": 1})3 dc1 = dc(1, metadata={"num_cells": 2})4 dc2 = dc(2, metadata={"num_cells": 2})56 # Define measures for integration7 dx = dx + dc0 # domain integral8 di = dc1 # interface integral9 do = dc2 # overlap integral

1011 # Parameters12 alpha = 4.013 beta = 4.01415 # Bilinear form16 a = dot(grad(u), grad(v))*dx \17 - dot(avg(grad(u)), jump(v, n))*di \18 - dot(avg(grad(v)), jump(u, n))*di \19 + alpha/h*jump(u)*jump(v)*di \20 + dot(jump(grad(u)), jump(grad(v)))*do

On the C++ side, multimesh function spaces must currently be explicitly constructed as demon-strated by the following excerpt from the multimesh-poisson demo:

C++ code1 // Create function spaces2 MultiMeshPoisson::FunctionSpace V0(mesh_0);3 MultiMeshPoisson::FunctionSpace V1(mesh_1);4 MultiMeshPoisson::FunctionSpace V2(mesh_2);56 // Build multimesh function space7 MultiMeshFunctionSpace V;8 V.parameters("multimesh")["quadrature_order"] = 2;9 V.add(V0);

10 V.add(V1);11 V.add(V2);12 V.build();

Future improvements to the multimesh functionality of FEniCS will include the introduction ofspecific integration measures in UFL, so that the measures don’t need to be defined in termsof custom_measure, as well as simplified and higher level interfaces for assembly and problemsolving in DOLFIN.

2.5 Assembly of point integrals

In addition to the classical cell integrals, exterior facet integrals, and interior facet integrals, FEniCSversion 1.5 supports specification of point integrals. A point integral represents the integrandevaluated at each vertex, summed over the vertices of the mesh. Starting with FEniCS version1.5, the DOLFIN assemblers recognize point integrals and assemble contributions from suchintegrals. We remark that for each vertex, the integrand will be restricted to the arbitrarilychosen first cell associated with this vertex prior to evaluation. This operation is therefore onlyconsistently defined for functions and integrands that are continuous at the vertices.

2.6 Point integral solvers and Rush–Larsen schemes

The FEniCS PointIntegralSolvers are special-purpose solvers dedicated to solving multistageintegration schemes defined for each vertex of a mesh. Such problems typically occur in con-nection with spatially varying systems of ODEs, for instance in electrophysiology. In FEniCSversion 1.5, we have extended the range of available schemes to also include the Rush–Larsen


14

[Rush and Larsen, 1978] and the generalized Rush–Larsen [Sundnes et al., 2009] schemes forsolving systems of nonlinear ODEs.

2.7 Redesign of core symbolic representation and algorithms

The domain-specific language UFL represents equations as symbolic expression trees, whereeach node represents some value or mathematical operation. For nonlinear equations withlarge expression trees, the performance and memory overhead of symbolic computations andform compiler algorithms can become significant, especially when running in parallel, wherethis overhead is a limiting factor for scalability according to Amdahl’s law. This becomes evenmore important when FEniCS is combined with high-level algorithms, such as the dolfin-adjointpackage, that rely extensively on symbolic algorithms from UFL. To reduce this overhead, thecore representation of symbolic expressions has been redesigned (see ufl.core), followed by arewrite of the core framework for developing additional symbolic algorithms (see ufl.corealg).Each expression tree node type now has the following attributes:

• ufl_operands Tuple of child nodes in expression tree. Equivalent to deprecated operands().

• ufl_shape Tuple of value shape dimensions. Equivalent to deprecated shape().

• ufl_free_indices Tuple of free index integer ids. Replaces deprecated free_indices().

• ufl_free_index_dimensions Tuple of dimensions associated with corresponding free indexids in ufl_free_indices. Replaces deprecated free_indices().

The deprecated functions mentioned above are still available as wrappers around the new at-tributes. Type traits of symbolic expression classes have also been made available through anefficient property-based API using the naming scheme ExprType._ufl_*_ (see ufl.core.expr).This is mainly intended for internal usage but also for developers building on the symboliccapabilities of FEniCS.

A major guiding principle in the redesign of core algorithms in UFL was to replace all usesof expensive recursion in Python with loops. Algorithms for expression traversal (see moduleufl.corealg.traversal) have all been reimplemented without recursion, and further fine-tunedfor specific iteration scenarios. The former Transformer base class for visitor-like algorithmshas been deprecated in favor of an implementation that avoids recursion. The new functionmap_expr_dag(function, expression) applies the given function to transform each expressiontree node in a non-recursive post-order traversal. The function arguments include the node aswell as the previously transformed node operands. This algorithm is further optimized to reducethe number of function calls and avoid duplicated expression tree nodes by (optionally) cachingintermediate results in a hashmap with the original expression nodes as keys.

Previous implementations of the Transformer class can easily be rewritten as implementationsof MultiFunction, which implements the same dynamic type dispatch mechanism, and passedas the function argument to map_expr_dag. Key algorithms such as automatic differentiation(apply_derivatives) and propagation of restrictions (apply_restrictions) have been reimple-mented in this optimized algorithm framework, and may serve as models. In addition, formsignatures are now computed without first applying automatic differentiation, which reduces thesymbolic overhead significantly when the signature is found in the form compiler cache. Togetherthese improvements have reduced the symbolic overhead in FEniCS 1.5 by 20–60%. To give a fewexamples: the initial just-in-time (JIT) compilation of a Poisson equation form was reduced from5s to 4s including C++ compilation, while for a complicated cardiac hyperelasticity model the JITtime was reduced from 103s to 48s. For the latter model, subsequent program runs now avoid a2s delay in the signature computation used for disk cache lookup.



P−r Λk(∆n)

k = 0 k = 1 k = 2 k = 3n = 1 P DPn = 2 P RT[E,F] DPn = 3 P N1E N1F DP

PrΛk(∆n)

k = 0 k = 1 k = 2 k = 3n = 1 P DPn = 2 P BDM[E,F] DPn = 3 P N2E N2F DP

Q−r Λk(�n)

k = 0 k = 1 k = 2 k = 3n = 1 Q DQn = 2 Q RTC[E,F] DQn = 3 Q NCE NCF DQ

SrΛk(�n)

k = 0 k = 1 k = 2 k = 3n = 1 S DPCn = 2 S BDMC[E,F] DPCn = 3 S AAE AAF DPC

Table 1: New notation for finite elements adopted from the Periodic Table of the Finite Elements.

2.8 Notation from Periodic Table of the Finite Elements

FEniCS now supports the notation for finite elements as set out in the Periodic Table of the FiniteElements [Arnold and Logg, 2014] based on the finite element exterior calculus, see Arnold et al.[2006]. The notation introduces new aliases for the existing elements in FEniCS and introducesnew placeholder names for the not yet implemented elements on quadrilaterals and hexahedra.Earlier FEniCS notation (“Lagrange”, “CG”, etc.) is still supported but may be phased out infuture versions. Table 1 summarizes the notation. In this table, n is the topological dimensionof the finite element domain (1D, 2D, 3D), r is the polynomial degree and k is the form degree;k = 0 means scalars, k = 1 means 1-forms (oriented line segments), k = 2 means 2-forms (orientedsurfaces) and k = 3 means 3-forms (oriented volumes).

Figure 5 shows a miniature (but high resolution) version of the periodic table. The full versioncan be downloaded from http://femtable.org.

As an example, the following code shows how to instantiate a pair of cubic Nédélec face elementsof the first and second kinds on a tetrahedron:

Python code1 element_1 = FiniteElement("N1F", "tetrahedron", 3)2 element_2 = FiniteElement("N2F", "tetrahedron", 3)

2.9 Changes in degree-of-freedom map construction

A number of performance improvements have been made in the degree-of-freedom (DOF) mapconstruction, and changes to how to DOF maps are order have been made. Specifically:

• DOLFIN now uses local (process-wise) numbering of degrees of freedom, which has re-duced the memory use of degree-of-freedom maps. This change also permits some newdevelopments in interfacing to linear-algebra backends.

• The degree-of-freedom map construction code has been re-written, reducing the time forconstruction and substantially improving parallel scaling of construction.

• Node-wise block structure in DOF maps, e.g. a fixed number of DOFs at each node, is nowautomatically detected. This provides better data locality and faster graph-based DOF mapreordering.


16

k 01012012301234

k 01012012301234

k 01012012301234

k 01012012301234

r = 12236341212452030205

r = 12133146415101051

r = 1214418126116322481

r = 122483824184166472325

2336126103030101560906015

2326831020154154045245

23291242754368812162169616

233814620483910481441688415

344102010206060203514021014035

3431015620453610351051267015

343162496414410827

25676886443281

344122210328472208027233618035

45515301535105105357028042028070

454152410358470207022428016035

454254016

12530024064

625200024001280

256

4551732155013512035

13647260634070

5662142215616816856

126504756504126

5652135155614012035

12642054031570

565366025

216540450125

1296432054003000

625

5662344217420418656

216768

1014588126

6772856288425225284

210840

1260840210

6762848218421618956

210720945560126

676498436

343882756216

24018232

1058460481296

677305828

10529427384

32811881602

952210

788367236

120360360120

330132019801320

330

787366328

12031528084

33011551540

924210

7876411249

51213441176

343

4096143361881610976

2401

788387436

144408384120

480176424181464

330

2233

4455

6677

8821

3243

5465

7687

2132

4354

6576

8722

3344

5566

7788

363

6126

102010

153015

214221

285628

367236

331

683

10156

152410

213515

284821

366328

441

9124

16249

254016

366025

498436

6411249

483

8146

122210

173215

234421

305828

387436

412124

10303010

20606020

3510510535

5616816856

8425225284

120360360120

4641

1020154

20453610

35847020

5614012035

8421618956

12031528084

81261

2754368

6414410827

12530024064

216540450125

343882756216

51213441176

343

824184

20483910

32847220

5013512035

7420418656

10529427384

144408384120

52030205

1560906015

3514021014035

7028042028070

126504756504126

210840

1260840210

330132019801320

330

5101051

154045245

351051267015

7022428016035

12642054031570

210720945560126

33011551540

924210

16322481

812162169616

25676886443281

625200024001280

256

1296432054003000

625

24018232

1058460481296

4096143361881610976

2401

166472325

481441688415

8027233618035

13647260634070

216768

1014588126

32811881602

952210

480176424181464

330

Period

ic Table of th

e Finite E

lemen

tsk

=0

k=

0k

=0

k=

0

r=1

r=1

r=1

n=

1

n=

2

n=

3

r=2

r=2

r=2

r=3

r=3

r=3

k=

1k

=1

k=

1k

=1

k=

2k

=2

k=

2k

=2

k=

3k

=3

k=

3k

=3

The table presents the primary spaces of finite elem

ents for the discretization of the fundam

ental operators of vector calculus: the gradient, curl, and divergence. A finite elem

ent space is a space of piecew

ise polynomial functions on a dom

ain determined by: (1) a

mesh of the dom

ain into polyhedral cells called elements, (2) a finite

dimensional space of polynom

ial functions on each element called

the shape functions, and (3) a unisolvent set of functionals on the shape functions of each elem

ent called degrees of freedom (DOFs),

each DOF being associated to a (generalized) face of the element,

and specifying a quantity which takes a single value for all elem

ents sharing the face. The elem

ent diagrams depict the DOFs and their

association to faces.

The spaces and

depicted on the left half of the table are the tw

o primary fam

ilies of finite element spaces for m

eshes of sim

plices, and the spaces are the tw

o primary fam

ilies of finite element spaces for m

eshes of and

are the two prim

ary families of finite elem

ent spaces for meshes of

on the right side are for m

eshes of cubes or boxes. Each is defined in any dimension n

≥1

for each value of the polynomial degree r≥

1, and each value of 0

≤k≤

n. The parameter k refers to the operator: the spaces consist

of differential k-forms w

hich belong to the domain of the kth exterior

derivative. Thus for k=0, the spaces discretize the Sobolev space H

1, the dom

ain of the gradient operator; for k=1, they discretize H

(curl), the dom

ain of the curl; for k=n

–1 they discretize H

(div), the domain

of the divergence; and for k = n, they discretize L2.

The spaces and

, which coincide, are the earliest finite

elements, going back in the case r = 1 of linear elem

ents to Cou-rant, 1 and collectively referred to as the Lagrange elem

ents. The spaces

and , w

hich also coincide, are the disconti-nuous Galerkin elem

ents, consisting of piecewise polynom

ials with

no interelement continuity im

posed, first introduced by Reed and Hill. 2 The space

in 2 dimensions w

as introduced by Raviart and Thom

as 3 and generalized to the 3-dimensional spaces

and

by Nédélec, 4 w

hile is due to Brezzi, Douglas and

Marini 5 in 2 dim

ensions, its generalization to 3 dimensions again

due to Nédélec. 6 The unified treatm

ent and notation of the in 2 dim

ensions, its generalization to 3 dimensions again

and fam

ilies is due to Arnold, Falk and Winther as part of finite

element exterior calculus, 7 extending earlier w

ork of Hiptmair for the

family. 8 The space

is the span of the elementary form

s introduced by W

hitney. 9

R. Courant, Bulletin of the American M

athematical Society 49, 1943.

W. H. Reed and T. R. Hill, Los Alam

os report LA-UR-73-479, 1973.P. A. Raviart and J. M

. Thomas, Lecture N

otes in Mathem

atics 606, Springer, 1977.J. C. N

édélec, Num

erische Mathem

atik 35, 1980.F. Brezzi, J. Douglas Jr., and L. D. M

arini, Num

erische Mathem

atik 47, 1985.J. C. N

édélec, Num

erische Mathem

atik 50, 1986.D. N

. Arnold, R.S. Falk, and R. Winther, Acta N

umerica 15, 2006.

R. Hiptmair, M

athematics of Com

putation 68, 1999.H. W

hitney, Geometric Integration Theory, 1957.

D. N. Arnold, D. Boffi, and F. Bonizzoni, N

umerische M

athematik, 2014.

D. N. Arnold and G. Aw

anou, Mathem

atics of Computation, 2013.

A. Logg, K.-A

. Mardal, and G. N

. Wells (eds.), Autom

ated Solution of Differential Equations by the Finite Elem

ent Method, Springer, 2012.

R. C. Kirby, ACM Transactions on M

athematical Softw

are 30, 2004.A. Logg and G. N

. Wells, ACM

Transactions on Mathem

atical Software 37, 2010.

M. Alnæ

s, A. Logg, K. B. Ølgaard, M. E. Rognes, and G. N

. Wells, ACM

Transactions on M

athematical Softw

are 40, 2014.

1.2.3.4.5.6.7.8.9.10.11.12.

13.14.15.

The family

of cubical elements can be derived from

the 1-di-m

ensional Lagrange and discontinuous Galerkin elements by a tensor

product construction detailed by Arnold, Boffi and Bonizzoni, 10 but for the m

ost part were presented individually along w

ith the correspon-ding sim

plicial elements in the papers m

entioned. The second cubical fam

ily is due to Arnold and Aw

anou. 11

The finite elements in this table have been im

plemented as part of

the FEniCS Project. 12, 13, 14 Each may be referenced in the Unified Form

Language (UFL) 15 by giving its fam

ily, shape, and degree, with the

family as show

n on the table. For example, the space

by giving its family, shape, and degree, w

ith the m

ay be referred to in UFL as:

FiniteElement("N2E", tetrahedron, 3) Alternatively, the elem

ents may be accessed in a uniform

fashion as:FiniteElement("P-", shape, r, k)FiniteElement("P",

shape, r, k)FiniteElement("Q-", shape, r, k)FiniteElement("S",

shape, r, k)for

FiniteElement("S", shape, r, k)

, FiniteElement("S",

shape, r, k),

FiniteElement("S", shape, r, k)

, and FiniteElement("S",

shape, r, k), respectively.

("P", interval, 1)("P", interval, 1)

("DP", interval, 0)("DP", interval, 1)





22

12

33

23

44

34

P1

P1

dP

0d

P1

P2

P2

dP

1d

P2

P3

P3

dP

2d

P3

33

44

48

13

98

12

14

46

16

12

22

910

88

12

24

618

14

27

20

54

48

36

39

810

64

32

14

48

410

87

22

72

0

13

44

44

12

66

36

10

10

15

30

10

10

610

20

20

36

60

36

612

14

812

20

30

410

15

20

45

60

10

20

("P", triangle, 1)("P", triangle, 1)

("Q", quadrilateral, 1)("S", quadrilateral, 1)

("RTC[E,F]", quadrilateral, 1)("BDMC[E,F]", quadrilateral, 1)

("DQ", quadrilateral, 0)("DPC", quadrilateral, 1)







("Q", hexahedron, 1)("S", hexahedron, 1)

("NCE", hexahedron, 1)("AAE", hexahedron, 1)

("NCF", hexahedron, 1)("AAF", hexahedron, 1)

("DQ", hexahedron, 0)("DPC", hexahedron, 1)









("DP", triangle, 0)("DP", triangle, 1)

("P", tetrahedron, 1)





("P", tetrahedron, 2)("P", tetrahedron, 2)



("P", tetrahedron, 3)("P", tetrahedron, 3)

("RT[E,F]", triangle, 1)("BDM[E,F]", triangle, 1)

("N1E", tetrahedron, 1)("N2E", tetrahedron, 1)

("N1F", tetrahedron, 1)("N2F", tetrahedron, 1)

("DP", tetrahedron, 0)("DP", tetrahedron, 1)









P1

P1

Q1

S1

dQ

0d

Pc

1

Q2

S2

dQ

1d

Pc

2

Q3

S3

dQ

2d

Pc

3

Q1

S1

dQ

0d

Pc

1

Q2

S2

dQ

1d

Pc

2

Q3

S3

dQ

2d

Pc

3

dP

0d

P1

P1

P1

P1

P2

P2

dP

1d

P2

P2

P2

P3

P3

dP

2d

P3

P3

P3

N1

1N

21

N2

1N

11

N1

2N

12

N1

3N

13

dP

0d

P1

dP

1d

P2

dP

2d

P3

N1

eN

1f

N1

eN

1f

N1

eN

1f

("Q", interval, 1)("S", interval, 1)

("DQ", interval, 0)("DPC", interval, 1)





22

12

33

23

44

34

Q1

S1

dQ

0d

Pc

1

Q2

S2

dQ

1d

Pc

2

Q3

S3

dQ

2d

Pc

3

n = 1n = 1

n = 1n = 1

n = 2n = 2

n = 2n = 2

n = 3n = 3

n = 3n = 3

n = 4n = 4

n = 4n = 4

Weight functions

for DOFs

Symbol of elem

ent

Element w

ith degrees of freedom

(DOFs)

Leg

en

dFin

ite e

lem

en

tsR

efe

ren

ces

Dimension of elem

ent function space

Finite element exterior

calculus notation

Element specification

in FEniCS

24

Concept and scientific content: Douglas N. Arnold (University of M

innesota) and Anders Logg (Chalmers University of

Technology). Graphic design: Mattias Schläger. The production of this poster has been supported by Sim

ula Research Laboratory and is partially based on w

ork supported by the U.S. National Science Foundation under grant DM

S-1115291. Findings do not necessarily represent the view

s of Simula or of the N

SF. Produced in 2014 and licensed under a Creative Com

mons Attribution-ShareAlike 4.0 International license.

femtable.org

[e/f] RT

[e/f]R

T1

RT

[e/f]R

T2

RT

[e/f]R

T3

BD

M[e/f]

BD

Mc

[e/f]

BD

Mc

[e/f]

BD

Mc

[e/f]

BD

M1

BD

Mc

1

BD

Mc

2

BD

Mc

3

BD

M[e/f]

BD

M2

BD

M[e/f]

BD

M3

N2

eN

ce

AA

eA

Af

AA

eA

Af

AA

eA

Af

Nc

f

Nc

eN

cf

Nc

eN

cf

N2

f

N2

eN

2f

N2

2N

22

N2

eN

2f

N2

3

RT

c[e/f]

RT

c[e/f]

RT

c[e/f]

N2

3

RT

c1

RT

c2

RT

c3

Nc

1A

A1

AA

1

AA

2A

A2

AA

3A

A3

Nc

1

Nc

2N

c2

Nc

3N

c3

PTofFE_poster_fin.indd 12014-09-22 14:24

Figure 5: Periodic Table of the Finite Elements.



Figure 6: Comparison of sparsity patterns of the Taylor–Hood Stokes operator on the DOLFINgearmesh.

Figure 7: Comparison of sparsity patterns of the Taylor–Hood Stokes operator on a NACA 0018airfoilmesh.

Improvements in sparsity patterns that follow from improved DOF map ordering are shown inFigures 6 and 7. The sparsity patterns produced by DOLFIN 1.5.0 are better clustered aroundthe diagonal. When DOLFIN is configured with SCOTCH, the SCOTCH implementation ofGibbs-Poole–Stockmeyer reordering is used.

The code for reproducing the sparsity patterns in Figures 6 and 7 and patterns on other meshescan be found at https://www.repository.cam.ac.uk/handle/1810/252670. The meshes areshown at http://fenicsproject.org/download/data.html#meshes.

2.10 Linear algebra interface

FEniCS uses the PETSc and SLEPc libraries as backends providing parallel infrastructure forlinear algebra, non-linear solvers, and eigensolvers. The wrapper layer to these packages hasbeen improved, in particular, as follows:

• PETScTAOSolver, the DOLFIN interface to the PETSc TAO framework, which providessolvers for non-linear optimization problems, has been introduced;

• LinearOperator, the DOLFIN interface to matrix-free operators, can now be unwrappedinto a respective PETSc or petsc4py object;


https://www.repository.cam.ac.uk/handle/1810/252670

http://fenicsproject.org/download/data.html#meshes

18

• SLEPcEigenSolver, the DOLFIN interface to eigensolvers, can now be unwrapped intoa respective SLEPc or slepc4py object.

The latter two extend the feature already available for other backend wrappers, e.g., PETScMatrix,PETScKrylovSolver, etc. This feature allows for finer, but still convenient, control over a solutionprocess and other details, in such cases when the coverage of backend features or options inDOLFIN is not sufficiently detailed.

In this release, support for the Trilinos Epetra backend has been removed. Support for the newerTrilinos Tpetra backend will be added to a future release.

2.11 Use of C++ 11

The FEniCS team has started using selected C++11 features, allowing removal of the dependencyon Boost shared pointers and some simplifications of the C++ source code. The set of featuresis limited for the time being, to remain compatible with some common compilers. GCC 4.6.3 isknown to be compatible.

For users of the DOLFIN C++ interface, the use of C++11 can lead to less verbose code by usingthe key word auto, initializer lists, and range-based loops, for instance.

2.12 Python versions

FEniCS now requires Python 2.7, and has experimental support for Python 3.x. As part ofsupporting Python 3, FIAT no longer depends on Scientific Python. In place of Scientific Python,which does not support Python 3, FIAT now depends on SymPy.

2.13 Packaging and installation

As before, FEniCS is available as a binary package as part of the standard Debian and Ubunturepositories. For users who wish to access the latest FEniCS versions before these have propagateddownstream, a personal package archive (PPA) is provided (ppa:fenics-packages/fenics). Abinary package is also available for Mac OSX.

With the release of version 1.5, FEniCS has retired the installer Dorsal in favor of the newtool fenics-install.sh. This script relies on HashDist (https://hashdist.github.io/) forinstallation of FEniCS and its dependencies. Using this script, users can easily build FEniCS witha one-line command:

curl -s http://fenicsproject.org/fenics-install.sh | bash

FEniCS developers (who need to modify the source code) are encouraged to use the two relatedscripts fenics-install-all.sh and fenics-install-component.sh as standard tools in theirnormal workflow. These scripts are part of the FEniCS Developer Tools repository on BitBucket.

In addition, FEniCS can now also be installed via a community-supported Conda recipe, seehttps://github.com/Juanlu001/fenics-recipes/releases/tag/v1.5.0 as well as via a cus-tom virtualization image provided on the FEniCS web page.


ppa:fenics-packages/fenics

https://hashdist.github.io/

https://github.com/Juanlu001/fenics-recipes/releases/tag/v1.5.0


3 New demo programs

Some new example programs have been added to demonstrate the use of new user-level features.The new demo programs are:

• Smoothed aggregation algebraic multigrid for three-dimensional elasticity. The demo il-lustrates the construction and specification of the near-nullspace which is required by themultigrid preconditioner. It also demonstrates how to construct a scalable solver for elas-ticity problems.

• Two new demos illustrating the implementation of multimesh-methods: multimesh-poissonand multimesh-stokes.

4 Interface changes

The following interface changes were made in the release of FEniCS version 1.5:

• The classes FacetArea, FacetNormal, CellSize, CellVolume, SpatialCoordinate,Circumradius, MinFacetEdgeLength, and MaxFacetEdgeLength now require a Mesh argu-ment instead of a Cell argument.

• The signature for the assemble function has been simplified to not require/accept the argu-ments coefficients, cells, and common_cell.

• Differentiation of expressions with respect to a Coefficient or Function using diff doesnot require the function to be wrapped in a variable construct.

• Quadrature degree and rule name can be specified as keywords to form integration mea-sures, i.e. f*dx(degree=3, rule="canonical"). The syntaxMeasure.__getitem__(mesh_function).__call__(subdomain_id),e.g., dx[mesh_function](42), has been deprecated in favor of keyword arguments, forexample: dx(subdomain_data=mesh_function, subdomain_id=42).

• GenericTensors cannot be reinitialized anymore, hence the reset_sparsity parameter hasbeen removed from all assemble functions.

• Deprecated MPI::process_number and MPI::num_processes were removed in favor ofMPI::rank and MPI::size respectively.

• GenericVector.__setitem__, e.g., vec[indices] = values, now takes localindiceswhichcan be list of ints, NumPy array of ints, int, or full slice :. Type of values can be scalar,NumPy array, or GenericVectorwhere applicable. Operation is collective and finalizes thevector automatically.

5 Dependencies

FEniCS, mostly DOLFIN, depends on a number of external packages. Here we list and describethese external packages, along with required version numbers (to the best of our knowledge).

Necessary dependencies:

• C++11 compiler (GCC ≥ 4.6 and Clang 3.6 are known to work), see section 2.11 for details

• Boost ≥ 1.48; provides some low-level data structures and algorithms, DOF reordering andmesh coloring [Schling, 2011]

• CMake ≥ 2.8; used by DOLFIN build system and optionally by Python JIT chain


20

• Eigen≥ 3.0; provides data structures and operations used by adaptive solvers [Guennebaudet al., 2015]

• Python 2.7 or ≥ 3.2; six (Python 2 and 3 compatibility tool); needed by FIAT, UFL, FFC, andInstant; optionally needed for Python interface to DOLFIN and mshr

• NumPy; Python package providing data structures and operations on N-dimensional arrays[van der Walt et al., 2011]

• SymPy; Python symbolic maths library, used by FIAT [SymPy Development Team, 2014]

Optional dependencies:

• OpenMP; supports parallel computing on shared memory systems

• MPI; supports parallel computing on distributed memory systems

• PETSc ≥ 3.3, < 3.6; serves as parallel (linear) algebra backend; provides data structuresand routines for handling parallel vectors, matrices, Krylov solvers, sparse direct solvers,various preconditioners and non-linear solvers [Balay et al., 2014b,a, 1997]

• petsc4py ≥ 3.3, < 3.6; provides Python bindings to PETSc [Dalcin et al., 2011]

• SLEPc ≥ 3.3, < 3.6; provides parallel eigen-problem solvers [Hernandez et al., 2005]

• slepc4py ≥ 3.5.1, < 3.6; provides Python bindings to SLEPc [Dalcin et al., 2011]

• UMFPACK; provides sequential sparse LU decomposition using multifrontal method [Davis,2004]

• CHOLMOD; provides sequential sparse Cholesky decomposition using supernodal method[Chen et al., 2008]

• PaStiX ≥ 5.2.1; provides parallel (both distributed and threaded) sparse LU and Choleskydecomposition [Hénon et al., 2002]

• Trilinos ≥ 11.0.0; provides mesh partitioning and coloring [Heroux et al., 2005]

• SCOTCH; provides mesh partitioning and DOF reordering [Chevalier and Pellegrini, 2006]

• ParMETIS ≥ 4.0.2; provides mesh partitioning [Karypis and Kumar, 1998]

• SWIG ≥ 2.0 (with Python 2) or ≥ 3.0.3 (with Python 3); tool needed for generating Pythoninterface to DOLFIN and mshr

• flufl.lock; implements file locking (used by Instant) on NFS file system

• HDF5; provides parallel, scalable IO backend; needs to be built with parallel support [TheHDF Group, 2015]

• zlib; reading compressed XML files and compressed VTK output

• VTK ≥ 5.2; provides interactive plotting in DOLFIN

• CGAL 4.5.1, TetGen 1.5.0; mshr backends, built automatically by mshr build system [TheCGAL Project, 2015, Si, 2015]

• GMP, MPFR; arbitrary-precision and multiple-precision arithmetic libraries, required bymshr [Granlund and the GMP development team, 2014, Fousse et al., 2007]

• Scipy; needed by UFL for evaluation of error and Bessel functions



• pytest; Python testing tool, needed for running unit tests

• Sphinx ≥ 1.1.0; enables building documentation

• Qt4; provides API for writing graphical applications

• Soya; Python 3D engine, used for plotting finite elements

6 How to cite FEniCS 1.5

Users of FEniCS version 1.5 are encouraged to cite this article, in addition to one or more of thepublications listed on the FEniCS Project web site:

http://fenicsproject.org/citing/

7 Acknowledgments

Although this article lists as authors only those developers who have made significant contri-butions specifically to the release of FEniCS 1.5, we gratefully acknowledge the contributionsby many people to the FEniCS Project, including Martin S. Alnæs, Jan Blechta, Juan Luis CanoRodríguez Patrick Farrell, Johan Hake, Johan Hoffman, Johan Jansson, Niclas Jansson, AugustJohansson, Claes Johnson, Benjamin Kehlet, Robert C. Kirby, Matthew Knepley, Miroslav Kuchta,Hans Petter Langtangen, Anders Logg, Kent-Andre Mardal, Andre Massing, Mikael Mortensen,Harish Narayanan, Chris Richardson, Johannes Ring, Marie E. Rognes, L. Ridgway Scott, OlaSkavhaug, Andy Terrel, Garth N. Wells, and Kristian Ølgaard.

The FEniCS Project is supported by The Research Council of Norway through a Centre of Ex-cellence grant to the Center for Biomedical Computing at Simula Research Laboratory, projectnumber 179578. Anders Logg acknowledges support by the Swedish Research Council GrantNo. 2014–6093. Jan Blechta acknowledges the support of the project LL1202 in the programmeERC-CZ funded by the Ministry of Education, Youth and Sports of the Czech Republic.

ReferencesD. N. Arnold and A. Logg. Periodic table of the finite elements. SIAM News, 2014.

D. N. Arnold, R. S. Falk, and R. Winther. Finite element exterior calculus, homological tech-niques, and applications. Acta numerica, 15:1–155, 2006. URL http://dx.doi.org/10.1017/S0962492906210018.

S. Balay, W. D. Gropp, L. C. McInnes, and B. F. Smith. Efficient management of parallelism inobject oriented numerical software libraries. In E. Arge, A. M. Bruaset, and H. P. Langtangen,editors, Modern Software Tools in Scientific Computing, pages 163–202. Birkhäuser Press, 1997.URL http://dx.doi.org/10.1007/978-1-4612-1986-6_8.

S. Balay, S. Abhyankar, M. F. Adams, J. Brown, P. Brune, K. Buschelman, V. Eijkhout, W. D. Gropp,D. Kaushik, M. G. Knepley, L. C. McInnes, K. Rupp, B. F. Smith, and H. Zhang. PETSc usersmanual. Technical Report ANL-95/11 - Revision 3.5, Argonne National Laboratory, 2014a. URLhttp://www.mcs.anl.gov/petsc.

S. Balay, S. Abhyankar, M. F. Adams, J. Brown, P. Brune, K. Buschelman, V. Eijkhout, W. D. Gropp,D. Kaushik, M. G. Knepley, L. C. McInnes, K. Rupp, B. F. Smith, and H. Zhang. PETSc Webpage, 2014b. URL http://www.mcs.anl.gov/petsc.

Y. Chen, T. A. Davis, W. W. Hager, and S. Rajamanickam. Algorithm 887: CHOLMOD, supernodalsparse Cholesky factorization and update/downdate. ACM Trans. Math. Softw., 35(3):22:1–22:14,Oct. 2008. ISSN 0098-3500. URL http://doi.acm.org/10.1145/1391989.1391995.


http://fenicsproject.org/citing/

http://dx.doi.org/10.1017/S0962492906210018

http://dx.doi.org/10.1017/S0962492906210018

http://dx.doi.org/10.1007/978-1-4612-1986-6_8

http://www.mcs.anl.gov/petsc

http://www.mcs.anl.gov/petsc

http://doi.acm.org/10.1145/1391989.1391995

22

C. Chevalier and F. Pellegrini. PT-Scotch: A tool for efficient parallel graph ordering. In 4thInternational Workshop on Parallel Matrix Algorithms and Applications (PMAA’06), IRISA, Rennes,France, Sept. 2006.

L. D. Dalcin, R. R. Paz, P. A. Kler, and A. Cosimo. Parallel distributed computing using Python.Advances in Water Resources, 34(9):1124 – 1139, 2011. ISSN 0309-1708. URL http://dx.doi.org/10.1016/j.advwatres.2011.04.013. New Computational Methods and Software Tools.

T. A. Davis. Algorithm 832: UMFPACK v4.3—an unsymmetric-pattern multifrontal method.ACM Trans. Math. Softw., 30(2):196–199, June 2004. ISSN 0098-3500. URL http://doi.acm.org/10.1145/992200.992206.

L. Fousse, G. Hanrot, V. Lefèvre, P. Pélissier, and P. Zimmermann. MPFR: A multiple-precisionbinary floating-point library with correct rounding. ACM Transactions on Mathematical Software,33(2):13:1–13:15, June 2007. URL http://doi.acm.org/10.1145/1236463.1236468.

T. Granlund and the GMP development team. GNU MP: The GNU Multiple Precision ArithmeticLibrary, 6.0.0 edition, 2014. URL http://gmplib.org/.

G. Guennebaud, B. Jacob, et al. Eigen v3, 2015. URL http://eigen.tuxfamily.org.

P. Hénon, P. Ramet, and J. Roman. PaStiX: A High-Performance Parallel Direct Solver for SparseSymmetric Definite Systems. Parallel Computing, 28(2):301–321, Jan. 2002. URL http://dx.doi.org/10.1016/S0167-8191(01)00141-7.

V. Hernandez, J. E. Roman, and V. Vidal. SLEPc: A scalable and flexible toolkit for the solutionof eigenvalue problems. ACM Trans. Math. Software, 31(3):351–362, 2005. URL http://dx.doi.org/10.1145/1089014.1089019.

M. A. Heroux, R. A. Bartlett, V. E. Howle, R. J. Hoekstra, J. J. Hu, T. G. Kolda, R. B. Lehoucq,K. R. Long, R. P. Pawlowski, E. T. Phipps, A. G. Salinger, H. K. Thornquist, R. S. Tuminaro,J. M. Willenbring, A. Williams, and K. S. Stanley. An overview of the Trilinos project. ACMTrans. Math. Softw., 31(3):397–423, 2005. ISSN 0098-3500. URL http://doi.acm.org/10.1145/1089014.1089021.

A. Johansson, M. G. Larson, and A. Logg. High order cut finite element methods for the stokesproblem. Advanced Modeling and Simulation in Engineering Sciences, 2(24), 2015. doi: 10.1186/s40323-015-0043-7.

G. Karypis and V. Kumar. A fast and high quality multilevel scheme for partitioning irregulargraphs. SIAM J. Sci. Comput., 20(1):359–392, Dec. 1998. ISSN 1064-8275. URL http://dx.doi.org/10.1137/S1064827595287997.

A. Plaza and G. Carey. Local refinement of simplicial grids based on the skeleton. Applied NumericalMathematics, 32:195–218, 2000. URL http://dx.doi.org/10.1016/S0168-9274(99)00022-7.

C. N. Richardson and G. N. Wells. Parallel scaling of DOLFIN on ARCHER. figshare.com,http://figshare.com/articles/Parallel_scaling_of_DOLFIN_on_ARCHER/1304537, 2015.URL http://dx.doi.org/10.6084/m9.figshare.1304537.

S. Rush and H. Larsen. A practical algorithm for solving dynamic membrane equations. IEEE TransBiomed Eng, 25(4):389–392, Jul 1978. URL http://dx.doi.org/10.1109/TBME.1978.326270.

B. Schling. The Boost C++ Libraries. XML Press, 2011. ISBN 0982219199, 9780982219195.

H. Si. TetGen, a Delaunay-based quality tetrahedral mesh generator. ACM Trans. Math. Softw., 41(2):11:1–11:36, Feb. 2015. ISSN 0098-3500. URL http://doi.acm.org/10.1145/2629697.


http://dx.doi.org/10.1016/j.advwatres.2011.04.013

http://dx.doi.org/10.1016/j.advwatres.2011.04.013

http://doi.acm.org/10.1145/992200.992206

http://doi.acm.org/10.1145/992200.992206

http://doi.acm.org/10.1145/1236463.1236468

http://gmplib.org/

http://eigen.tuxfamily.org

http://dx.doi.org/10.1016/S0167-8191(01)00141-7

http://dx.doi.org/10.1016/S0167-8191(01)00141-7

http://dx.doi.org/10.1145/1089014.1089019

http://dx.doi.org/10.1145/1089014.1089019

http://doi.acm.org/10.1145/1089014.1089021

http://doi.acm.org/10.1145/1089014.1089021

http://dx.doi.org/10.1137/S1064827595287997

http://dx.doi.org/10.1137/S1064827595287997

http://dx.doi.org/10.1016/S0168-9274(99)00022-7

http://dx.doi.org/10.6084/m9.figshare.1304537

http://dx.doi.org/10.1109/TBME.1978.326270

http://doi.acm.org/10.1145/2629697


J. Sundnes, R. Artebrant, O. Skavhaug, and A. Tveito. A second-order algorithm for solvingdynamic cell membrane equations. IEEE Trans Biomed Eng, 56(10):2546–2548, Oct 2009. URLhttp://dx.doi.org/10.1109/TBME.2009.2014739.

SymPy Development Team. SymPy: Python library for symbolic mathematics, 2014. URL http://www.sympy.org.

The CGAL Project. CGAL User and Reference Manual. CGAL Editorial Board, 4.6 edition, 2015.URL http://doc.cgal.org/4.6/Manual/packages.html.

The HDF Group. Hierarchical data format, version 5, 2015. URL http://www.hdfgroup.org/HDF5/.

S. van der Walt, S. Colbert, and G. Varoquaux. The NumPy Array: A structure for efficientnumerical computation. Computing in Science Engineering, 13(2):22–30, March 2011. ISSN 1521-9615. URL http://dx.doi.org/10.1109/MCSE.2011.37.


http://dx.doi.org/10.1109/TBME.2009.2014739

http://www.sympy.org

http://www.sympy.org

http://doc.cgal.org/4.6/Manual/packages.html

http://www.hdfgroup.org/HDF5/

http://www.hdfgroup.org/HDF5/

http://dx.doi.org/10.1109/MCSE.2011.37

the fenics project version 1publications.lib.chalmers.se/records/fulltext/228672/... ·...

Documents