?? dopelib: differential equations and optimization ... · winnifried wollner, university of...

??

DOpElib: Differential Equations and Optimization Environment; AGoal Oriented Software Library for Solving PDEs and OptimizationProblems with PDEs

CHRISTIAN GOLL, University of HeidelbergTHOMAS WICK, The University of Texas at AustinWINNIFRIED WOLLNER, University of Hamburg

In this article, we describe the Differential Equations and Optimization Environment (DOpElib). DOpElib isa software library that provides a unified interface to high level algorithms such as time-stepping methods,nonlinear solvers and optimization routines. This structure ensures that, first of all, the user is only requiredto write those sections of code that are specific to the considered problem. Second, the exchange of parts ofthe used routines is possible with only a few lines of code to change instead of large reimplementations. Thearticle illustrates the design principles and various features of DOpElib and provides some numerical resultsas demonstration for the versatility of the software.

Categories and Subject Descriptors: G.4 [Mathematical Software]: Optimization routines and interfaceto finite element software; G.1.6 [Optimization]: Optimization with partial differential equations – Con-strained optimization; G.1.8 [Partial Differential Equations]: Finite element method

General Terms: Algorithms, Design, Documentation

Additional Key Words and Phrases: goal oriented interface design, numerical solution of optimization prob-lems and partial differential equations

ACM Reference Format:Goll, C.; Wick, G.; Wollner, W.; DOpElib: Differential Equations and Optimization Environment. ACM Trans.Math. Softw. ?, ?, Article ?? ( ???), 18 pages.DOI = 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000

1. INTRODUCTIONToday, there exists a broad variety of software libraries that provide numerical toolsfor solving partial differential equations (PDEs). Prominent examples are deal.II[Bangerth, Heister, and Kanschat Bangerth et al.], dune [ DUNE], FEniCS [ FEniCS]or commercial solvers as for instance ANSYS (with its Fluent package), COMSOL, orsimufact forming. Finally, a lot of work is (still) done in Matlab. In fact, these librariesprovide very useful tools for a huge variety of applications.

In many cases, the user is confronted with certain bottlenecks when using such soft-ware. On the one hand, in open-source projects for academic research, standard high-level routines which are necessary to solve even simplest PDEs, such as linear and non-linear solvers or time-stepping schemes must be implemented by the users themselves.

Author’s addresses: C. Goll, Institute of Applied Mathematics, University of Heidelberg, Im NeuenheimerFeld 293/294, 69120 Heidelberg, Germany, [email protected]; T. Wick, The Institute forComputational Engineering and Sciences, The University of Texas at Austin, Austin, Texas 78712, USA,[email protected]; Winnifried Wollner, Universität Hamburg, Department of Mathematics, Bundesstr.55, 20146 Hamburg, Germany,[email protected];Permission to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or commercial advantage and thatcopies show this notice on the first page or initial screen of a display along with the full citation. Copyrightsfor components of this work owned by others than ACM must be honored. Abstracting with credit is per-mitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any componentof this work in other works requires prior specific permission and/or a fee. Permissions may be requestedfrom Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212)869-0481, or [email protected]© ??? ACM 0098-3500/???/-ART?? $10.00

DOI 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000

ACM Transactions on Mathematical Software, Vol. ?, No. ?, Article ??, Publication date: ???.

??:2 C. Goll et al.

However, such routines are, at large, problem-independent and could be provided asstandard tools. As our guiding design principle, we note that in many numerical stud-ies, the main task is the computation of some target functional, e.g., error norms, pointvalues, or certain mean-values such as drag or lift coefficients. As a second motivatingprinciple, there is nowadays an increasing interest in solving optimization problems inwhich the state equation is governed by a PDE. Such optimization problems compriseoptimal control, parameter estimation, inverse problems or optimal experimental de-sign. To do this in complex applications requires tremendous work already on the PDEitself before considering optimization of the processes modeled by the PDE. Thus it isadvantageous to have an environment that allows to focus on the development of anappropriate code for the PDE at first but asserts due to the required interface, thatthe code written for the PDE is then reusable for the application of state-of-the-artoptimization routines.

On the other hand, commercial finite element (FE) toolkits provide these previouslymentioned routines but limits user-interaction with the source code to an extend thattypically conflicts with the consideration of problems deviating from the intended user-base for the commercial product. This is quite unsatisfactory because in the develop-ment of novel numerical algorithms or in the solution of more complex applications theresearcher needs to be enabled to change certain parameters or pieces of source code.

This article will provide information on how the Differential Equations and Opti-mization Environment DOpElib [ DOpElib] solves these problems by providing a wellstructured interface for high-level routines integrated with tools to solve PDEs. Atthe present stage we provide an interface to the finite element library deal.II and acollection of algorithms to solve both pure PDE problems as well as optimization prob-lems constrained by a PDE. This provides an extension to the very few tools availabledoing so; successful in-house code examples are Gascoigne [ Gascoigne] and RoDoBo[ RoDoBo]. Like DOpElib, both have been initiated as well in the Numerical AnalysisGroup in Heidelberg.

The main feature of DOpElib is to give a unified interface to high level algorithmssuch as time-stepping methods, nonlinear solvers and optimization routines. DOpElibis designed in such a way that the user only needs to write those parts of the code thatare problem dependent while all invariant parts of the algorithms are reusable withoutany need for further coding. In particular, the user is enabled to switch between variousdifferent algorithms without the need to rewrite the problem dependent code, thoughobviously he or she will have to replace the algorithm object with an other one. Thisreplacement can be done by replacing the appropriate object at only one point in thecode.

While deal.II –which at present is the only FE-toolkit to which we provide aninterface– leaves the implementation of all high-level algorithms to the user, DOpElibis user-focused by delivering prefabricated tools which require adjustments by the useronly for parts connected to his specific problem. The possible solution of optimizationproblems with PDE constraints is an innovative feature in DOpElib.

