grid howto

7/27/2019 Grid Howto

1/75

The Distributed and Unified NumericsEnvironment (DUNE) Grid Interface HOWTO

Peter Bastian Markus Blatt Andreas Dedner

Christian Engwer Robert Klofkorn Martin Nolte

Mario Ohlberger Oliver Sander

Version 1.3svn, April 22, 2009

Abteilung Simulation groer Systeme, Universitat Stuttgart,

Universitatsstr. 38, D-70569 Stuttgart, Germany

Abteilung fur Angewandte Mathematik, Universitat Freiburg,

Hermann-Herder-Str. 10, D-79104 Freiburg, Germany

Institut fur Numerische und Angewandte Mathematik, Universitat Munster,

Einsteinstr. 62, D-48149 Munster, Germany

Institut fur Mathematik II,

Freie Universitat Berlin, Arnimallee 2-6, D-14195 Berlin, Germany

http://www.dune-project.org/
http://www.dune-project.org/http://www.dune-project.org/


2/75

2


3/75

This document gives an introduction to the Distributed and Unified Numerics Environment (DUNE).DUNE is a template library for the numerical solution of partial differential equations. It is basedon the following principles: i) Separation of data structures and algorithms by abstract interfaces, ii)

Efficient implementation of these interfaces using generic programming techniques (templates) in C++and iii) Reuse of existing finite element packages with a large body of functionality. This introductioncovers only the abstract grid interface of DUNE which is currently the most developed part. However,part of DUNE are also the Iterative Solver Template Library (ISTL, providing a large variety ofsolvers for sparse linear systems) and a flexible class hierarchy for finite element methods. These willbe described in subsequent documents. Now have fun!

Thanks to Martin Drohmann for adapting this howto to version 1.2 of the DUNE grid interface.


4/75

Contents

1 Introduction 61.1 What is DUNE anyway? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Download . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4 Code documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Getting started 9

2.1 Creating your first grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Traversing a grid A first look at the grid interface . . . . . . . . . . . . . . . . . . . . 11

3 The DUNE grid interface 163.1 Grid definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Common types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Concepts of the DUNE grid interface . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Propagation of type information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Grid implementations 21

4.1 Using different grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Using configuration information provided by configure . . . . . . . . . . . . . . . . . . . 294.3 The DGF Parser reading common macro grid files . . . . . . . . . . . . . . . . . . . . 29

5 Quadrature rules 315.1 Numerical integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Functors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Integration over a single element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Integration with global error estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 Attaching user data to a grid 366.1 Mappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2 Visualization of discrete functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.3 Cell centered finite volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.3.1 Numerical Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4


5/75

Contents

7 Adaptivity 527.1 Adaptive integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.1 Adaptive multigrid integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.1.2 Implementation of the algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.2 Adaptive cell centered finite volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8 Parallelism 648.1 DUNE Data Decomposition Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648.2 Communication Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 668.3 Parallel finite volume scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5


6/75

1 Introduction

1.1 What is DUNE anyway?

DUNE is a software framework for the numerical solution of partial differential equations with grid-based methods. It is based on the following main principles:

Separation of data structures and algorithms by abstract interfaces. This provides more function-ality with less code and also ensures maintainability and extendability of the framework.

Efficient implementation of these interfaces using generic programming techniques. Static poly-morphism allows the compiler to do more optimizations, in particular function inlining, whichin turn allows the interface to have very small functions (implemented by one or few machineinstructions) without a severe performance penalty. In essence the algorithms are parametrizedwith a particular data structure and the interface is removed at compile time. Thus the resultingcode is as efficient as if it would have been written for the special case.

Reuse of existing finite element packages with a large body of functionality. In particular thefinite element codes UG, [2], Alberta, [8], and ALU3d, [3], have been adapted to the DUNEframework. Thus, parallel and adaptive meshes with multiple element types and refinementrules are available. All these packages can be linked together in one executable.

The framework consists of a number of modules which are downloadable as separate packages. Thecurrent core modules are:

dune-common contains the basic classes used by all DUNE-modules. It provides some infrastruc-tural classes for debugging and exception handling as well as a library to handle dense matricesand vectors.

dune-grid is the most mature module and is covered in this document. It defines nonconforming,hierarchically nested, multi-element-type, parallel grids in arbitrary space dimensions. Graphicaloutput with several packages is available, e. g. file output to IBM data explorer and VTK (parallelXML format for unstructured grids). The graphics package Grape, [5] has been integrated ininteractive mode.

dune-istl Iterative Solver Template Library. Provides generic sparse matrix/vector classes

and a variety of solvers based on these classes. A special feature is the use of templates to exploitthe recursive block structure of finite element matrices at compile time. Available solvers includeKrylov methods, (block-) incomplete decompositions and aggregation-based algebraic multigrid.

Before starting to work with DUNE you might want to update your knowledge about C++ andtemplates in particular. For that you should have the bible, [9], at your desk. A good introduction,besides its age, is still the book by Barton and Nackman, [1]. The definitive guide to templateprogramming is [10]. A very useful compilation of template programming tricks with application toscientific computing is given in [11] (if you cant find it on the web, contact us).

6


7/75

1 Introduction

1.2 Download

The source code of the DUNE framework can be downloaded from the web page. To get started,it is easiest to download the latest stable version of the tarballs of dune-common, dune-grid and

dune-grid-howto. These are available on the DUNE download page:

http://www.dune-project.org/download.html

Alternatively, you can download the latest development version via anonymous SVN. For furtherinformation, please see the web page.

1.3 Installation

The official installation instructions are available on the web page

http://www.dune-project.org/doc/installation-notes.html

Obviously, we do not want to copy all this information because it might get outdated and inconsistentthen. To make this document self-contained, we describe only how to install DUNE from the tarballs.If you prefer to use the version from SVN, see the web page for further information. Moreover, weassume that you use a UNIX system. If you have the Redmond system then ask them how to installit.

In order to build the DUNE framework, you need a standards compliant C++ compiler. We testedcompiling with GNU g++ in version 3.4.1 and Intel icc, version 7.0 or 8.0.

Now extract the tarballs of dune-common, dune-grid and dune-grid-howto into a common direc-tory, say dune-home. Change to this directory and call

> d u ne - c o m mo n - 1 . 0/ b i n / d u n e c o n t r o l a l l

Replace 1.0 by the actual version number of the package you downloaded if necessary. This shouldconfigure and build all DUNE modules in dune-home with a basic configuration.

For many of the examples in this howto you need adaptive grids or the parallel features of DUNE.To use adaptive grids, you need to install one of the external grid packages which DUNE providesinterfaces for, for instance Alberta, UG and ALUGrid.

Alberta http://www.alberta-fem.de/

UG http://sit.iwr.uni-heidelberg.de/ ug/

ALUGrid http://www.mathematik.uni-freiburg.de/IAM/Research/alugrid/

To use the parallel code of DUNE, you need an implementation of the Message Passing Interface

(MPI), for example MPICH or LAM. For the DUNE build system to find these libraries, the configurescripts of the particular DUNE modules must be passed the locations of the respective installations.The dunecontrol script facilitates to pass options to the configure via a configuration file. Such aconfiguration file might look like this:

C O N F I G U R E _ F L A G S = " - - w i t h - a l u g r i d = / p a t h / t o / a l u g r i d / " \

" - - w i t h - a l b e r t a = / p a t h / t o / a l b e r t a " \

" - - w i th - u g = / p a t h / t o / u g - - e n a b le - p a r a l l el "

M A K E _ F L A G S = " - j 2 "

7
http://www.dune-project.org/download.htmlhttp://www.dune-project.org/doc/installation-notes.htmlhttp://www.alberta-fem.de/http://sit.iwr.uni-heidelberg.de/~ug/http://www.mathematik.uni-freiburg.de/IAM/Research/alugrid/http://www.mathematik.uni-freiburg.de/IAM/Research/alugrid/http://sit.iwr.uni-heidelberg.de/~ug/http://www.alberta-fem.de/http://www.dune-project.org/doc/installation-notes.htmlhttp://www.dune-project.org/download.html


8/75

1 Introduction

If this is saved under the name dunecontrol.opts, you can tell dunecontrol to cinsider the file bycalling

> d u ne - c o m mo n - 1 . 0/ b i n / d u n e c o n t r o l - - o p t s = d u n e c o n t r o l . o p t s a l l

For information on how to build and configure the respective grids, please see the DUNE web page.

1.4 Code documentation

Documentation of the files and classes in DUNE is provided in code and can be extracted using thedoxygen1 software available elsewhere. The code documentation can either be built locally on yourmachine (in html and other formats, e.g. LATEX) or its latest version is available at

http://www.dune-project.org/doc/

1.5 LicenceThe DUNE library and headers are licensed under version 2 of the GNU General Public License 2,with a special exception for linking and compiling against DUNE, the so-called runtime exception.The license is intended to be similiar to the GNU Lesser General Public License, which by itself isntsuitable for a C++ template library.

The exact wording of the exception reads as follows:

As a special exception, you may use the DUNE source files as part of a software libraryor application without restriction. Specifically, if other files instantiate templates or usemacros or inline functions from one or more of the DUNE source files, or you compile oneor more of the DUNE source files and link them with other files to produce an executable,this does not by itself cause the resulting executable to be covered by the GNU GeneralPublic License. This exception does not however invalidate any other reasons why theexecutable file might be covered by the GNU General Public License.

