Core modules

Before diving into grid tutorials, it helps to understand how DUNE is organized.

Learning goals

After this page, you should be able to:

• explain why DUNE is split into modules,
• identify the role of each core module,
• understand how the modules combine in a typical workflow.

Why modules?

DUNE is split into modules so you can combine only what you need:

• small core dependencies for basic workflows,
• optional higher-level modules for specific discretizations,
• extension modules for special grids, I/O, and application domains.

This keeps projects flexible and avoids a monolithic framework structure.

Core module roles

In this tutorial we start with the five core modules:

• dune-common: infrastructure, utilities, configuration, and base abstractions.
• dune-geometry: reference elements and geometry mappings.
• dune-grid: grid interface and concrete grid implementations.
• dune-localfunctions: local shape functions and basis-related local tools.
• dune-istl: iterative solvers, sparse linear algebra, and preconditioners.

How they fit together

A typical first workflow looks like:

1. create or load a grid (dune-grid),
2. iterate entities and access geometry (dune-grid + dune-geometry),
3. define local finite element ingredients (dune-localfunctions),
4. assemble and solve linear systems (dune-istl),
5. use common infrastructure throughout (dune-common).

What comes next

After this core layer, you can move to higher-level modules such as:

• dune-functions / dune-assembler for modern assembly workflows,
• dune-fem (including Python paths) for rapid model development,
• extension modules for grid managers, mesh I/O, and specialized transformations.

The next pages start with grid concepts because they are the central entry point to most DUNE-based PDE codes.

Summary and next steps

You now have the module-level map of DUNE and the role of the five core modules. Continue with Grid Basics to start working with concrete grids and grid views.