To give a brief overview, at the present stage of the development the following keyfeatures are supported by the library

— Solvers for nonlinear stationary and nonstationary PDEs in 1d, 2d, and 3d.— Various, easily exchangeable, time-stepping schemes (based on finite differences),

such as forward Euler, backward Euler, Crank-Nicolson, shifted Crank-Nicolson, andFractional-Step-Θ scheme.

— Use of all finite elements of from deal.II including hp-support.— Several examples showing the solution of PDEs including Poisson, Navier-Stokes,

Plasticity and fluid-structure interaction problems.


DOpElib: Differential Equations and Optimization Environment ??:3

— Line search and trust region Newton algorithms for the solution of optimization prob-lems with PDE constraints by elimination of the state variable.

— Interface to SNOPT for the solution of optimization problems with PDEs and addi-tional other control and state constraints.

— Several examples showing how to solve various kinds of optimization problems in-volving stationary and nonstationary PDE constraints.

— Goal-oriented mesh adaptation with the Dual Weighted Residual method and stan-dard residual based error estimators.

— Different spatial triangulations for control and state variables without the need toreimplement the user dependent code when switching from one common triangula-tion to different ones.

The article is organized as follows. In the main Section 2, a detailed description of themain features is given. First, we explain the solution of stationary PDEs, in Section 2.1,nonstationary PDEs, in Section 2.2, and optimization problems, in Section 2.3. In allthree cases we first described how the interface is designed, and why it is designed assuch. Then the implementation required by the user is demonstrated at an example.Finally, additional features are discussed in Section 2.4. In the final Section 3, we givethree different numerical examples which illustrate the versatile features of DOpElib.

2. DETAILED DESCRIPTION OF THE MAIN FEATURESThis library is designed to allow easy implementation for the numerical solution ofproblems involving PDEs. By providing interfaces to existing FE-toolkits, at presentdeal.II, we remove all tedious routine implementation needed in deal.II by introduc-ing appropriate classes that take care of all the problem independent implementationwhile leaving only the problem specific parts to the user. To show how this is designed,we will, in the sequel, describe the reasoning, first, for a simple stationary PDE, inSection 2.1, and then show how this idea extends to non stationary problems, in Sec-tion 2.2, as well as to optimization problems with PDE constraints in, Section 2.3.

2.1. Solving Stationary PDEsFor the start, we consider a prototypical problem given by the solution of a stationaryPDE, which we assume to be given in weak form. In abstract notation it reads; findsome u in an appropriate set such that

a(u)(ϕ) = (f, ϕ) ∀ϕ ∈ V, (2.1)

with some suitable space V for the test functions and a right hand side function f . Toillustrate this further, we take the stationary incompressible Navier-Stokes equationsin a domain Ω ⊂ Rd, i.e., u = (v, p) and ϕ = (ϕu, ϕp) then

a(u)(ϕ) = ν(∇v,∇ϕu) + (v∇v, ϕu) + (p,∇ · ϕu) + (∇ · v, ϕp) (2.2)

for all ϕ ∈ V = H10 (Ω;Rd)×L2

0(Ω). Here (·, ·) denotes the L2-inner-product. The solutionwill be searched for in V + (ud, 0) where ud is some continuation of the given Dirichletboundary data. In a typical calculation, we do not only want to calculate u but morelikely we are interested in one (or several) functionals depending on the solution, i.e.,some numbers J(u).

In order to solve this problem, i.e., calculate a sequence of values J(uh) approximat-ing J(u), we need to discretize the equation. In DOpElib, we are using finite elements,as they are provided by deal.II, to do this. This means we need to pick a subdivisionTh, for instance into quadrilaterals, of the domain Ω and a finite element. In the con-crete case, we could, for instance, take the inf-sup stable Q2/Q1 Taylor-Hood element.As it is clear, that the initialization of the unknowns, the local shape functions, re-


??:4 C. Goll et al.

moval of hanging node constraints, etc. always follows the same procedure, we definean object which takes the finite element (FE) and the triangulation and takes care ofall other things related to handling the finite element space Vh. We will refer, to thisobject as the SpaceTimeHandler since it is also capable of coping with unknowns fortime dependent problems. Then, it is clear that the simplest form of the constructorshould have the following interface:

template<typename TRIANGULATION, typename FE>void SpaceTimeHandler (TRIANGULATION& triag , FE& fe ) ;

Next, one needs to solve the discrete equation

a(uh)(ϕh) = (f, ϕh) ∀ϕ ∈ Vh. (2.3)

To this end, one can employ a Newton type method with some globalization like line-search, see, e.g., [Nocedal and Wright 2000]. To apply the Newton method, one needsto calculate the residual of the equation, solve linearized equations for the calculationof the update, and then employ some kind of globalization strategy. Again, this willusually require the evaluation of the residual.

The evaluation of the residual will require the calculation of the integrals involved inthe weak formulation of the problem. For example the i-th component of the residual,with respect to the given FE-basis ϕi

h, will read as follows

a(uh)(ϕih)− (f, ϕi

h) =∑

K∈Th

∫K

ν∇uh · ∇ϕih dx+ . . . (2.4)

Again, we see that, except for the local cell (element) integrals, all calculations are in-dependent from the concrete form of the PDE. Hence we define an object Integratorthat offers a method to calculate the residual given a user-defined object pde that im-plements the local cell integrals, i.e.,

template<typename PROBLEM, typename VECTOR>void Integrator

: : ComputeNonlinearResidual (PROBLEM& pde ,VECTOR & residual ) ;