1http://www.stack.nl/dimitri/doxygen/2http://www.gnu.org/licenses/gpl.html

8
http://www.dune-project.org/doc/http://www.stack.nl/~dimitri/doxygen/http://www.stack.nl/~dimitri/doxygen/http://www.stack.nl/~dimitri/doxygen/http://www.gnu.org/licenses/gpl.htmlhttp://www.gnu.org/licenses/gpl.htmlhttp://www.stack.nl/~dimitri/doxygen/http://www.dune-project.org/doc/

9/75

2 Getting started

In this section we will take a quick tour through the abstract grid interface provided by DUNE. Thisshould give you an overview of the different classes before we go into the details.

2.1 Creating your first grid

Let us start with a replacement of the famous hello world program given below.

Listing 1 (File dune-grid-howto/gettingstarted.cc)

1 // $I d : g e t t i n g s t a r t e d . c c 1 98 2008 0123 1 6 : 1 2 : 4 1 Z s a n d e r $2

3 / / D une i n c l u d e s4 #include "config.h" / / f i l e c o n s t ru c t e d b y . / c o n f i g u r e s c r i p t 5 #include // l o a d s g ri d d e f i n i t io n 6 #include // d e f i n i t i on o f g r i d in f o7 #include // i n c lu d e m pi h e l p er c l a s s8

9

10 in t main( in t argc, char **argv)

11 {

12 // i n i t i a l i z e MPI, f i n a l i z e i s done a u to m at i ca l ly on e x i t 13 Dune::MPIHelper::instance(argc,argv);

14

15 // s t a r t t r y / c at ch b l o c k t o g e t e r ro r m es sa ge s f rom dune 16 tr y {

17 / / m ake a g r i d 18 c o n st i n t dim=3;

19 typedef D u ne : : S G r id < d i m , d i m > G r i d Ty p e ;

20 Dune::FieldVector < int , d im > N ( 3 ) ;

21 Dune::FieldVector L( -1.0);

22 Dune::FieldVector H(1.0);

23 G r i d Ty p e g r i d ( N ,L , H ) ;

24

25 / / p r i n t some i n f or m a ti o n a b ou t t h e g r i d 26 Dune::gridinfo(grid);

27 }

28 catch ( s td : : e x ce p ti o n & e ) {

29 s td : : c ou t < < " S TL E R RO R : " < < e . w ha t ( ) < < s td : : e nd l ;

30 return 1;

31 }

32 catch ( D u ne : : E x ce p ti o n & e ) {

33 s td : : c ou t < < " D U NE E R RO R : " < < e . w ha t ( ) < < s td : : e nd l ;

34 return 1;

35 }

36 catch ( . .. ) {

37 s td : : c ou t < < " U n kn o wn E R RO R " < < s td : : e nd l ;

38 return 1;

39 }

40

41 / / d o ne 42 return 0;

43 }

9


10/75

2 Getting started

This program is quite simple. It starts with some includes in lines 4-6. The file config.h hasbeen produced by the configure script in the applications build system. It contains the currentconfiguration and can be used to compile different versions of your code depending on the con-figuration selected. It is important that this file is included before any other DUNE header files.

The next file dune/grid/sgrid.hh includes the headers for the SGrid class which provides a specialimplementation of the DUNE grid interface with a structured mesh of arbitrary dimension. Thendune/grid/common/gridinfo.hh loads the headers of some functions which print useful informationabout a grid.

Since the dimension will be used as a template parameter in many places below we define it asa constant in line number 18. The SGrid class template takes two template parameters which arethe dimension of the grid and the dimension of the space where the grid is embedded in (its worlddimension). If the world dimension is strictly greater than the grid dimension the surplus coordinatesof each grid vertex are set to zero. For ease of writing we define in line 19 the type GridType usingthe selected value for the dimension. All identifiers of the DUNE framework are within the Dunenamespace.

Lines 20-22 prepare the arguments for the construction of an SGrid object. These arguments use theclass template FieldVector which is a vector with n components of type T. You can either assignthe same value to all components in the constructor (as is done here) or you could use operator[] toassign values to individual components. The variable N defines the number of cells or elements to beused in the respective dimension of the grid. L defines the coordinates of the lower left corner of thecube and H defines the coordinates of the upper right corner of the cube. Finally in line 23 we are nowable to instantiate the SGrid object.

The only thing we do with the grid in this little example is printing some information about it.After successfully running the executable gettingstarted you should see an output like this:

Listing 2 (Output of gettingstarted)

= > S G r id ( d i m = 3 , d i m w o rl d = 3 )

l e v el 0 c o d im [ 0 ] = 2 7 c o d im [ 1 ] = 1 0 8 c o d im [ 2 ] = 1 4 4 c o d im [ 3 ] = 6 4

l ea f c o di m [ 0 ]= 2 7 c o di m [ 1 ]= 1 08 co di m [ 2 ]= 1 44 co d im [ 3 ] =6 4

leaf dim=3 geomTypes=((cube ,3)[0]=27,(cube ,2)[1]=108,(cube ,1)[2]=144,(cube ,0)[3]=64)

The first line tells you that you are looking at an SGrid object of the given dimensions. The DUNEgrid interface supports unstructured, locally refined, logically nested grids. The coarsest grid is calledlevel-0-grid or macro grid. Elements can be individually refined into a number of smaller elements.Each element of the macro grid and all its descendents obtained from refinement form a tree structure.All elements at depth n of a refinement tree form the level-n-grid. All elements which are leafs of arefinement tree together form the so-called leaf grid. The second line of the output tells us that thisgrid object consists only of a single level (level 0) while the next line tells us that that level 0 coincidesalso with the leaf grid in this case. Each line reports about the number of grid entities which makeup the grid. We see that there are 27 elements (codimension 0), 108 faces (codimension 1), 144 edges(codimension 2) and 64 vertices (codimension 3) in the grid. The last line reports on the differenttypes of entities making up the grid. In this case all entities are of type cube.

Exercise 2.1 Try to play around with different grid sizes by assigning different values to the N pa-rameter. You can also change the dimension of the grid by varying dim. Dont be modest. Also trydimensions 4 and 5!

10

11/75

2 Getting started

Exercise 2.2 The static methods Dune::gridlevellist and Dune::gridleaflist produce a verydetailed output of the grids elements on a specified grid level. Change the code and print out thisinformation for the leaf grid or a grid on lower level. Try to understand the output.

2.2 Traversing a grid A first look at the grid interface

After looking at very first simple example we are now ready to go on to a more complicated one. Hereit is:

Listing 3 (File dune-grid-howto/traversal.cc)

1 // $I d : t r a v e r s a l . c c 2 38 2009 0309 1 6 :1 1 :1 2 Z c h r i s t i $2

3 // C/C++ in cl ud es4 #include / / f o r s t an d ar d I /O 5

6 / / D une i n c l u d e s

7 #include "config.h" / / f i l e c o n s t ru c t e d b y . / c o n f i g u r e s c r i p t 8 #include // l o a d s g ri d d e f i n i t io n 9 #include // i n c lu d e m pi h e l p er c l a s s10

11

12 // e xa mp le f o r a g e ne r ic a l go r it h m t h a t t r a v e r se s13 // t h e e n t i t i e s o f a g i ve n m esh i n v a ri o u s w ays14 template < class G >

15 void t r av e rs a l ( G & g ri d )

