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.

Participants

TBD

Proposed topics

general

  • 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>.

dune-localfunctions

dune-istl

  • SO: Discussion on an improved implmentation of the block sparse matrix format: IBCRSMatrix.
Creative Commons License   |  Legal Statements / Impressum  |  Hosted by TU Dresden & Uni Heidelberg  |  generated with Hugo v0.131.0 (Jul 27, 22:23, 2026)