where VECTOR is some vector type in which the residual should be stored. It is clearthat we need to ensure that the integrator object has access to the information storedin the SpaceTimeHandler to correctly loop over all cells. To solve the linearized systems,again, all that is left is the calculation of the matrix corresponding to the linearizedequation. To calculate this, we can define a method in the integrator that does exactlythis provided we have a user defined object pde that can evaluate the local integralsneeded for assembling the matrix, i.e.,

template<typename PROBLEM, typename MATRIX>void Integrator

: : ComputeMatrix (PROBLEM& pde ,MATRIX & system_matrix ) ;

where now MATRIX is an appropriate matrix type needed by the linear solver. Withthis we can now define a nonlinear solver NewtonSolver for the solution of the discreteproblem requiring the existence of the following function

template<typename LINSOLVE>template<typename PROBLEM, typename VECTOR>

void NewtonSolver<LINSOLVE>: : NonlinearSolve (PROBLEM& pde ,



VECTOR & solut ion ) ;

Where LINSOLVE denotes the solver that should be used to solve the linearized equa-tions during the Newton iteration.

Finally, we note that to compute the requested functional value all that is left isto evaluate the functional in the computed solution which can be done again usingan appropriate integrator method. Since the sequence of events sketched above isagain independent of the exact problem we introduce another container which we callStatPDEProblem that then simply provides the user with the method

template<c lass NEWTON>void StatPDEProblem<NEWTON>

: : ComputeReducedFunctionals ( ) ;

that takes care of calling all other methods needed for the calculation of J(uh). Thetemplate argument NEWTON represents the chosen solver of the nonlinear problems.That combines all the necessary steps to calculate J(uh).

Finally, we will need to have an object that is capable of providing all the neces-sary functionality required from the template argument PROBLEM in all of the above.We provide a wrapper named PDEProblemContainer collecting all the problem specificinformation like the description of the PDE and the functional, the boundary values,etc. Although, having such an object instead of directly giving these information to theStatPDEProblem seems like a nuisance at the moment, we will see that it is of greaterinterest for time-dependent problems or optimization problems in what follows in Sec-tion 2.2 and Section 2.3 respectively.

Remark 2.1. In fact, the above constructors are not exactly what is implemented inDOpElib. This is due to the fact, that for instance there are several different sparsitypatterns available in deal.II which the user should be able to choose. Thus it needs tobe given to the SpaceTimeHandler. However, to keep the presentation clear, and sincedefault values are available for these arguments, we refrained from including thesedetails above and in what follows.

Remark 2.2. The reason to include the nonlinear solver as a template argumentin StatPDEProblem is that if a given problem can not be solved with this algorithm,e.g., it has no derivatives, then the user should be able to exchange only the nonlinearsolver. Further, this makes it possible to compare different algorithms available forthe solution of the PDE without the need to recode other parts of the problem, therebyhelping in doing fair comparisons.

In the next section we will now sketch the way a user needs to implement the user-dependent data as the local cell integrals and the initialization of the objects describedabove.

2.1.1. Problem Dependent Implementation of Stationary PDE Problems. To solve a stationaryPDE problem, the user has to provide some code which can roughly be divided into thefollowing main sections:

Discretization. Specification of discretization issues such as finite elements,quadrature rules, and triangulation.Solvers. Choice of a (non-)linear solver.Problem-data. Definition of the weak form, the corresponding matrices, the func-tionals J , as well as the boundary conditions.Additional features. ParameterReader to read in the run-time parameters suchas material coefficients or adjustments for the solvers like tolerance for Newton’smethod.


??:6 C. Goll et al.

The first two points will be done below in the discussion of the file main.cc. The thirdpoint is done separately in the file pde.h and func.h for convenience. The specificationof additional features is skipped, since it consist of reading in a text-file only.

Now, we describe a program designed to compute a value J(u), where u = (v, p) isthe solution of the Navier-Stokes equations (2.2) on the domain Ω as seen in Fig. 1 withf = 0, and J is the drag-force of the enclosed circle. We assume given Dirichlet datafor the velocity v on the boundary ΓD = Γin ∪Γwall ∪Γcirc. This is the Benchmark-Case2D-1 described in [Turek and Schäfer 1996].

(2.5, 0)

(2.5, 0.41)(0, 0.41)

(0, 0)

Ω

Γwall

Γwall

ΓinΓcirc Γout

Fig. 1: Flow around a cylinder with circle-center C = (0.2, 0.2) and radius r = 0.05.

We split the program into the parts main.cc, func.h and pde.h. The main.cc-file isresponsible for the declaration of various objects which have mostly to do with thediscretization, the solvers and the general program sequence, whereas the other twocontain most of the problem-data – especially the cell-wise contributions of the weakform in pde.h and the functional in func.h. We give a brief explanation on every file inthe following.

2.1.2. main.cc. In this file, we gather all the basic components that are necessary forthe solution process of a (stationary) partial differential equation. The structure of theprogram is basically the same for every equation under consideration, what changesis typically just the kind of finite element or linear solver we want to use. Here, a keyissue is that we only need to pick some pre-implemented routines from the DOpEliblibrary rather than implementing these ourselves.

After the usual preamble, in which we include the necessary header-files fromdeal.II, DOpElib and our own problem-data (i.e. func.h and pde.h), we start by defin-ing an instance of a ParameterReader-object, which handles reading of run-time pa-rameters.

ParameterReader pr ;

The object pr then reads a text-file in which we might specify some problem-relatedparameters (for instance the viscosity ν), but also general parameters for (non)-linearsolvers and the output-format of computed data. After that, we create a triangulationof the domain Ω named triangulation using the tools provided by the deal.II FE-library.