16 {

17 // f i r s t we e x t ra c t t he d im en si on s o f t he g r id 18 c o n st i n t d im = G : : d im e ns i on ;

19

20 // t yp e u se d f o r c o o rd i na t e s i n t h e g r i d 21 // s uc h a t y pe i s e x po r te d b y e ve ry g r i d i mp le me nt at io n 22 t y p e de f t y p e na m e G : : c t y p e c t ;

23

24 / / L ea f T r a ve r sa l 25 s t d : : c ou t < < " * * * T r a v e r s e c o di m 0 l e a v es " < < s t d : : e n d l ;

26

27 // t yp e o f t h e G ridV iew u se d f o r t r a v e r s a l 28 / / e v e r y g r i d e x p o r t s a L ea f Gr id Vi ew a nd a L e ve l Gr i dV i ew 29 t y p e de f t y p e na m e G : : L e a f G ri d V i ew L e a f G ri d V i e w ;

30

31 / / g e t t h e i n s t an c e o f t h e L ea fG ri dV ie w 32 L e a f G ri d V i e w l e a f Vi e w = g r id . l e a f V i e w ( );

33

34 // Get t h e i t e r a t o r t yp e 35 / / N ot e t h e u se o f t h e t yp en am e a nd t e m pl a t e k ey wo rd s36 t y p e de f t y p e na m e LeafGridView:: template Codim ::Iterator ElementLeafIterator ;

37

38 // i t e r a t e t hr ou gh a l l e n t i t i es o f c odim 0 a t t he l e a f s39 in t c ou nt = 0 ;

40 fo r ( E l e m e n t L ea f I t e r at o r i t = l e a f Vi e w . template begin ();

41 it!=leafView. template e nd < 0 > ( ); + + i t )

42 {

43 D u ne : : G e o m e t r y Ty p e g t = i t - > t y pe ( ) ;

44 s td : : c ou t < < " v i s it i ng l e af " < < g t

45 < < " w i t h f i rs t v e r t e x a t " < g e o m e tr y ( ) . c o r n er ( 0 )

46 < < s t d : : e nd l ;

47 count++;

48 }

49

11

12/75

2 Getting started

50 s td : : c ou t < < " t h er e a re / i s " < < c o un t < < " l ea f e le m en t ( s ) " < < s td : : e nd l ;

51

52 / / L e a f wi s e t r a v e r s a l o f c od im d im 53 s t d : : c ou t < < s t d : : e n d l ;

54 s td : : c ou t < < " * ** T r a ve r se c o di m " < < d im < < " l e av e s " < < s t d :: e n dl ;

5556 // Get t h e i t e r a t o r t yp e 57 / / N ot e t h e u se o f t h e t yp en am e a nd t e m pl a t e k ey wo rd s58 t y p e de f t y p e na m e L e a f G ri d V i e w : : template Codim

59 : : I t e r at o r V e r t e xL e a f I t er a t o r ;

60

61 // i t e r a t e t hr ou gh a l l e n t i t i e s o f c odim 0 on t h e g i v en l e v e l 62 c ou nt = 0 ;

63 fo r ( V e r t e x L e af I t e r a to r i t = l e a f Vi e w . template begin ();

64 it!=leafView. template end(); ++it)

65 {


67 s td : : c ou t < < " v i si t in g " < < g t

68 < < " a t " < g e o m e t r y ( ) . c o r ne r ( 0 )

69 < < s t d : : e nd l ;

70 count++;

71 }72 s td : : c ou t < < " t h er e a re / i s " < < c o un t < < " l ea f v e rt i ce s ( s ) "

73 < < s t d : : e nd l ;

74

75 // L e ve l wi s e t r a v e r s a l o f codim 0 76 s t d : : c ou t < < s t d : : e n d l ;

77 s t d : : c ou t < < " * * * T r a v e r s e c o di m 0 l e ve l - w i s e " < < s t d : : e n dl ;

78

79 // t yp e o f t h e G ridV iew u se d f o r t r a v e r s a l 80 / / e v e r y g r i d e x p o r t s a L ea f Gr id Vi ew a nd a L e ve l Gr i dV i ew 81 t y p e de f t y p e na m e G : : L e v e l Gr i d V ie w L e v e l Gr i d V ie w ;

82

83 // Get t h e i t e r a t o r t yp e 84 / / N ot e t h e u se o f t h e t yp en am e a nd t e m pl a t e k ey wo rd s85 t y p e de f t y p e na m e L e v e l Gr i d V i ew : : template Codim

86 : : I t e r at o r E l e m e n tL e v e l I te r a t o r ;

87

88 // i t e r a t e t hr ou gh a l l e n t i t i e s o f c odim 0 on t h e g i v en l e v e l 89 fo r ( in t l e v el = 0 ; l e ve l < = g r i d . m a x Le v e l ( ) ; l e v el + + )

90 {

91 / / g e t t h e i n s t a nc e o f t h e L ea fG ri dV ie w 92 L e v e lG r i d V ie w l e v e l Vi e w = g r id . l e v e l V i ew ( l e v e l ) ;

93

94 c ou nt = 0 ;

95 fo r ( E l e m e n t L e ve l I t e r at o r i t = l e v e lV i e w . template begin ();

96 it!=levelView. template e nd < 0 > ( ); + + i t )

97 {


99 s td : : c ou t < < " v i si t in g " < < g t

100 < < " w i t h f i rs t v e r t e x a t " < g e o m et r y ( ) . c o r n er ( 0 )

101 < < s t d : : e nd l ;

102

count++;103 }

104 s t d : : c ou t < < " t h e r e a r e / i s " < < c o u nt < < " e l e m e n t ( s ) on l e v e l "

105 < < l ev e l < < s td : : e nd l ;

106 s t d : : c ou t < < s t d : : e n d l ;

107 }

108 }

109

110


112 {

12

13/75

2 Getting started


115


118 / / m ake a g r i d 119 c o n st i n t dim=2;


121 Dune::FieldVector < int , d im > N ( 1 ) ;

122 Dune::FieldVector L( -1.0);

123 Dune::FieldVector H(1.0);

124 G r i d Ty p e g r i d ( N ,L , H ) ;

125

126 // r e f i n e a l l e le me nt s o nc e u s i ng t h e s ta nd a rd r ef i ne m en t r u l e 127 grid.globalRefine(1);

128

129 // t r a v e rs e t h e g r i d a nd p r i n t s ome i n f o130 traversal(grid);

131 }



134 return 1;135 }



138 return 1;

139 }

140 catch ( . .. ) {


142 return 1;

143 }

144

145 / / d o ne 146 return 0;

147 }

The main function near the end of the listing is pretty similar to the previous one except that we usea 2d grid for the unit square that just consists of one cell. In line 127 this cell is refined once using thestandard method of grid refinement of the implementation. Here, the cell is refined into four smallercells. The main work is done in a call to the function traversal in line 130. This function is given inlines 14-108.

The function traversal is a function template that is parameterized by a class G that is assumedto implement the DUNE grid interface. Thus, it will work on any grid available in DUNE withoutany changes. We now go into the details of this function.

The algorithm should work in any dimension so we extract the grids dimension in line 18. Next,each DUNE grid defines a type that it uses to represent positions. This type is extracted in line 22for later use.

A grid is considered to be a container of entities which are abstractions for geometric objects likevertices, edges, quadrilaterals, tetrahedra, and so on. This is very similar to the standard templatelibrary (STL), see e. g. [9], which is part of any C++ system. A key difference is, however, that thereis not just one type of entity but several. As in the STL the elements of any container can be accessedwith iterators which are generalized pointers. Again, a DUNE grid knows several different iteratorswhich provide access to the different kinds of entities and which also provide different patterns ofaccess.

13


14/75

2 Getting started

As we usually do not want to use the entire hierarchy of the grid, we first define a view on that partof the grid we are interested in. This can be a level or the leaf part of the grid. In line 29 a type for aGridView on the leaf grid is defined.

Line 36 extracts the type of an iterator from this view class. Codim is a struct within the grid class

that takes an integer template parameter specifying the codimension over which to iterate. Within theCodim structure the type Iterator is defined. Since we specified codimension 0 this iterator is used toiterate over the elements which are not refined any further, i.e. which are the leaves of the refinementtrees.

The for-loop in line 40 now visits every such element. The begin and end on the LeafGridViewclass deliver the first leaf element and one past the last leaf element. Note that the template keywordmust be used and template parameters are passed explicitely. Within the loop body in lines 42-48 theiterator it acts like a pointer to an entity of dimension dim and codimension 0. The exact type wouldbe typename G::template Codim::Entity just to mention it.

An important part of an entity is its geometrical shape and position. All geometrical information isfactored out into a sub-object that can be accessed via the geometry() method. The geometry object

is in general a mapping from a d-dimensional polyhedral reference element to w dimensional space.Here we have d = G::dimension and w = G::dimensionworld. This mapping is also called the localto global mapping. The corresponding reference element has a certain type which is extracted in line43. Since the reference elements are polyhedra they consist of a finite number of corners. The imagesof the corners under the local to global map can be accessed via the corner(int n) method. Line 44prints the geometry type and the position of the first corner of the element. Then line 47 just countsthe number of elements visited.

Suppose now that we wanted to iterate over the vertices of the leaf grid instead of the elements. Nowvertices have the codimension dim in a dim-dimensional grid and a corresponding iterator is providedby each grid class. It is extracted in line 59 for later use. The for-loop starting in line 63 is verysimilar to the first one except that it now uses the VertexLeafIterator. As you can see the different

entities can be accessed with the same methods. We will see later that codimensions 0 and dim arespecializations with an extended interface compared to all other codimensions. You can also accessthe codimensions between 0 and dim. However, currently not all implementations of the grid interfacesupport these intermediate codimensions (though this does not restrict the implementation of finiteelement methods with degrees of freedom associated to, say, faces).

Finally, we show in lines 81-107 how the hierarchic structure of the mesh can be accessed. To thatend a LevelGridView is used. It provides via an Iterator access to all entities of a given codimension(here 0) on a given grid level. The coarsest grid level (the initial macro grid) has number zero andthe number of the finest grid level is returned by the maxLevel() method of the grid. The methodsbegin() and end() on the view deliver iterators to the first and one-past-the-last entity of a givengrid level supplied as an integer argument to these methods.

The following listing shows the output of the program.

Listing 4 (Output of traversal)

* ** T r av e rs e c o di m 0 l e av e s

v i si t in g l ea f ( c ub e , 2 ) w it h f i rs t v e rt e x a t - 1 - 1

v is it in g l ea f ( cu be , 2 ) w it h f ir st v er te x a t 0 - 1

v is it in g l ea f ( cu be , 2 ) w it h f ir st v er te x a t - 1 0v is it in g l ea f ( cu be , 2 ) w it h f ir st v er te x a t 0 0

t h er e a re / i s 4 l ea f e l em e nt ( s )

14


15/75

2 Getting started

* ** T r av e rs e c o di m 2 l e av e s

v is it in g ( cu be , 0 ) a t -1 - 1v is it in g ( cu be , 0 ) a t 0 -1

v is it in g ( cu be , 0 ) a t 1 -1

v is it in g ( cu be , 0 ) a t -1 0v is it in g ( cu be , 0 ) a t 0 0v is it in g ( cu be , 0 ) a t 1 0

v is it in g ( cu be , 0 ) a t -1 1

v is it in g ( cu be , 0 ) a t 0 1

v is it in g ( cu be , 0 ) a t 1 1t h er e a re / i s 9 l ea f v e rt i ce s ( s )

