edit

Dune Developer Meeting 2026

Date and Location

The developer meeting is held on 29.09-01.10, 2026 at the Technische Universität Dresden.

Building Z21
Zellescher Weg 25, 01217 Dresden
Level 2, Room 250

See Campus-Navigator and Maps. If you arrive early or the room 250 is still locked, you can wait in the break room 239.

Participants

  • Christoph (Tuesday noon - Thursday early afternoon)
  • Robert
  • Simon

Program

Day and Time Location Topic
09/28 19:00 Bierstube get together
09/29 09:30 Z21/250 Session 1
09/29 12:00 Mensa Siedepunkt Lunch
09/29 13:00 Z21/250 Session 2
09/29 16:00 Z21/250 Coffee break
09/29 16:30 Z21/250 Session 3
09/29 19:30 Bautzner Tor Dinner
09/30 09:30 Z21/250 Session 4
09/30 12:00 Mensa Siedepunkt Lunch
09/30 13:00 Z21/250 Session 5
09/30 16:00 Z21/250 Coffee break
09/30 16:30 Z21/250 Session 6
09/30 19:30 Matjo BBQ & HotPot Dinner
10/01 09:30 Z21/250 Session 7
10/01 12:00 Mensa Siedepunkt Lunch

Proposed topics

general

  • RK: DUNE project perspectives

    • What do we want to achieve in the near and far future with this project?
    • maintenance and where to host our stuff
    • relevance, see comment below.

  • RK: Next meeting: Where? When? Lets decide this during this meeting.

  • RK: Interoperability

    • of discretization modules. Where are we on this today?
    • with other projects

  • CGü: Update minimum required versions

    • Python
    • GCC
    • Clang
    • CMake: at least 3.22, from now 3.16

  • SP: Packaging infrastructure of dune (various implementations: spack, pip, vcpkg, easybuild, debian; little overlap, python integration; dunecontrol redesign; duneproject update)

    • Mailing list discussion:
      • Existing efforts: Debian, OpenSuse, PyPi, Spack (spack/dune-spack), EasyBuild (dune-easybuild), vcpkg (vcpkg-ports)
      • Proposal for central GitLab group for packaging recipes (packaging/ or pkg/)
      • Common patterns: naming, versioning (e.g., year-based instead of 2.x.x), module separation, Python bindings integration
      • Automation: generate Spack/EasyBuild recipes from PyPi packages; EasyBuild 2.8/2.9 exists but maintenance is difficult
      • PyPi packaging automated on GitHub due to GitLab CI restrictions
      • Integrate packaging into release pipeline and system tests
      • Consider Common Package Specification (CPS) for future compatibility
    • Open Issues and Merge-Requests:

  • SP: Tutorials/Examples for dune (how to get started with the various modules? simple problems solved with the core modules; developer documentation: e.g. how to write python bindings; what is the focus of the discretization modules: differences/similarities/design - this is more about improving the content of the documentation, not about the technical aspect of the documentation provider; can we use AI tools to improve the documentation; can we get some inspiration by other frameworks)

  • SP: Community: My impression is that dune community is dying out. What can we do against this? GSoC redesign, Master/PhD projects, tasks for young students, early developers to contribute, merchandising (what happened to the new dune logo design?), Maybe we can apply for a DFG funded project or research group together? What about the software-infrastructure funding?

    • Dune logo redesign discussed in 2017 dev meeting; current logo is >20y old, need modern design not just high-res/rectangular version!
    • GSoC 2025: More creative topics and detailed project descriptions, but application not accepted by Google. Why? What was missing? Why are other projects accepted instead?
    • DFG research software infrastructure funding program was considered but no action taken

  • SP: Publication of dune papers: release notes as zenodo publication or in Journal of Numerical Mathematics? Citation recommendations in each dune module, better visibility of publications - each module should be citeable somehow.

    • Dune 2.10 release notes paper rejected/needs major rewrite after ~1 year delay; journal scope mismatch not communicated early
    • Release notes become outdated quickly due to long review cycles; alternative venues: arXiv, technical reports, or JNMA (published Deal.II release papers in similar format)
    • Strong proposal: Use Zenodo for each release (used by FEniCS, MFEM, Gridap, ngsolve, DuMux, AMDiS)
      • Low effort, no review delay, provides DOI for each version and combined versions
      • Can combine paper and software, link DOIs bidirectionally
      • Create a “Dune” Zenodo community to centralize publications
    • Need consistent future strategy:
      • Publish release notes for each version via Zenodo?
      • Write a general overview paper every ~5 years covering multiple versions
      • Ask JNMA editorial board if release notes papers are welcome
      • Update the 2.10 paper for the next release if pursuing journal publication

dune-common

  • SP: Tensor data structures in dune-common (self-developed, e.g., based on dune-tensor, or external library, e.g. Blaze-lib, Eigen, kokkos…)
    • Discussion:
      • We see the need for tensor generalizations of FieldVector/FieldMatrix
      • Infrastructure based on (backported) std::mdspan provided - Needs an enrichted interface
      • Experimental development in user module dune-tensor, includes test-suite, benchmarks, extensions in several directions, generalization to sparse tensors…
      • We need a discussion to the envisioned interface and implementation pattern.
      • Alternatively: Choose to include an external tensor library already in dune-common (maybe with own interface on top)
    • Open Issues and Merge-Requests:
  • SP: Threading and GPU parallelization (link dependency to TBB is annoying, thread-safety guarantees, GPU-based linear solvers, assemblers?)
  • SO: [hands-on session]: Fix add_*_falgs(...) CMake functions to handle variables in global properties so that super builds can handle them correctly.
  • PB: Redesign of parallel index sets.

dune-grid

  • SO: Missing geometry information. If the grid has more than one geometry type per codimensoin, the information of indexSet().subIndex(...) is useless as one cannot know for which of the index sets the returned index belongs to. This is specially bad if a grid does not provide entities, for which the subentity indices are only accessible through this interface.
  • SO: Generic code when there is no reference element. A lot of code relies on the assumption that there exist a reference element, however, several implementations may actualy return a GeometryType::none, for which there is no reference element. Do we perhaps need a capability that give us the guarantee that every entity of the grid has a reference element? For instance Capabilities::alwaysHaveReferenceElements<GridView,Codim>.
  • RK: dune-grid!782: sequence counter for grids
  • RK: dune-grid!771: user data pointers on grids
  • RK: dune-grid#193: grid method size with PartitionType
  • RK: dune-grid#194: backward communication optional

dune-localfunctions

dune-istl

  • SO: Discussion on an improved implmentation of the block sparse matrix format: IBCRSMatrix.
  • RK: dune-istl-GPU?
Creative Commons License   |  Legal Statements / Impressum  |  Hosted by TU Dresden & Uni Heidelberg  |  generated with Hugo v0.131.0 (Sep 26, 16:40, 2026)