Next, we create some quadrature rules (for the evaluation of integrals over cellsquad and faces face_quad) and a finite element fe appropriate for the PDE at hand. Wechoose a Gaussian quadrature of a certain degree and the previously mentioned Taylor-Hood element. These routines are quite standard in each finite element software andthus we can use those provided by the FE-library deal.II.

Then, the two characteristic features LocalPDE and LocalFunctional objects comeinto play:



LocalPDE pde ;LocalFunctional funct ional ;

These hold the information of the PDE and the functional under consideration. Furtherexplication is given below because the definition of this classes is done separately inpde.h and func.h respectively.

In the next step, we define an object of type SpaceTimeHandler, which handles all thethings connected with the triangulation as well as the finite element space.

SpaceTimeHandler dof_handler ( tr iangulation ,fe ) ;

Now we have everything at hand to create an instantiation of the container for theproblem data PDEProblemContainer. This basically represents the discretized problem,and bundles things like boundary conditions, the PDE, the functional and the dis-cretization. First, we give the constructor the pde and the dof_handler.

PDEProblemContainer<LocalPDE>prob_container ( pde , dof_handler ) ;

After that, we add the functional under consideration and, because it is a functionalacting on the boundary, specify the part of the boundary on which the functional oper-ates (this is done via a ’boundary color’, where 1 represents Γcirc).

prob_container . AddFunctional(&funct ional ) ;prob_container . SetBoundaryFunctionalColors ( 1 ) ;

Next, we incorporate the Dirichlet data. To this end, we instantiate a classDirichletData containing the required description of the boundary values. Then wehave to tell the prob_container for which components and boundaries we prescribethe Dirichlet conditions. This is done via a boundary-color and a so-called componentmask (here, 0 denotes ΓD).

DirichletData dd ;prob_container . SetDirichletBoundaryColors (0 ,

comp_mask ,dd ) ;

Now, we create the object which steers the whole solution process, the previously men-tioned StatPDEProblem. It takes care of solving the discretized equation and evaluatingthe given functionals. The class depends actually on some template-parameters, so forthe sake of abbreviation, we defined a typedef at the beginning of the main.cc-file.

typedef StatPDEProblem<NEWTON> PDE;

Here, NEWTON itself is an abbreviation of

typedef NewtonSolver<LINSOLVE> NEWTON;

The template parameter LINSOLVE describes which linear solver we use in this exam-ple. We opted for a direct solver, so:

typedef DirectLinearSolver <MATRIX, VECTOR> LINSOLVE;

With the types settled, we create the object solver, which needs the discretization (rep-resented here by the prob_container), the parameter reader as well as the quadraturerules.

PDE pde ( prob_container , pr ,quad , face_quad ) ;


??:8 C. Goll et al.

Finally, we compute the value J(uh) by calling:

pde . ComputeReducedFunctionals ( ) ;

2.1.3. pde.h. We shall now give an overview to the implementation of the specific formof the PDE.

Let N be the number of degrees of freedom (DoFs) of our discretization andϕih

∣∣ 1 ≤ i ≤ N

be a given FE-Basis. As stated in subsection 2.1, to solve the dis-crete equation (2.3) we need the residual, i.e., the vector(

a(uh)(ϕih)− (f, ϕi

h))Ni=1

. (2.5)

The corresponding Jacobian can be defined analogously. Now, all we have to supplyhere are the cell-wise contributions to these terms, then the Integrator object takescare of assembling (2.5) and similarly of the matrix for the linearized equation to besolved.

To this end, we define a class LocalPDE which provides the three methodsCellEquation, CellRightHandSide and CellMatrix. The splitting of these terms is sim-ilar to Gascoigne [ Gascoigne] whereas the content (i.e., the implementation itself) ofthese terms works as it is required by the FE-library for which the integration is done,here this is deal.II.

We show the basic structure of these methods using the CellEquation method forthe implementation of the cell-wise integrals.

void CellEquation ( const CellDataContainer &cdc ,VECTOR &loca l_vec tor )

const auto& fe_values = cdc . GetFEValuesState ( ) ;unsigned int do fs_per_ce l l = cdc . GetNDoFsPerCell ( ) ;unsigned int n_q_points = cdc . GetNQPoints ( ) ;

The CellDataContainer contains all the information we need to compute the cell-contributions (things like number of quadrature points, number of degrees of freedomon the cell, the dealii::FEValues-objects, etc.). To get access to the values and thegradient of the solution in the quadrature points we need to extract them from theCellDataContainer:

cdc . GetValuesState ( " state " , uvalues ) ;cdc . GetGradsState ( " state " , ugrads ) ;

In these two lines, we load the values and the gradient of the solution during the lastNewton iteration in all the quadrature points on the cell into the two variables uvaluesand ugrads.

In the next lines, we finally implement our concrete cell contribution of the PDE.Thus, we loop over the quadrature points and the number of DoFs of the cell. In theinnermost loop, we evaluate the weak form tested with ϕi

h (here phi_i_grads_v de-notes the matrix ∇ϕi

h) on the cell with the help of the previously selected quadratureformula.

f or ( unsigned int q_point = 0;q_point < n_q_points ;q_point ++)

/ / i n i t i a l i z e phi_i_grads_v etc .Tensor <2,2> vgrads ;



vgrads [0]= ugrads [ q_point ] [ 0 ] ;vgrads [1]= ugrads [ q_point ] [ 1 ] ;f o r ( unsigned int i =0; i <do fs_per_ce l l ; i ++)

l o ca l_vec tor ( i ) +=( _nu ∗ vgrads ∗ phi_i_grads_v

+ / / a l l the other terms) ∗ fe_values .JxW( q_point ) ;

DOpElib takes care of the distribution of the local cell contributions into the vector ofthe residual (2.4). The methods CellRightHandSide and CellMatrix follow the samestructure as CellEquation, so we do not go into the details here.