* ** T r av e rs e c o di m 0 l ev el - w i s e

v i si t in g ( c ub e , 2 ) w i t h f i rs t v e rt e x a t - 1 - 1t h er e a re / i s 1 e l em e nt ( s ) o n l e ve l 0

v i si t in g ( c ub e , 2 ) w i t h f i rs t v e rt e x a t - 1 - 1v i si t in g ( c ub e , 2 ) w i t h f i rs t v e rt e x a t 0 - 1

v is it in g ( cu be , 2 ) w it h f ir st v er te x a t -1 0

v is it in g ( cu be , 2 ) w it h f ir st v er te x a t 0 0

t h er e a re / i s 4 e l em e nt ( s ) o n l e ve l 1

Remark 2.3 Define the end iterator for efficiency.

Exercise 2.4 Play with different dimensions, codimension (SGrid supports all codimenions) and re-finements.

Exercise 2.5 The method corners() of the geometry returns the number of corners of an entity.Modify the code such that the positions of all corners are printed.

15

16/75

3 The DUNE grid interface

3.1 Grid definition

There is a great variety of grids: conforming and non-conforming grids, single-element-type andmultiple-element-type grids, locally and globally refined grids, nested and non-nested grids, bisection-type grids, red-green-type grids, sparse grids and so on. In this section we describe in some detail thetype of grids that are covered by the DUNE grid interface.

Reference elementsA computational grid is a nonoverlapping subdivision of a domain Rw into elements of simple

shape. Here simple means that the element can be represented as the image of a reference elementunder a transformation. A reference element is a convex polytope, which is a bounded intersection ofa finite set of half-spaces.

Dimension and world dimensionA grid has a dimension d which is the dimensionality of its reference elements. Clearly we have d w.In the case d < w the grid discretizes a d-dimensional manifold.

Faces, entities and codimensionThe intersection of a d-dimensional convex polytope (in d-dimensional space) with a tangent planeis called a face (note that there are faces of dimensionality 0, . . . , d 1). Consequently, a face of agrid element is defined as the image of a face of its reference element under the transformation. The

elements and faces of elements of a grid are called its entities. An entity is said to be of codimensionc if it is a d c-dimensional object. Thus the elements of the grid are entities of codimension 0, facetsof an element have codimension 1, edges have codimension d 1 and vertices have codimension d.

ConformityComputational grids come in a variety of flavours: A conforming grid is one where the intersection oftwo elements is either empty or a face of each of the two elements. Grids where the intersection of twoelements may have an arbitrary shape are called nonconforming.

Element typesA simplicial grid is one where the reference elements are simplices. In a multi-element-type grid a finitenumber of different reference elements are allowed. The DUNE grid interface can represent conforming

as well as non-conforming grids.

Hierarchically nested grids, macro gridA hierarchically nested grid consists of a collection of J + 1 grids that are subdivisions of nesteddomains

= 0 1 . . . J.

Note that only 0 is required to be identical to . If 0 = 1 = . . . = J the grid is globally refined,otherwise it is locally refined. The grid that discretizes 0 is called the macro grid and its elements

16


17/75

3 TheDUNE grid interface

the macro elements. The grid for l+1 is obtained from the grid for l by possibly subdividing eachof its elements into smaller elements. Thus, each element of the macro grid and the elements that areobtained from refining it form a tree structure. The grid discretizing l with 0 l J is called thelevel-l-grid and its elements are obtained from an l-fold refinement of some macro elements.

Leaf gridDue to the nestedness of the domains we can partition the domain into

= J J1l=0

l \ l+1.

As a consequence of the hierarchical construction a computational grid discretizing can be obtainedby taking the elements of the level-J-grid plus the elements of the level-J1-grid in the region J1\Jplus the elements of the level-J 2-grid in the region J2 \ J1 and so on plus the elements of thelevel-0-grid in the region 0 \ 1. The grid resulting from this procedure is called the leaf grid because

it is formed by the leaf elements of the trees emanating at the macro elements.Refinement rulesThere is a variety of ways how to hierarchically refine a grid. The refinement is called conforming ifthe leaf grid is always a conforming grid, otherwise the refinement is called non-conforming. Note thatthe grid on each level l might be conforming while the leaf grid is not. There are also many ways howto subdivide an individual element into smaller elements. Bisection always subdivides elements intotwo smaller elements, thus the resulting data structure is a binary tree (independent of the dimensionof the grid). Bisection is sometimes called green refinement. The so-called red refinement is thesubdivision of an element into 2d smaller elements, which is most obvious for cube elements. In manypractical situation anisotropic refinement, i. e. refinement in a preferred direction, may be required.

SummaryThe DUNE grid interface is able to represent grids with the following properties:

Arbitrary dimension.

Entities of all codimensions.

Any kind of reference elements (you could define the icosahedron as a reference element if youwish).

Conforming and non-conforming grids.

Grids are always hierarchically nested.

Any type of refinement rules.

Conforming and non-conforming refinement.

Parallel, distributed grids.

17


18/75


3.2 Concepts

Generic algorithms are based on concepts. A concept is a kind of generalized class with a welldefined set of members. Imagine a function template that takes a type T as template argument. All

the members of T, i.e. methods, enumerations, data (rarely) and nested classes used by the functiontemplate form the concept. From that definition it is clear that the concept does not necessarily existas program text.

A class that implements a concept is called a model of the concept. E.g. in the standard templatelibrary (STL) the class std::vector is a model of the concept container. If all instances ofa class template are a model of a given concept we can also say that the class template is a model ofthe concept. In that sense std::vector is also a model of container.

In standard OO language a concept would be formulated as an abstract base class and all themodels would be implemented as derived classes. However, for reasons of efficiency we do not want touse dynamic polymorphism. Moreover, concepts are more powerful because the models of a conceptcan use different types, e.g. as return types of methods. As an example consider the STL where the

begin method on a vector of int returns std::vector::iterator and on a list of int it returnsstd::list::iterator which may be completely different types.

Concepts are difficult to describe when they do not exist as concrete entities (classes or class tem-plates) in a program. The STL way of specifying concepts is to describe the members X::foo() ofsome arbitrary model named X. Since this decription of the concept is not processed by the compilerit can get inconsistent and there is no way to check conformity of a model to the interface. As aconsequence, strange error messages from the compiler may be the result (well C++ compilers canalways produce strange error messages). There are two ways to improve the situation:

Engines: A class template is defined that wraps the model (which is the template parameter)and forwards all member function calls to it. In addition all the nested types and enumerationsof the model are copied into the wrapper class. The model can be seen as an engine that powersthe wrapper class, hence the name. Generic algorithms are written in terms of the wrapper class.Thus the wrapper class encapsulates the concept and it can be ensured formally by the compilerthat all members of the concept are implemented.

Barton-Nackman trick: This is a refinement of the engine approach where the models are derivedfrom the wrapper class template in addition. Thus static polymorphism is combined with atraditional class hierarchy, see [11, 1]. However, the Barton-Nackman trick gets rather involvedwhen the derived classes depend on additional template parameters and several types are relatedwith each other. That is why it is not used at all places in DUNE.

The DUNE grid interface now consists of a set of related concepts. Either the engine or the Barton-Nackman approach are used to clearly define the concepts. In order to avoid any inconsistencieswe refer as much as possible to the doxygen-generated documentation. For an overview of the gridinterface see the web page

http://www.dune-project.org/doc/doxygen/html/group Grid.html.

3.2.1 Common types

Some types in the grid interface do not depend on a specific model, i. e. they are shared by allimplementations.

18
http://www.dune-project.org/doc/doxygen/html/group__Grid.htmlhttp://www.dune-project.org/doc/doxygen/html/group__Grid.htmlhttp://www.dune-project.org/doc/doxygen/html/group__Grid.html


19/75


Dune::ReferenceElementdescribes the topology and geometry of standard entities. Any given entity of the grid can be completelyspecified by a reference element and a map from this reference element to world coordinate space.

Dune::GeometryTypedefines names for the reference elements.

Dune::CollectiveCommunicationdefines an interface to global communication operations in a portable and transparent way. In partic-ular also for sequential grids.

3.2.2 Concepts of the DUNE grid interface

In the following a short description of each concept in the DUNE grid interface is given. For the detailsclick on the link that leads you to the documentation of the corresponding wrapper class template (inthe engine sense).

GridThe grid is a container of entities that allows to access these entities and that knows the number ofits entities. You create instances of a grid class in your applications, while objects of the other classesare typically aggregated in the grid class and accessed via iterators.

GridViewThe GridView gives a view on a level or the leaf part of a grid. It provides iterators for access tothe elements of this view and a communication method for parallel computations. Alternatively, aLevelIterator of a LeafIterator can be directly accessed from a grid. These iterator types are describedbelow.

EntityThe entity class encapsulates the topological part of an entity, i.e. its hierarchical construction fromsubentities and the relation to other entities. Entities cannot be created, copied or modified by theuser. They can only be read-accessed through immutable iterators.

GeometryGeometry encapsulates the geometric part of an entity by mapping local coordinates in a referenceelement to world coordinates.

EntityPointerEntityPointer is a dereferenceable type that delivers a reference to an entity. Moreover it is immutable,i.e. the referenced entity can not be modified.

IteratorIterator is an immutable iterator that provides access to an entity. It can by incremented to visit allentities of a given codimension of a GridView. An EntityPointer is assignable from an Iterator.

