DUNE

DUNE -> (Distributed) & Unified Numerics Environment

• opensource

• solving grid - based . numerical sol’n of

• PDE’s

• Distributed Means Distributed development + Distributed computing.

• Flexible + efficient

Main goal:- well defined interfaces for the various Components of a PDE solver.
All the components of DUNE are exchangable.
=> you can use different grids , methods in same problem by just changing a small part & not
the whole code.
Design principles of DUNE :-
1. Separate storage (data structures) from operations (algos), connect them
through abstract interfaces, and allow multiple optimized implementations of
same data type.

• Says to create abstract interfaces for data structures & let algorithms work with those
data structures interfaces.

• Any grid must be able to give its element, vertex, neighbors.

• algorithms dont care what grid structure is, it calls the interface & reviews the info.

Why
(a) Flexibility: you can swap implementations without touching algo.
(b) reuse samecode also for other grids
(c) optimization of solving
2. Dune uses C++ templates so that choice of grid, solver, or data type is decided
at compile time, not at runtime. This avoids performance penalty of virtual
functions, making framework both flexible & fast.
virtual fns:
 
struct Grid {
virtual void refine () = 0;
};

void run ( Grid * g ) {

g - > refine () ;
}
 

• run doesnt know what type of grid g is (Yasp or UG.)

1
• So program keeps a table (vtable) of function pointers

• At run time it looks up the table & sees correct function. This takes time.

Why use templates over virtual functions?

 

struct Grid {
virtual void refine () = 0;
};

struct YaspGrid : Grid {

void refine () override { /* ... */ }
};

void doRefine ( Grid * g ) {

g - > refine () ; // It searches for which refine to use
}
 

Runtime-dispatch flow for a virtual call (how doRefine resolves g->refine())

Start:
Call doRefine(Grid* g)

Object g is YaspGrid but compiler only knows type is Grid

Read hidden vptr from object

Look up slot for “refine” in the vtable

(array of function pointers)

Fetch function pointer (address of YaspGrid::refine) and invoke it

While Using Templates:

 

tmeplate < typename GridType >

void doRefine ( GridType & g ) {
g . refine () ; // This is resolved at compile time
}

Yasgrid yg ;
dorefine ( yg ) ; // compile knows grid type is YaspGrid
 

2
 Runtime-Dispatch Flow for Template

Compile time Begins

Compiler sees Grid type=Yasp Grid

Generates code
void d o R e f i n e ( GridType &g ) {
g . r e f i n e ( ) ; // This i s r e s o l v e d a t c o m p i l e time
}

Compile time ends/Run time Begin

DoRefine called with yg

Direct Call (or inlined) to

YaspGrid::refine()

Execute
YaspGrid::refine()

End of flow

3. Use Legacy Codes Dont rewrite them Again

Modular Design Dune has seperate modules with clear dependance. Each module has one specific
job. There is a well-defined order for these modules. Lower-level modules (like dune-common,
dune-geometry) provide building blocks, while higher-level modules (like dune-grid, dune-istl)
depend on these building blocks.
Why?

• No circular dependencies

• Easy maintenance

• Flexibility

1 Dune Ecosystem
The modular structure of DUNE is implemented by conceptually splitting code into separate,
independent libraries. It organizes something as a set of independent, self-contained parts (or
"modules") that can also work together but are also decoupled.

3
Dune modules ̸= C++ modules
Dune Modules Can be maintained independently of official DUNE infrastructure

Build scripts:
A set of instructions that tell the computer how to compile & link a program.
For small programs (up to 50 lines) g++ [Link] -o program is enough.
Else you need to make a makefile.

Core modules:

• DUNE-COMMON

• DUNE-GEOMETRY

• DUNE-GRID

• DUNE-ISTL

• DUNE-DOALFUNCTIONS

DUNE - Common
• It’s a tool that every other module depends on.

What it Provides
• Build scripts: Create infrastructure so all modules can be built in the same way.

• Basic modules like logging, type traits, exception handling.

• Logging: Tools for outputting runtime messages (info, warnings, errors).

• Type traits: Template-based utilities.

• Exception handling: Standardized method for throwing and capturing errors.

• Dense Linear Algebra Vectors and Matrices

• Dense linear algebra vectors and matrices are stored in contiguous arrays. These are not
sparse matrices, most entries are non-zero.

• They only store data that represents small systems or temporary workspace objects, such as:

• Geometry data (e.g., coordinates, transformations, etc.).

• Storage of global data for finite element shape functions.

• Operations on reference data, transformations, and local configurations.

• These matrices are used several million times in calculations.

4
 Dense vs Sparse Matrices

Property Dense Sparse

Storage All entries Only non-zero entries
Use Case Local Tasks, geometry Global system matrices
Efficiency Maximizes computation, requires small operations Minimizes memory usage for large system
Size 1000s x 1000s (typically) millions of DOFs (rarely full)
Math Tiny local element level math Huge system level solver Math

Dune Geometry
What is it?
• Math of element shapes.

What it Provides
• Reference elements (unit cube, unit traingle, etc.).

• Element transformations: Mapping from simple reference element to actual grid element
in domain.

• Quadrature rules: Approximating integrals over elements like

R
f (x) dx

Why?
• PDE solvers need to integrate functions over elements and transform them onto the reference.

Dune Grid
What is it?
• The heart of Dune, it’s an abstract grid interface.

What it Provides
• As it’s abstract, it can work with any dimension (e.g., 1D, 2D, 3D, etc.).

• Various element types (e.g., unit square, unit cube, tetrahedron, etc.).

• Q)But these are already provided in Dune Geometry.

• Ans)Dune Geometry works on reference elements (shapes like unit square, unit cube).Its
like knowing mathematical shape and how to integrate it

Why is it Useful?
• Dune grid works on actual computational grids (mesh that covers your physical domain). It
uses Dune Geometry internally for element geometry. It has info of what each grid cell is (a
"rectangle," etc.).

• It manages useful mesh nodes of many elements and knows where each element is and how to
connects.