2.1.4. func.h. The implementation of the boundary-functional J follows the outline ofthe computation of the cell-residual in pde.h. The main difference, and common to allfunctionals, is that as we only want to evaluate a functional, i.e. a number, and not aresidual-vector, we loop over the quadrature points and not over the local degrees offreedom.

In the present situation, we want to evaluate a functional that consists of a boundaryintegral. Thus we need to evaluate integrals on faces, those who lie on Γcirc, instead ofintegrals over cells. This face contributions are calculated in BoundaryValue and addedto sum up to the value of J .

doubleBoundaryValue ( const FaceDataContainer& fdc )

/ / same as before , get n_q_points etc .const auto& face_values = fdc . GetFEFaceValuesState ( ) ;fdc . GetFaceValuesState ( " state " , ufacevalues ) ;fdc . GetFaceGradsState ( " state " , ufacegrads ) ;

double erg = 0 . ;f o r ( unsigned int q_point = 0;

q_point < n_q_points ;q_point ++)

erg −= ( _nu ∗ ufacegrads [ q_point ] [ 0 ]∗ face_values . normal_vector ( q_point )+ / / other terms

) ∗ face_values .JxW( q_point ) ;return erg ;

2.2. Solving Nonstationary PDEsTo describe the solution of nonstationary PDEs, we consider a time-dependent semi-linear form a(u)(ϕ) and some right hand side f . Let I := [0, T ] be a time intervalwith end time point value T . The weak formulation of such a problem then consists offinding some u such that ∫

I

a(u)(ϕ) dt =

∫I

(f, ϕ) dt ∀Φ ∈ X,

with some suitable Bochner space X. As model problem, we extend the previous ex-ample and consider the nonstationary Navier-Stokes equations in a spatial domain


??:10 C. Goll et al.

Ω ∈ Rd. The weak formulation is then to find u = (v, p) ∈ X with∫I

[(∂tv, ϕ) + ν(∇v,∇ϕ) + (v · ∇v, ϕ)− (p,∇ · ϕ) + (∇ · v, χ)

]dt

+ (v(0)− v0, ϕ(0)) =

∫I

(f, ϕ) dt

for all Φ := (ϕ, χ) ∈ X with

X := (v, p) | v ∈ L2(I,H10 (Ω)d), ∂tv ∈ L2(I, L2(Ω)d), p ∈ L2(I, L2(Ω) \ R) .

We note that the only difference is the appearance of an additional time integration,the initial-value, and the term ∫

I

(∂tv, ϕ) dt

so that we can reuse our stationary implementation for all the other terms if we rescalethem appropriately in the time integration.

As for stationary problems, the goal is to compute some target functional J whichis now possibly time-dependent. To organize the discretization process, we need toperform spatial and temporal discretization. This is again done via an object that takescare of organizing the degrees of freedom, as in the case of stationary problems. Theonly difference to the stationary case is that we need to add the temporal subdivisiontimes. In the simplest case, when we have the same spatial triangulation at all times,the constructor could look as follows:

template<typename TIMES, typename TRIANGULATION,typename FE>

void SpaceTimeHandler (TIMES& times ,TRIANGULATION& triag ,FE& fe ) ;

Now we may discretize the problem with some time-stepping scheme, which will re-move the temporal derivative and replace it by some difference quotients. Since theexact way of doing this depends on the time-stepping scheme we need a new objectthat takes the user-given description of the PDE and generates the appropriate com-binations of spatial integrals and scaling. Thus a generic problem may look as follows:

template<typename PROBLEM>class TimeStepProblem ( Problem & P ) ;

At present we have prepared the following time-stepping schemes in DOpElib:

— Forward-(or Explicit)-Euler— Backward-(or Implicit)-Euler— Crank-Nicolson scheme— Shifted Crank-Nicolson scheme (to deal with singular initial data)— Fractional-Step-θ scheme

After choosing the time-stepping scheme, the SpaceTimeHandler loops over all time-steps, where in each of the time-steps we can reuse the functionality we have providedto solve stationary PDEs. This means for instance, if we have implemented the cell-integrals in the weak formulation for the stationary case, then we can use the exactsame implementation again for the solution of the nonstationary version of the equa-tion. However, we need to provide an additional term to cope with the integral for thetime derivative.



Now it is apparent, why we introduced the StatPDEProblem, because we define theInstatPDEProblem to contain the necessary loop over all time points. Consequently,the implementation of nonstationary problems is quite similar to stationary problems,at least from the user implementation point of view, which was one major goal weclaimed at the beginning. Next, we will describe the methods the user needs to providein addition to the stationary case.

2.2.1. Problem-Dependent Implementation of Nonstationary Problems. We explain in moredetail the temporal discretization and specific issues of its implementation. To keepthe presentation easy, we neglect all material coefficients to give the idea based on theweak form of the Navier-Stokes equations: Find (v, p) such that for all (ϕ, χ) and allt ∈ I

(∂tv, ϕ) + (∇v,∇ϕ) + (v · ∇v, ϕ)− (p,∇ · ϕ) + (∇ · v, χ) = (f, ϕ),

where f describes some volume forces. Temporal discretization using the One-step-θscheme reads: Given the old time-step solution (vn, pn), find (vn+1, pn+1) (and multipli-cation by the inverse of the time-step k):

(vn+1 − vn, ϕ) + kθ(∇vn+1,∇ϕ) + kθ(vn+1 · ∇vn + vn · ∇vn+1, ϕ)

− k(pn+1,∇ · ϕ) + k(∇ · vn+1, χ)

= kθ(fn+1, ϕ) + k(1− θ)(fn, ϕ)− k(1− θ)(∇vn,∇ϕ)