IntersectionIteratorIntersectionIterator provides access to all entities of codimension 0 that have an intersection of codi-mension 1 with a given entity of codimension 0. In a conforming mesh these are the face neighbors

19
http://www.dune-project.org/doc/doxygen/html/classDune_1_1ReferenceElement.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1GeometryType.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1CollectiveCommunication.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Grid.htmlhttp://todo.dvi/http://www.dune-project.org/doc/doxygen/html/classDune_1_1Entity.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Geometry.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1EntityPointer.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Iterator.htmlhttp://www.dune-project.org/doc/doxygen/dune-grid-html/group__GIIntersectionIterator.htmlhttp://www.dune-project.org/doc/doxygen/dune-grid-html/group__GIIntersectionIterator.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Iterator.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1EntityPointer.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Geometry.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1Entity.htmlhttp://todo.dvi/http://www.dune-project.org/doc/doxygen/html/classDune_1_1Grid.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1CollectiveCommunication.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1GeometryType.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1ReferenceElement.html


20/75


of an element. For two entities with a common intersection the IntersectionIterator can be derefer-enced as an Intersection object which in turn provides information about the geometric location ofthe intersection. Furthermore this Intersection class also provides information about intersections ofan entity with the internal or external boundaries. The IntersectionIterator provides intersections

between codimension 0 entities among the same GridView.

LevelIndexSet, LeafIndexSetLevelIndexSet and LeafIndexSet which are both models of Dune::IndexSet are used to attach anykind of user-defined data to (subsets of ) entities of the grid. This data is supposed to be stored inone-dimensional arrays for reasons of efficiency. An IndexSet is usually not used directly but througha Mapper (c.f. chapter 6.1).

LocalIdSet, GlobalIdSetLocalIdSet and GlobalIdSet which are both models of Dune::IdSet are used to save user data duringa grid refinement phase and during dynamic load balancing in the parallel case. The LocalIdSet isunique for all entities on the current partition, whereas the GlobalIdSet gives a unique mapping over

all grid partitions. An IdSet is usually not used directly but through a Mapper (c.f. chapter 6.1).

3.3 Propagation of type information

The types making up one grid implementation cannot be mixed with the types making up anothergrid implementation. Say, we have two implementations of the grid interface XGrid and YGrid. Eachimplementation provides a LevelIterator class, named XLevelIterator and YLevelIterator (in fact,these are class templates because they are parametrized by the codimension and other parameters).Although these types implement the same interface they are distinct classes that are not related inany way for the compiler. As in the Standard Template Library strange error messages may occur if

you try to mix these types.In order to avoid these problems the related types of an implementation are provided as public typesby most classes of an implementation. E.g., in order to extract the XLevelIterator (for codimension0) from the XGrid class you would write

XGrid:: template Codim :: LevelIterator

Because most of the types are parametrized by certain parameters like dimension, codimension orpartition type simple typedefs (as in the STL) are not sufficient here. The types are rather placed ina struct template, named Codim here, where the template parameters of the struct are those of thetype. This concept may even be applied recursively.

20
http://www.dune-project.org/doc/doxygen/html/classDune_1_1IndexSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IdSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IdSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IdSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IdSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IndexSet.htmlhttp://www.dune-project.org/doc/doxygen/html/classDune_1_1IndexSet.html

21/75

4 Grid implementations

4.1 Using different grids

The power of DUNE is the possibility of writing one algorithm that works on a large variety of gridswith different features. In that chapter we show how the different available grid classes are instantiated.As an example we create grids for the unit cube = (0, 1)d in various dimensions d.

The different grid classes have no common interface for instantiation, they may even have differenttemplate parameters. In order make the examples below easier to write we want to have a classtemplate UnitCube that we parametrize with a type T and an integer parameter variant. T should beone of the available grid types and variant can be used to generate different grids (e. g. triangular orquadrilateral) for the same type T. The advantage of the UnitCube template is that the instantiationis hidden from the user.

The definition of the general template is as follows.

Listing 5 (File dune-grid-howto/unitcube.hh)

1 #ifndef UNITCUBE_HH

2 #define UNITCUBE_HH

3

4 #include

5 #include

6

7 / / d e f a u l t i m pl e me n ta t io n f o r any t e m pl a t e p ar am et er 8 template < typename T , in t variant >

9 class UnitCube10 {

11 public :

12 typedef T G r id T yp e ;

13

14 / / c o n s t r u c t o r t h ro w in g e x c e p t i on 15 U n i t Cu b e ( )

16 {

17 DUNE_THROW(Dune::Exception ,"nospecializationforthisgridavailable");

18 }

19

20 T & g ri d ( )

21 {

22 return grid_;

23 }

24

25 private :

26 // t h e c o ns t ru c t ed g r i d o b j e c t 27 T g r id _ ;

28 };

29

30 / / i n c l u d e b a s i c u n i t cu b e u s i ng G ri d Fa c to ry c o nc e pt 31 #include " b a s i c u n i t c u b e . h h "

32

33 // i nc l ud e s p e c i a l i z a t i o ns34 #include "unitcube_onedgrid.hh"

35 #include " u n i t c u b e _ s g r i d . h h "

21

22/75


36 #include "unitcube_yaspgrid.hh"

37 #include "unitcube_uggrid.hh"

38 #include " u n i t c u b e _ a l b e r t a g r i d . h h "

39 #include " u n i t c u b e _ a l u g r i d . h h "

40

41 #endif

Instantiation of that template results in a class that throws an exception when an object is created.

OneDGridThe following listing creates a OneDGrid object. This class has a constructor without arguments thatcreates a unit interval discretized with a single element. OneDGrid allows local mesh refinement in onespace dimension.

Listing 6 (File dune-grid-howto/unitcube onedgrid.hh)

1 #ifndef UNITCUBE_ONEDGRID_HH

2 #define UNITCUBE_ONEDGRID_HH

34 #include < d u n e / g r i d / o n e d g r i d . h h >

5

6 / / O neDGrid s p e c i a l i z a t i o n 7 template

8 class UnitCube

9 {

10 public :

11 typedef D u ne : : O n e D G r i d G r i d Ty p e ;

12

13 U n i t Cu b e ( ) : g r i d_ ( 1 , 0 . 0 , 1 . 0 )

14 {}

15

16 D u ne : : O n e D G r i d & g r i d ( )

17 {

18 return grid_;

19 }20

21 private :

22 D u ne : : O n e D G r i d g r i d_ ;

23 };

24

25 #endif

SGridThe following listing creates a SGrid object. This class template also has a constructor withoutarguments that results in a cube with a single element. SGrid supports all dimensions.

Listing 7 (File dune-grid-howto/unitcube sgrid.hh)1 #ifndef UNITCUBE_SGRID_HH

2 #define UNITCUBE_SGRID_HH

3

4 #include

5

6 // SGrid s p e c i a l i z a t i o n 7 template < in t dim>

8 class UnitCube

9 {

10 public :

22

23/75



12

13 D u ne : : S G r id < d i m , d i m > & g r id ( )

14 {

15 return grid_;

16 }17

18 private :

19 D u ne : : S G r id < d i m , d i m > g r i d_ ;

20 };

21

22 #endif

YaspGridThe following listing instantiates a YaspGrid object. The variant parameter specifies the number ofelements in each direction of the cube. In the parallel case all available processes are used and theoverlap is set to one element. Periodicity is not used.

Listing 8 (File dune-grid-howto/unitcube yaspgrid.hh)

1 #ifndef UNITCUBE_YASPGRID_HH

2 #define UNITCUBE_YASPGRID_HH

3

4 #include

5

6 / / Y asp Gri d s p e c i a l i z a t i o n 7 template < in t dim, in t size>

8 class UnitCube

9 {

10 public :

11 typedef Dune::YaspGrid GridType;

12

13 U n it C ub e ( ) : L en ( 1 .0 ) , s ( s iz e ) , p ( false ) ,

14

# if HAVE_MPI15 grid_(MPI_COMM_WORLD ,Len,s ,p,1)

16 #else

17 grid_(Len,s,p,1)

18 #endif

19 { }

20

21 D u ne : : Y a s p Gr i d < d im > & g r i d ( )

22 {

23 return grid_;

24 }

25

26 private :

27 Dune::FieldVector < double , d im > L en ;

28 Dune::FieldVector < int , d im > s ;

29 Dune::FieldVector < bool , d im > p ;

30 Dune::YaspGrid grid_;31 };

32

33 #endif

GridFactoryThe file basicunitcube.hh provides an interface class for the set-up of a unit cube in two or threedimensions with simplicial or cubic elements with help of the dune-grid class GridFactory. This class

23

24/75


hides grid specific methods for insertion of vertices and elements in the macro grid. Specializations ofthe GridFactory exist for UGGrid, AlbertaGrid and the three dimensional ALUGrid objects.

Listing 9 (File dune-grid-howto/basicunitcube.hh)

1 #ifndef BASICUNITCUBE_HH

2 #define BASICUNITCUBE_HH

3

4 #include

5

6 // d e c l a ra t i o n o f a b a s i c u n it c ub e t h a t u se s t h e G ri dF ac to ry 7 template < in t d im >

8 class BasicUnitCube;

9

10 // u n it c ub e i n tw o d im en si on s w it h 2 v a r i an t s : t r i a n g l e and r e c t a ng l e e le me nt s11 template

12 class B a s i cU n i t Cu b e < 2 >