The concrete choice of θ leads to a specific time-stepping scheme. For instance, θ = 0.5gives the Crank-Nicolson scheme.

It is well-known in fluid mechanics that the pressure and incompressibility termsshould be treated fully implicitly when time-discretizing the Navier-Stokes equations.For this reason, the implementation is split up into several items to account for fullyimplicit terms and remaining terms for which we need old time-step and present time-step values. Hence, in the local cell equation, the parameters scale and scale_ico areused to distinguish these terms. I the present context this means that scale = ±kθ orscale = ±k(1− θ) and scale_ico = ±k.

With this the CellEquation needs to contain the terms weighted with the appropri-ate scaling as it is indicated below but is otherwise the same as it is in the stationarycase.

void CellEquation ( . . . )/ / Usual loops over DoFs and quadrature points

l o c a l _ c e l l _ v e c t o r ( i ) +=

scale ∗/ / terms l ike (\ nabla v^n+1 , \nabla\phi ) etc .

+ sca l e_ i co ∗/ / terms l ike (−p^n+1 ,\ nabla\cdot\phi )

Analogous procedure is performed in the local cell matrix.

Remark 2.3. Note that in the stationary case there is no such difference and ac-cordingly DOpElib automatically sets scale_ico = scale, so that in fact the user hasto implement the CellEquation only once and can henceforth reuse it in all his sta-tionary and nonstationary problems if scale and scale_ico are properly used. Thistransfers of course also to other methods like CellMatrix.



In comparison to stationary problems, we need to consider, in addition, the imple-mentation of the time-derivative, i.e., the term (vn+1, ϕ). This is done in the methodCellTimeEquation in a straight-forward way. After the initialization of v and the shapefunction phi_i and the usual loops over the quadrature points and degrees of freedomof the cell we fill the local cell vector by

l o c a l _ c e l l _ v e c t o r ( i ) += scale ∗ ( v ∗ phi_i )∗ fe_values .JxW( q_point ) ;

Here, the advantage is that DOpElib orders the terms in the time-stepping problemssuch that only (vn+1, ϕ) must be implemented.

Remark 2.4 (Nonlinear terms in the time derivative). However, if someone needsto give an explicit formula for the difference quotient this can be written using themethods

void CellTimeEquationExplicit ( . . . )

/ / implement ( v^n+1 ,\ phi ) and ( v^n,\ phi )

Such explicit statements may be useful for nonlinear terms to which time derivativesare applied as it appears for instance in fluid-structure interaction problems.

Remark 2.5 (Fractional-Step-θ-scheme). The temporal discretization in this sectionis based on the One-Step-θ-schemes. The library offers in addition an implementa-tion of the second-order and strongly A-stable Fractional-Step-θ-scheme in which eachtime-step is subdivided into three sub-steps. However, no additional implementationis needed by the user for the application of the Fractional-Step-θ-scheme.

2.3. Solving Optimization ProblemsOnce we are able to solve stationary and nonstationary PDEs we can consider opti-mization problems constrained by these PDEs. How this is done will be described inthis section.

A prototypical PDE constrained optimization problem reads:

min J(q, u)

s.t. a(q, u)(ϕ) = 0 ∀ϕ ∈ V,q− ≤ q ≤ q+,

g(q, u) ≤ 0,

where u is a function and q can either be a function or some fixed number of param-eters. the numbers q− and q+ are bounds for the control q, and g(·) is some state con-straint. To keep the presentation brief we will neglect the additional bounds

a ≤ q ≤ b, g(q, u) ≤ 0

although they can be treated by DOpElib as well. Then, in order to minimize the func-tional J one may apply the, so-called, reduced approach, in which we eliminate thedependent variable u by the solution operator S of the (stationary or nonstationary)PDE, i.e.,

a(q, S(q))(ϕ) = 0 ∀ϕ ∈ V.Thus replacing u by S(q) one is left with the problem

min j(q) = J(q, S(q)).



This can be discretized using the finite element approximation Sh of S and yields theproblem

min jh(q) = J(q, Sh(q)).

After possibly discretizing the control q as well using finite elements, one canapply any algorithm to solve the, unconstraint, minimization problem. This,will in any case require the evaluation of jh(q) which we can do, e.g., us-ing StatPDEProblem::ComputeReducedFunctional for a stationary PDE or usingInstatPDEProblem::ComputeReducedFunctional for nonstationary PDEs.

If one would like to use derivative based methods, one needs, in addition, derivativesof jh and thus of J as well as of Sh. We remark, that one can calculate the derivative ofj using adjoint calculus. Then the directional derivative of j in direction δq is given by

j′h(q)(δq) = J ′q(q, Sh(q))(δq) + (S∗hJ′u(q, Sh(q)), δq)

where the index q or u denote directional derivatives for the respective argument. Tocalculate the action of the adjoint operator S∗h we note that z = S∗hJ

′u(q, Sh(q)) can be

computed via the adjoint PDE

a′u(q, u)(ϕ, z) = J ′u(q, u)(ϕ) ∀ϕ ∈ X . (2.6)

Similarly formulas for the second derivatives can be obtained, see, e.g., [Becker et al.2007].

We define an object

template<typename PDE, typename COSTFUNCTIONAL>class OPTProblemContainer ;

that collects the user given PDE and functional descriptions and constructs the re-quired PDE and right hand side information needed for the calculations.

This means, for solving optimization problems with PDEs, the user needs to pro-vide the derivatives of the functional and the PDE in addition to the already definedfunctions CellEquation, BoundaryValue. For the above adjoint equation these are

void CellEquation_U ( . . . )

/ / implement d i re c t i ona l der ivat ive/ / o f the CellEquation w. r . t . u

and functional terms, i.e.,

void BoundaryValue_U ( . . . )

/ / implement here the der ivat ive of/ / the boundary cost funct ional w. r . t . u

Based on this classes we can now solve the optimization problem, for instance usinga Newton type method for the reduced problem, see, e.g., [Nocedal and Wright 2000].This yields an object ReducedNewtonAlgorithm which needs to be initialized with theOptProblemContainer and then provides the following method to be called by the user

ReducedNewtonAlgorithm : : Solve ( ControlVector <VECTOR>& )

where the argument provides an initial guess for the optimal control.Summarizing, we learned from the previous sections that due to the design of the

classes it is easily possible to extend any given and running code for a PDE both to the



nonstationary counterpart, if the PDE is stationary, as well as to an optimization prob-lem where the constraint is given by this PDE. Meaning that the use of our frameworkfor the simulation of PDEs will, due to the enforced interface, enable easy applicationof state-of-the-art optimization algorithms to minimization problems governed by thePDE.

2.4. Additional FeaturesFinally, we shall give a brief summary of features that are applicable (in general) to alltypes of problems. Specifically, DOpElib provides goal-oriented mesh refinement withthe help of the Dual Weighted Residual (DWR) method, see [Becker and Rannacher1996] or [Bangerth and Rannacher 2003]. Here, a given cost functional such as a pointevaluation, line integration or domain integration is considered as target quantity. Thesame routines can also be used, without any modification by the user, to use standardresidual error estimators by exchanging the error estimator class.

Since in many applications it is desirable to use different discretizations for the stateand the control DOpElib provides multi-mesh support, meaning that once a problemhas been written correctly using the same mesh for all finite element variables one canswitch to a different SpaceTimeHandler that allows different meshes for all variableswithout the need to change the user-given implementation of the PDE and functional.

3. APPLICATIONSIn this final section, we present three numerical tests which demonstrate differentfeatures of DOpElib:

— In the first numerical example, we consider goal-oriented mesh refinement with thehelp of the DWR method for the stationary Navier-Stokes equations.

— The second example presents nonstationary fluid-structure interaction. The chal-lenges for those kind of problems are the multi-domain character of the coupledproblem and the treatment of the coupling conditions. The problem is formulatedin a variational monolithically-coupled way which allows to consider goal-orientedmesh refinement and gradient-based optimization.

— In the third numerical test, an optimization problem for structural mechanics is dis-cussed.

3.1. Goal-Oriented Mesh Refinement for Navier-StokesIn this example, we consider a laminar flow around a cylinder in 2d. To be more pre-cise, we are computing the benchmark 2D-1 from [Turek and Schäfer 1996]. The com-putational domain is as depicted in Fig. 1 and the equation is discretized with theTaylor-Hood element. We want to compute the drag force on the enclosed cylinder

J(u) =1

20

∫Γcirc

ν∂nv1 − pn1, (3.1)

with the solution u = (v, p), the normal n and the viscosity ν = 0.001.To achieve an efficient computation of the quantity J , we employ goal-oriented mesh

refinement with the help of the DWR-method, see [Becker and Rannacher 1996]. Themethod delivers error indicators and by this way computational grids tailored to min-imize the error in the previously given functional J . The price we have to pay is theadditional computation of a (linear) dual problem, which is implemented as describedin Section 2.3. In Fig. 2 we see a resulting triangulation after eight refinement stepswith roughly 320 000 degrees of freedom.



Fig. 2: Locally adapted grid after eight refinement steps.

In Fig. 3 we compare the errors in the functional obtained by using global and localmesh refinement. We see clearly that the local mesh refinement allows for substantialsavings with respect to degrees of freedom.

globallocal

10−6

10−5

10−4

10−3

10−2

10−1

100

103 104 105 106

J(u−

uh)

# Degrees of FreedomFig. 3: Comparison of global and local mesh refinement with respect to the error in thedrag-functional J .

3.2. Nonstationary Fluid-Structure InteractionIn this example, a challenging benchmark FSI 2 proposed by Hron and Turek [Hronand Turek 2006] is considered. To solve this problem accurately, it is very importantthat the coupling conditions

vf = vs and σfnf = σsns,

namely, the continuity of velocities and continuity of normal stresses are satisfied ineach time-step. This is achieved with the help of a monolithic coupling scheme (strongcoupling).

The basic configuration is sketched in Fig. 1 at which an elastic beam is attachedbehind the rigid cylinder. The elastic beam has length l = 0.35m and height h = 0.02m.The right lower end is positioned at (0.6m, 0.19m), and the left end is attached to thecircle. Control points A(t) (with A(0) = (0.6, 0.2)) are fixed at the trailing edge of thestructure, measuring x- and y-deflections of the beam.

Details on parameters and evaluation functionals and other results can be found in[Bungartz and Schäfer 2006; Degroote et al. 2010; Hron and Turek 2006; Wick 2011].The Fractional-Step-θ scheme is used for time discretization with different time stepsizes k. However, the time-stepping scheme can be very easily chosen in the main.ccfunction by choosing an appropriate time-stepping scheme as previously explained.



The quantities of interest are evaluations of x- and y displacement at the pointA(0) = (0.6, 0.2) and the drag and lift forces acting on the cylinder and the elasticbeam:

(FD, FL) =

∫Sf

σf · nf ds+

∫Γi

σs · ns ds, (3.2)

where Sf denotes the path over the cylinder in the fluid part and Γi the interfacebetween the elastic beam and the fluid.

Fig. 4: FSI 2 test case: mesh (left) and velocity profile in vertical direction (right) attime t = 16.14s.

Since the problem is fully nonstationary, only a snapshot of the solution and themesh are presented in Fig. 4. By comparison of our findings in Fig. 5 with the litera-ture, it can be identified that the implementation in DOpElib is correct.

-0.03

-0.025