13 {

14 protected :

15 template < class G ri d >

16 s t a ti c v o i d i n s e r tV e r t i ce s ( D u n e : : G ri d F ac t o r y < G r id > & f a c t o ry )17 {

18 Dune::FieldVector < double , 2 > p os ;

19

20 p os [ 0] = 0 ; p os [1 ] = 0 ;

21 factory.insertVertex(pos);

22

23 p os [ 0] = 1 ; p os [1 ] = 0 ;


25

26 p os [ 0] = 0 ; p os [1 ] = 1 ;


28

29 p os [ 0] = 1 ; p os [1 ] = 1 ;


31 }

32


34 s t a ti c v o i d i n s e r tS i m p l ic e s ( D u ne : : G r i d F ac t o ry < G r i d > & f a c t o ry )

35 {

36 const D u ne : : G e o m e t r y Ty p e t y p e ( D u n e : : G e o me t r y T yp e : : s i m pl e x , 2 ) ;

37 std::vector c or ne rI Ds ( 3 ) ;

38

39 c or ne rI Ds [ 0] = 0 ; c or ne rI Ds [ 1] = 1 ; c or ne rI Ds [ 2] = 2 ;

40 f a c t or y . i n s e r t E l em e n t ( t y pe , c o r n er I D s ) ;

41

42 c or ne rI Ds [ 0] = 2 ; c or ne rI Ds [ 1] = 1 ; c or ne rI Ds [ 2] = 3 ;


44 }

45


47 s t a ti c v o i d i n s e rt C u b e s ( D u ne : : G r i d F ac t o ry < G r i d > & f a c t o ry )

48 {

49 const D u ne : : G e o m e t r y Ty p e t y p e ( D u n e : : G e o m e t r y Ty p e : : c u be , 2 ) ;


51 fo r ( in t i = 0; i < 4 ; ++ i )

52 c or ne rI Ds [ i ] = i ;


54 }

55 };

56

57 / / u n i t c ub e i n 3 d i me ns io ns w i th t wo v a r i a n t s : t e t r a h ed a and h ex a he d ra 58 template

24

25/75


59 class B a s i cU n i t Cu b e < 3 >

60 {

61 protected :


63 s t a ti c v o i d i n s e r tV e r t i ce s ( D u n e : : G ri d F ac t o r y < G r id > & f a c t o ry )

64 {65 Dune::FieldVector < double , 3 > p o s ;

66

67 p os [ 0] = 0 ; p os [1 ] = 0; p os [ 2] = 0 ; f ac to ry . in se rt Ve rt ex ( po s );







74 p os [ 0] = 1 ; p os [1 ] = 1; p os [ 2] = 1 ; f ac to ry . i ns er tV er te x (p os );

75 }

76


78 s t a ti c v o i d i n s e r tS i m p l ic e s ( D u ne : : G r i d F ac t o ry < G r i d > & f a c t o ry )

79 {

80 const D u ne : : G e o m e t r y Ty p e t y p e ( D u n e : : G e o me t r y T yp e : : s i m pl e x , 3 ) ;81 std::vector c or ne rI Ds ( 4 ) ;

82

83 c or ne rI Ds [ 0] = 0 ; c or ne rI Ds [ 1] = 1 ; c or ne rI Ds [ 2] = 2 ; c or ne r ID s [ 3] = 4 ;


85



88



91



94


96 f a c t or y . i n s e r t E l em e n t ( t y pe , c o r n er I D s ) ;97 }

98


100 s t a ti c v o i d i n s e rt C u b e s ( D u ne : : G r i d F ac t o ry < G r i d > & f a c t o ry )

101 {

102 const D u ne : : G e o m e t r y Ty p e t y p e ( D u n e : : G e o m e t r y Ty p e : : c u be , 3 ) ;


104 fo r ( in t i = 0; i < 8 ; ++ i )

105 c or ne rI Ds [ i ] = i ;


107 }

108 };

109

110 #endif /BASICUNITCUBE HH/

UGGridThe following listing shows how to create UGGrid objects based on the BasicUnitCube. Two andthree-dimensional versions are available. The variant parameter can take on two values: 1 for quadri-lateral/hexahedral grids and 2 for triangular/tetrahedral grids. The initial grids are read in AmiraMeshformat.

Listing 10 (File dune-grid-howto/unitcube uggrid.hh)

25

26/75


1 #ifndef UNITCUBE_UGGRID_HH

2 #define UNITCUBE_UGGRID_HH

3

4 # if HAVE_UG

5 #include < d u n e / g r i d / u g g r i d . h h >

67 template < in t dim, in t v a ri a nt >

8 class U n it C u be < D u ne : : U G G ri d < d i m > , v a r ia n t >

9 : public B a s ic U n i tC u b e < d i m >

10 {

11 public :

12 typedef D u ne : : U G G ri d < d i m > G r i d Ty p e ;

13

14 private :

15 G r i d Ty p e * g r i d_ ;

16

17 public :

18 U n i t Cu b e ( )

19 {

20 D u ne : : G r i d F ac t o ry < G r i d Ty p e > f a c t or y ;

21 B a s i cU n i t Cu b e < d i m > :: i n s e r t V e r ti c e s ( f a c t or y ) ;

22 if ( v ar ia nt == 1 )23 B a s i cU n i t Cu b e < d i m > :: i n s e r t C u be s ( f a c to r y ) ;

24 e ls e i f( v ar ia nt = = 2 )

25 B a s i cU n i t Cu b e < d i m > :: i n s e r t S i m pl i c e s ( f a c to r y ) ;

26 else

27 D U N E _ TH R O W ( D u ne : : N o t I m p le m e nt e d , " V a r i a nt "

28 < < v a r ia n t < < " o f U G u n i t c u b e n ot i m p l e m e n te d . " ) ;

29 g r i d_ = f a c t or y . c r e a t e G r id ( ) ;

30 }

31

32 ~ U n i t C ub e ( )

33 {

34 delete grid_;

35 }

36

37 G r id T yp e & g r id ( )

38 {39 return * g r i d _ ;

40 }

41 };

42

43 #endif // #i f HAVE UG44

45 #endif

AlbertaGridThe following listing contains specializations of the UnitCube template for Alberta in two and threedimensions. When using Alberta versions less than 2.0 the DUNE framework has to be configured

with a dimension (--with-alberta-dim=2 , --with-alberta-world-dim=2 ) and only this dimensioncan then be used. The dimension from the configure run is available in the macro ALBERTA_DIM andALBERTA_WORLD_DIM in the file config.h (see next section). The variant parameter must be 1. Likein the UGGrid implementation the grid factory concept is used as the UnitCube specializations arebased on the BasicUnitCube.

Listing 11 (File dune-grid-howto/unitcube albertagrid.hh)

1 #ifndef UNITCUBE_ALBERTAGRID_HH

2 #define UNITCUBE_ALBERTAGRID_HH

26

27/75


3

4 # if HAVE_ALBERTA

5 #include

6 #include

7

8 template < in t d im >9 class U n it C u be < D u ne : : A l b e r ta G r id < d im , d i m > , 1 >

10 : public B a s ic U n i tC u b e < d i m >

11 {

12 public :

13 typedef D u ne : : A l b e r ta G r id < d im , d i m > G r i d Ty p e ;

14

15 private :

16 G r i d Ty p e * g r i d _ ;

17

18 public :

19 U n i t Cu b e ( )

20 {


22 B a s i cU n i t Cu b e < d i m > :: i n s e r t V e r ti c e s ( f a c t or y ) ;

23 B a s i cU n i t Cu b e < d i m > :: i n s e r t S i m pl i c e s ( f a c to r y ) ;

24 g r i d_ = f a c t or y . c r e a t e G r id ( " U n i t C ub e " , true );25 }

26

27 ~ U n i t C ub e ( )

28 {

29 D u ne : : G r i d F ac t o ry < G r i d Ty p e > :: d e s t r o y Gr i d ( g r i d_ ) ;

30 }

31


33 {

34 return * g r i d _ ;

35 }

36 };

37

38 #endif // #i f HAVE ALBERTA39

40 #endif

ALUGridThe next listing shows the instantiation of ALUSimplexGrid or ALUCubeGrid objects. The ALU-Grid implementation supports either simplicial grids, i.e. tetrahedral or triangular grids, and hexahe-dral grids and the element type has to be chosen at compile-time. This is done by choosing eitherALUSimplexGrid or ALUCubeGrid. The variant parameter must be 1. For three dimensional versionsthe grid objects are set up with help of the BasicUnitCube class.

Listing 12 (File dune-grid-howto/unitcube alugrid.hh)

1

#ifndef UNITCUBE_ALU3DGRID_HH2 #define UNITCUBE_ALU3DGRID_HH

3

4 # if HAVE_ALUGRID

5 #include

6 #include

7

8 / / A LU3 dGrid a nd ALU 2dGrid s i m p l e x s p e c i a l i z a t i o n .9 / / N o te : e l e me n t t y p e d e t er m in e d b y t y p e 10 template

11 class UnitCube

12 : public B a s ic U n i tC u b e < 3 >

27

28/75


13 {

14 public :

15 typedef Dune::ALUSimplexGrid GridType;

16

17 private :

18 G r id T yp e * g r id _ ;19

20 public :

21 U n i t Cu b e ( )

22 {


24 B a s i cU n i t Cu b e < 3 > :: i n s e r t V e r ti c e s ( f a c t or y ) ;

25 B a s i cU n i t Cu b e < 3 > :: i n s e r t S i m pl i c e s ( f a c to r y ) ;


27 }

28

29 ~UnitCube()

30 {

31 delete grid_;

32 }

33

34 G r id T yp e & g r id ( )35 {


37 }

38 };

39

40 / / A LU 2S im pl ex Gr id 2 d s p e c i a l i z a t i o n . N ot e : e l e me n t t y p e d e te r m in e d b y t y p e 41 template

42 class UnitCube

43 {

44 public :

45 typedef Dune::ALUSimplexGrid GridType;

46

47 U n i t Cu b e ( ) : f i l e na m e ( " g r i ds / 2 d s i m p l e x . a lu " ) , g r i d_ ( f i l e n a m e . c _ st r ( ) )

48 {}

49

50 G r id T yp e & g ri d ( )51 {

52 return grid_;

53 }

54

55 private :

56 s t d : : s t ri n g f i l e na m e ;

57 G r i d Ty p e g r i d_ ;

58 };

59

60 / / A LU3dGrid h e x ah e d ra s p e c i a l i z a t i o n . N ot e : e l em e n t t y p e d e t er m i ne d b y t y p e 61 template

62 class UnitCube

63 : public B a s ic U n i tC u b e < 3 >

64 {

65

public :66 typedef Dune::ALUCubeGrid GridType;

67

68 private :

69 G r id T yp e * g r id _ ;

70

71 public :

72 U n i t Cu b e ( )

73 {


75 B a s i cU n i t Cu b e < 3 > :: i n s e r t V e r ti c e s ( f a c t or y ) ;

28

29/75


76 B a s i cU n i t Cu b e < 3 > :: i n s e r t C u be s ( f a c to r y ) ;


78 }

79

80 ~UnitCube()

81 {82 delete grid_;

83 }

84


86 {


88 }

89 };

90 #endif

91

92 #endif

4.2 Using configuration information provided by configure

The ./configure script in the application (dune-grid-howto here) produces a file config.h thatcontains information about the configuration parameters. E.g. which of the optional grid implemen-tations is available and which dimension has been selected (if applicable). This information can thenbe used at compile-time to include header files or code that depend on optional packages.

As an example, the macro HAVE_UG can be used to compile UG-specific code as in

# if HAVE_UG

#include " d u n e / g r i d / u g g r i d . h h "

It is important that the file config.h is the first include file in your application!

4.3 The DGF Parser reading common macro grid filesDune has its own macro grid format, the Dune Grid Format. A detailed description of the DGFand how to use it can be found on the homepage of Dune under the documentation section (seeDuneGridFormatParser1).

Here we only give a short introduction. The configuration --with-grid-dim={1,2,3} must beprovided during configuration run in order to use the DGF parser. A default grid type can be cho-sen with the configuration option --with-grid-type=ALBERTAGRID . Further possible grid types areALUGRID_CUBE,ALUGRID_SIMPLEX,ALUGRID_CONFORM , ONEDGRID,SGRID,UGGRID , and YASPGRID. Notethat both values will also be changeable later. If the --with-grid-dim option was not provided duringconfiguration the DFG grid type definition will not work. Nevertheless, the grid parser will work butthe grid type has to be defined by the user and the appropriate DGF parser specialization has to beincluded. Assuming the --with-grid-dim was provided the DGF grid type definition works by firstincluding gridtype.hh.

#include

Depending on the pre-configured values of GRIDDIM and GRIDTYPE a typedef for the grid to use will beprovided by including dgfgridtype.hh. The follwoing example show how an instance of the definedgrid is generated. Given a DGF file, for example unitcube2.dgf, a grid pointer is created as follows.

1http://www.dune-project.org/doc/doxygen/dune-grid-html/group DuneGridFormatParser.html

29
http://www.dune-project.org/doc/doxygen/dune-grid-html/group__DuneGridFormatParser.htmlhttp://www.dune-project.org/doc/doxygen/dune-grid-html/group__DuneGridFormatParser.htmlhttp://www.dune-project.org/doc/doxygen/dune-grid-html/group__DuneGridFormatParser.htmlhttp://www.dune-project.org/doc/doxygen/dune-grid-html/group__DuneGridFormatParser.html

30/75


G r id P tr < G r i dT y p e > g r i d Pt r ( " u n i t c u be 2 . d g f " ) ;

The grid is accessed be dereferencing the grid pointer.

G r id T yp e & g ri d = * g r id P tr ;

To change the grid one simply has to re-compile the code using the following make command.

ma ke GR ID DI M =2 GR ID TY PE = AL BE RT AG RI D in te gr at io n

This will compile the application integration with grid type ALBERTAGRID and grid dimension 2.Note that before the re-compilation works, the corresponding object file has to be removed.

30


31/75

5 Quadrature rules

In this chapter we explore how an integral

f(x) dx

over some function f : R can be computed numerically using a DUNE grid object.

5.1 Numerical integration

Assume first the simpler task that is a reference element and that we want to compute the integralover some function f : R over the reference element:

f(x) dx.

A quadrature rule is a formula that approximates integrals of functions over a reference element .In general it has the form

f(x) dx =ni=1

f(i)wi + error.

The positions i and weight factors wi are dependent on the type of reference element and the numberof quadrature points n is related to the error.

Using the transformation formula for integrals we can now compute integrals over domains that are mapped from a reference element, i. e. = {x | x = g(x), x }, by some functiong : :

f(x) =

f(g(x))(x) dx =ni=1

f(g(i))(i)wi + error. (5.1)

Here (x) =

| det JT(x)J(x)| is the integration element and J(x) the Jacobian matrix of the map g.The integral over the whole domain requires a grid =

kk. Using (5.1) on each element we

obtain finally

f(x) dx =k

nki=1

f(gk(ki ))k(ki )w

ki +

k

errork. (5.2)

Note that each element k may in principle have its own reference element which means that quadraturepoints and weights as well as the transformation and integration element may depend on k. The totalerror is a sum of the errors on the individual elements.

In the following we show how the formula (5.2) can be realised within DUNE.

31

32/75

5 Quadrature rules

5.2 Functors

The function f is represented as a functor, i. e. a class having an operator() with appropriatearguments. A point x is represented by an object of type FieldVector where ct is the

type for each component of the vector and d is its dimension.

Listing 13 (dune-grid-howto/functors.hh) Here are some examples for functors.

1 / / a sm oo th f u n c t i o n 2 template < typename ct , in t dim>

3 class E xp {

4 public :

5 E xp ( ) { m i d p oi n t = 0 . 5; }

6 d o u bl e o p e r at o r () ( const Dune::FieldVector & x) const

7 {

8 Dune::FieldVector y(x);

9 y - = m i d p oi n t ;

10 return exp(-3.234*(y*y));

11 }

12 private :13 Dune::FieldVector midpoint;

14 };

15

16 // a f un ct i on w it h a l o c a l f e at u re 17 template < typename ct , in t dim>

18 class N e ed l e {

19 public :

20 N e e dl e ( )

21 {

22 m i dp o in t = 0 .5 ;

23 m i d p oi n t [ d im - 1 ] = 1 ;

24 }

25 d o u bl e o p e r at o r () ( const Dune::FieldVector & x) const

26 {

27 Dune::FieldVector y(x);

28 y - = m i d p oi n t ;29 return 1.0/(1E-4+y*y);

30 }

31 private :

32 Dune::FieldVector midpoint;

33 };

5.3 Integration over a single element

The function integrateentity in the following listing computes the integral over a single element ofthe mesh with a quadrature rule of given order. This relates directly to formula (5.1) above.

Listing 14 (dune-grid-howto/integrateentity.hh)1 #ifndef DUNE_INTEGRATE_ENTITY_HH

2 #define DUNE_INTEGRATE_ENTITY_HH

3

4 #include < d u n e / c o m m o n / e x c e p t i o n s . h h >

5 #include < d u n e / g r id / c o m m o n / q u a d r a tu r e r u le s . h h >

6

7 // ! com pute i n t e g r a l o f f u n ct i o n o v e r e n t i t y w i th g i ve n o rd er 8 template < class Iterator , class Functor >

9 double i n t e g ra t e e n t it y ( const I t e r at o r & i t , const F u n ct o r & f , in t p )

32

33/75

5 Quadrature rules

10 {

11 // d im en si on o f t h e e n t i t y 12 c o n st i n t d i m = I t e r at o r : : E n t i ty : : d i m e n s i on ;

13

14 // t yp e u se d f o r c o o rd i na t e s i n t h e g r i d

15 t y p e de f t y p e na m e I t e r at o r : : E n t i ty : : c t y p e c t ;16

17 / / g e t g eo me tr y t y p e 18 D u ne : : G e o m e t r y Ty p e g t = i t - > t y pe ( ) ;

19

20 // g e t q ua d ra t ur e r u l e o f o rd er p21 const Dune::QuadratureRule &

22 r u le = D u n e : : Q u ad r a t ur e R u le s < c t , d im > : : r u le ( g t , p ) ;

23

24 // e ns ur e t h at r u le ha s a t l e a s t t he r eq u es te d o rd er 25 if ( r u l e . o r d e r ( ) < p )

26 DUNE_THROW(Dune::Exception ,"ordernotavailable");

27

28 / / c o mp ut e a p p r o x im a t e i n t e g r a l 29 double result=0;

30 fo r ( typename Dune::QuadratureRule :: const_iterator i=rule. begin();

31 i ! = r u l e . e nd ( ) ; + + i )32 {

33 double f v a l = f ( i t - > g e o me t r y ( ) . g l o ba l ( i - > p o s i t io n ( ) ) ) ;

34 double w e i gh t = i - > w e i gh t ( ) ;

35 double d e t ja c = i t - > g e o m et r y ( ) . i n t e g r a ti o n E l e me n t ( i - > p o s i t io n ( ) ) ;

36 r es ul t + = f va l * w ei gh t * d et ja c ;

37 }

38

39 // r et u rn r e s u l t 40 return result;

41 }