-0.02

-0.015

-0.01

-0.005

0

14 14.2 14.4 14.6 14.8 15

ux

Time

-0.08-0.06-0.04-0.02

0 0.02 0.04 0.06 0.08

14 14.2 14.4 14.6 14.8 15

uy

Time

120 140 160 180 200 220 240 260 280 300

14 14.2 14.4 14.6 14.8 15

Dra

g

Time

-250-200-150-100-50

0 50

100 150 200 250

14 14.2 14.4 14.6 14.8 15

Lift

Time

Fig. 5: FSI 2: The deflections of the beam, ux(A) and uy(A) (in cm), and the drag FD

and the lift FL evaluation (in kg/ms2) are displayed versus time (in s).



3.3. Compliance MinimizationIn this example, we consider the compliance minimization of a standard MBB-Beam(Messerschmidt-Bölkow-Blohm-Beam), see, e.g., [Bendsøe and Sigmund 2003]. In or-der to enforce thickness values to be either 1 or 0 we employ the, so called, SIMP-model(Solid Isotropic Material with Penalization), see as well, [Bendsøe and Sigmund 2003].

If we pick the SIMP paramter p = 1 the thickness variable is allowed to take in-termediate value apart from 0 and 1, i.e., we consider a variable thickness sheet. Thediscretization is done using Q2 elements for the displacement and discontinuous P0

elements for the thickness. A typical thickness distribution is shown in the left image

Fig. 6: Thickness distribution for the MBB-beam minimum compliance problem usingSIMP parameter p = 1 (left) and p = 4 right.

in Fig. 6. To obtain thickness values that are, mostly, either 1 or 0 we need to pick alarger value for p. The distribution given in the right image in Fig. 6 has been obtainedusing p = 4.

4. CONCLUSIONSIn this article, we described the architecture of the novel software library DOpElib forsolving PDEs and optimization problems. The key idea of the software is to supplya toolkit which allows for fast implementation of the problems at hand, but at thesame time gives the user full flexibility to change or alter the used algorithms. Thisis achieved by a unified interface to state of the art time-stepping methods, nonlinearsolvers and optimization routines. The capabilities of DOpElib are demonstrated withthe help of three examples.

ACKNOWLEDGMENTS

The DOpElib project makes use of various finite elements taken from the deal.II [Bangerth, Heister, andKanschat Bangerth et al.] finite element library which has been developed initially by W. Bangerth, R.Hartmann, and G. Kanschat [Bangerth et al. 2007]. The authors acknowledge their past experience aswell as discussions on modularization of algorithms with the authors of the libraries Gascoigne, initiatedby Malte Braack and Roland Becker [ Gascoigne] and RoDoBo, which where initiated by Roland Becker,Dominik Meidner, and Boris Vexler [ RoDoBo]. Finally, the second author thanks Mary F. Wheeler (ICES,Austin) for the possibility to finish this work.

REFERENCES

BANGERTH, W., HARTMANN, R., AND KANSCHAT, G. 2007. deal.II – a general purposeobject oriented finite element library. ACM Trans. Math. Softw. 33, 4, 24/1–24/27.

BANGERTH, W., HEISTER, T., AND KANSCHAT, G. deal.II differential equations anal-ysis library, technical reference. http://www.dealii.org.

BANGERTH, W. AND RANNACHER, R. 2003. Adaptive Finite Element Methods for Dif-ferential Equations. Birkhäuser Verlag.



BECKER, R., MEIDNER, D., AND VEXLER, B. 2007. Efficient numerical solutionof parabolic optimization problems by finite element methods. Optim. MethodsSoftw. 22, 5, 813–833.

BECKER, R. AND RANNACHER, R. 1996. A feed-back approach to error control infinite element methods: basic analysis and examples. East-West J. Numer. Math. 4,237–264.

BENDSØE, M. P. AND SIGMUND, O. 2003. Topology Optimization: Theory, Methodsand Applications. Springer.

BUNGARTZ, H.-J. AND SCHÄFER, M. 2006. Fluid-Structure Interaction: Modelling,Simulation, Optimization. Lecture Notes in Computational Science and EngineeringSeries, vol. 53. Springer.

DEGROOTE, J., HAELTERMAN, R., ANNEREL, S., BRUGGEMAN, P., AND VIEREN-DEELS, J. 2010. Performance of partitioned procedures in fluid-structure interac-tion. Comput. Struct. 88, 7–8, 446–457.

DOpElib. The differential equation and optimization environment: DOPELIB.http://www.dopelib.net.

DUNE. DUNE distributed and unified numerics environment.http://www.dune-project.org.

FEniCS. FENICS project. http://fenicsproject.org.Gascoigne. The finite element toolkit GASCOIGNE. http://www.gascoigne.de.HRON, J. AND TUREK, S. 2006. Proposal for numerical benchmarking of fluid-

structure interaction between an elastic object and laminar incompressible flow.Vol. 53. Springer-Verlag, 146 – 170.

NOCEDAL, J. AND WRIGHT, S. 2000. Numerical Optimization 2nd Ed. Springer.RoDoBo. RODOBO: A C++ library for optimization with stationary and nonstationary

PDEs. http://www.rodobo.uni-hd.de.TUREK, S. AND SCHÄFER, M. 1996. Benchmark computations of laminar flow around

cylinder. In Flow Simulation with High-Performance Computers II, E. Hirschel, Ed.Notes on Numerical Fluid Mechanics Series, vol. 52. Vieweg, 547–566.

WICK, T. 2011. Fluid-structure interactions using different mesh motion techniques.Comput. Struct. 89, 13-14, 1456–1467.

Received ??; revised ??; accepted ??


?? dopelib: differential equations and optimization ... · winnifried wollner, university of...

Documents