42 #endif

Line 22 extracts a reference to a Dune::QuadratureRule from the Dune::QuadratureRules single-

ton which is a container containing quadrature rules for all the different reference element types anddifferent orders of approximation. Both classes are parametrized by dimension and the basic type usedfor the coordinate positions. Dune::QuadratureRule in turn is a container ofDune::QuadraturePointsupplying positions i and weights wi.

Line 30 shows the loop over all quadrature points in the quadrature rules. For each quadrature pointi the function value at the transformed position (line 33), the weight (line 34) and the integrationelement (line 35) are computed and summed (line 36).

5.4 Integration with global error estimation

In the listing below function uniformintegration computes the integral over the whole domain via

formula (5.2) and in addition provides an estimate of the error. This is done as follows. Let Ic be thevalue of the numerically computed integral on some grid and let If be the value of the numericallycomputed integral on a grid where each element has been refined. Then

E |If Ic| (5.3)

is an estimate for the error. If the refinement is such that every element is bisected in every coordinatedirection, the function to be integrated is sufficiently smooth and the order of the quadrature rule is

p + 1, then the error should be reduced by a factor of (1/2)p after each mesh refinement.

33

34/75

5 Quadrature rules

Listing 15 (dune-grid-howto/integration.cc)

1 // $I d : i n t e g r a t i o n . c c 2 38 2009 0309 1 6 :1 1 :1 2 Z c h r i s t i $2

3 / / D une i n c l u d e s4 #include "config.h" / / f i l e c o n s t ru c t e d b y . / c o n f i g u r e s c r i p t 5 #include // l o a d s g ri d d e f i n i t io n 6 #include // i n c lu d e m pi h e l p er c l a s s7

8 / / c h e ck s f o r d e f i n e d g r i d t y p e and i n c l u d e s a p p r o p ri a t e d g f p a r s e r i m p l em e nt a ti o n 9 #include

10

11 #include " f u n c t o r s . h h "

12 #include "integrateentity.hh"

13

14 / / ! u ni fo rm r e fi n e me n t t e s t 15 template < class Grid>

16 void u n i f o r mi n t e g r at i o n ( G r i d & g r i d )

17 {

18 // f u nc t i on t o i n t e g r a t e 19 Exp< typename Grid::ctype, Grid::dimension > f;

20

21 / / g e t G ri dV iew o n l e a f g r i d t y p e 22 t y p e de f t y p e na m e G r i d : : L e a f G ri d V i e w G r i d V i e w ;

23

24 / / g e t G ri dV ie w i n s t a n c e 25 G r i d Vi e w g r i d Vi e w = g r id . l e a f V i e w ( );

26

27 // g e t i t e r a t o r t yp e 28 t y p e de f t y p e na m e G r i d Vi e w : : template C o di m < 0 > : : I t e r at o r L e a f I te r a t o r ;

29

30 / / l o o p o v er g r i d s e qu e nc e 31 double oldvalue=1E100;

32 fo r ( in t k = 0; k < 1 0; k + +)

33 {

34 / / c om pu te i n t e g r a l w i t h s ome o r de r 35 double v al u e = 0 . 0;

36 L e a f It e r a t or e e n di t = g r i d Vi e w . template end();37 fo r ( L e a fI t er a to r i t = g r id V ie w . template b e gi n < 0 > ( ); i t ! = e e n di t ; + + i t )

38 v a l ue + = i n t e g ra t e e n t it y ( i t , f , 1 ) ;

39

40 // p r i n t r e s u l t and e r ro r e s ti m at e 41 s t d : : c ou t < < " e l e m e n t s = "

42 < < s t d : : s e t w ( 8 ) < < s t d : : r i g h t

43 < < g r i d . s iz e ( 0 )

44 < < " i n t e gr a l = "

45 < < s t d : : s c i en t i f i c < < s t d : : s e t p re c i s i on ( 1 2 )

46 < < v a l ue

47 < < " e r r or = " < < s t d : : a bs ( v a l ue - o l d v a l ue )

48 < < s t d : : e nd l ;

49

50 // s av e v al ue o f i n t e g ra l 51 oldvalue=value;

52

53 // r e f in e a l l e le me nt s54 grid.globalRefine(1);

55 }

56 }

57


59 {


62

34

35/75

5 Quadrature rules


65 u s i ng n a m e s pa c e Dune;

66

67 / / u s e u n i tc u b e f ro m g r i d s

68 s t d : : s t r i ng s t r e am d g f F i le N a m e ;69 d g fF i le N am e < < " g r id s / u n it c ub e " < < G r id T yp e : : d i me n si o n < < " . d gf " ;

70

71 / / c r e a t e g r i d p o i nt e r , Gr id Typ e i s d e f i n e d b y g r i d t y p e . h h 72 GridPtr gridPtr( dgfFileName.str () );

73

74 / / i n t e g r a t e and c om pu te e r r or w i t h e x t r a p o l a t i o n 75 u n i f o rm i n t e g ra t i o n ( * g r i d P tr ) ;

76 }



79 return 1;

80 }



83 return 1;

84 }85 catch ( . .. ) {


87 return 1;

88 }

89

90 / / d o ne 91 return 0;

92 }

Running the executable integration on a YaspGrid in two space dimensions with a qudature ruleof order two the following output is obtained:

e le me nt s = 1 i nt eg ra l = 1. 00 00 00 00 00 00 e + 00 e rr or = 1 .0 00 00 0 00 00 00 e + 10 0

e le me nt s = 4 i nt eg ra l = 6. 67 47 72 31 10 08 e - 01 e rr or = 3 .3 25 22 7 68 89 92 e - 01

e l em e nt s = 1 6 i n te g ra l = 6 . 28 3 02 7 31 1 36 6 e - 01 e rr o r = 3 .9 1 74 4 9 99 6 41 9 e - 02e l em e nt s = 6 4 i n te g ra l = 6 . 19 2 29 4 77 7 55 1 e - 01 e rr o r = 9 .0 7 32 5 3 38 1 42 6 e - 03

e l em e nt s = 2 56 i n te g ra l = 6 . 17 0 05 6 96 6 10 9 e - 01 e rr o r = 2 .2 2 37 8 1 14 4 28 5 e - 03e l em e nt s = 1 02 4 in t eg r al = 6 . 1 64 5 24 9 49 2 26 e - 0 1 e rr o r = 5 .5 3 2 01 6 88 2 08 2 e - 04

e l em e nt s = 4 09 6 in t eg r al = 6 . 1 63 1 43 6 53 1 45 e - 0 1 e rr o r = 1 .3 8 1 29 6 08 1 43 5 e - 04

e l e m en t s = 1 6 3 84 i n t e gr a l = 6 . 1 6 2 7 9 84 3 5 7 7 9 e - 0 1 e r r or = 3 . 4 5 2 1 7 3 6 6 21 3 3 e - 0 5

e l e m en t s = 6 5 5 36 i n t e gr a l = 6 . 1 6 2 7 1 21 3 8 1 0 1 e - 0 1 e r r or = 8 . 6 2 9 7 6 7 7 3 14 1 6 e - 0 6e l e m en t s = 2 6 2 14 4 i n t e g r al = 6 . 1 6 2 6 9 0 5 64 0 9 8 e - 0 1 e r r or = 2 . 1 5 7 4 0 0 3 5 66 9 5 e - 0 6

e l e m en t s = 1 0 4 8 57 6 i n t e gr a l = 6 . 1 6 2 6 8 51 7 0 6 2 3 e - 0 1 e r r or = 5 . 3 9 3 4 7 4 6 3 02 4 4 e - 0 7

e l e m en t s = 4 1 9 4 30 4 i n t e gr a l = 6 . 1 6 2 6 8 38 2 2 2 5 7 e - 0 1 e r r or = 1 . 3 4 8 3 6 6 2 4 31 0 4 e - 0 7

The ratio of the errors on two subsequent grids nicely approaches the value 1 /4 as the grid is refined.

Exercise 5.1 Try different quadrature orders. For that just change the last argument of the call to

integrateentity in line 38 in file integration.cc.

Exercise 5.2 Try different grid implementations and dimensions and compare the run-time.

Exercise 5.3 Try different integrands f and look at the development of the (estimated) error in theintegral.

35


36/75

6 Attaching user data to a grid

In most useful applications there will be the need to associate user-defined data with certain entitiesof a grid. The standard example are, of course, the degrees of freedom of a finite element function.But it could be as simple as a boolean value that indicates whether an entity has already been visitedby some algorithm or not. In this chapter we will show with some examples how arbitrary user datacan be attached to a grid.

6.1 Mappers

The general situation is that a user wants to store some arbitrary data with a subset of the entities ofa grid. Remember that entities are all the vertices, edges, faces, elements, etc., on all the levels of agrid.

An important design decision in the DUNE grid interface was that user-defined data is stored inuser space. This has a number of implications:

DUNE grid objects do not need to know anything about the user data.

grid howto

Documents