Dune Developer Meeting 2018 in Stuttgart

Date

The developer meeting is held on November 7th and 8th, 2018 in Stuttgart.

The meeting is co-located with the Dune User Meeting 2018.

Participants

  • Andreas Dedner
  • Christoph Grüninger
  • Christian Engwer
  • Robert Klöfkorn
  • Oliver Sander
  • Jorrit Fahlke
  • Claus Heine
  • Marcel Koch
  • Nils-Arne Dreier
  • Dominic Kempf
  • Bernd Flemisch
  • Birane Kane
  • Linus Seelinger
  • Steffen Müthing
  • Stephan Hilb
  • Mirco Altenberg
  • Martin Alkämper
  • Samuel Burbulla
  • Markus Blatt
  • Timo Koch

Proposed topics

Please use the edit function to add your topics or write an email to the organizers.

General

  • RK: Stability of the gitlab infrastructure. How can we help to improve it?
  • CGü: I’d like to see an hour of cleaning up. Together we scan (one or two of)
    • merge requests
    • bugs
    • the remaining open FlySpray tasks
    • Git branches

and decide which can be closed / deleted right away and which to keep.

dune-common

dune-geometry

dune-grid

  • OS: ALUGrid has been implementing some improvements to the distributed grids interface. Can we make some of the part of the official interface?

    • RK: That would be nice and should not be much work or disturbance for other grid implementations.
    • CGü: Do you have concret suggestions what to include?
  • RK: Should we add a grid implementation providing polyhedral grids?

    • CE: I’m in favor of adding a wide range of different grids to the core to improve the first shot user experience.

dune-localfunctions

dune-istl

  • RK: What is needed to make dune-istl a more self contained LA solver package?
  • CE: I’d like to finish our long standing effort of fully dynamic solver interfaces and a solver factory. There are a few smaller questions where I’d like to have some feedback from the core developers.
  • OS: The fact that FieldVector and FieldMatrix get special treatment is the source of various inconsistencies and general unhappiness. Can we review that decision? There are two competing proposals:
    • Make nesting recursion end at regular number types, rather than at FieldVector/FieldMatrix. For example, allow BCRSMatrix<double> and make it do what people would expect.
    • Introduce a dedicated new type Field<T> that should wrap number types T and that should be used to end recursions. This would mean that BCRSMatrix<FieldMatrix<double,1,1> > should be replaced by BCRSMatrix<Field<double> >.

The interesting question: Can we do that in a backward-compatible way?

Discretization modules (FEM, PDELab, …)

  • CE: can we agree on a new common discrete function interface based on dune-functions? Current state is
    • dune-functions defines interfaces for functions and global bases.
    • a couple of people are now working directly with dune-functions, without any other discretization module.
    • PDELab supports the new function interface together with “old-style” PDELab gridfunctionspaces
    • FUFEM is now mostly based on dune-functions
  • CGrä: Some comments on CE’s proposal above:
    • Notice that dune-functions localFunction(f) interface is already supported in the VTKWriter
    • When discussing the proposal please mention the subtleties of localFunction(derivative(f)) vs derivative(localFunction(f)) to avoid later surprises.

python support

  • CE: How do we envision future code development regarding python?

Protocol

User Meeting Input

  • Parallel grid construction
    • would be possible with a discussed extension of the grid interface, boundary segments will not work
  • Data I/O (HDF5 / XDMF)
    • will be a working group on second day of Dune dev meeting
  • Binary operators for dense linear algebra
    • does currently not exist because of past performance concerns
    • Oliver will provide an example implementation, Oliver thinks about which operators needs to be implemented
    • needs benchmarking (to prevent performance penalty), will be done by Jö
  • Dune packaging for spack https://github.com/spack/spack
    • users seem not to be interested
    • interesting concept, might be enough to get get Dominic working on it
  • News entries on homepage for applications to build application showcases
    • idea: new section latest publications, last three on start page with link “more” to complete list; new list ist above or below nes entries (Andreas and Robert will investigate this)
  • Periodic Boundaries
    • Yasp implements periodicity as ghost elements and requires parallel execution
    • ALUGrid and SPGrid implements that differently by identifing entities
    • Yasp does not correctly answer boundary and neightbor on periodic boundary
    • Alu and SPGrid does not transform outsideElements at periodic boundary
    • Timo and Dominic will complete the documentation

Agenda

Suggestion by Oliver: working groups

  • Documentation / website
  • Build system: WG (Steffen, Markus, Dominic, Jö, Linus)
  • Discuss new Dune paper: Thursday
  • Development Process (handling of MRs etc.)
  • Bindings for other programming languages
  • Infrastructure
  • MPI rework
  • New way of handling scalar LA entities (FieldVector<T,1>, FieldMatrix<T,1,1>) (Jö, Oliver, Claus)
  • Minimal versions of toolchain components
  • Dynamic selection of solver components in ISTL
  • I/O: WG (Steffen, Timo, Markus)
  • dune-localfunctions interface: WG (Oliver, Andreas, Christian)
  • twists and grid topology: WG (Marcel, Christian, Claus, Robert)
    • First approach: Avoiding twis problem by creating edge consistent grids -> module from Marcel.
    • Make functionality usable without dune?
    • Grids need flags: will consistency be preserved during loading/refinement/load balancing
    • Different ways of refinement (conforming/nonconforming) -> document behaviour
    • Second approach: How to handle non edge consistent grids
    • Load local dofs, for every subentity transform according to inconsistency, revert transformation before writing into global data structure
    • Transformation not always permutation: Momentums, Raviart Thomas, …
    • Local Finite Element should provide object that can provide transformation for subentity dofs
    • Special implementation if transformation only permutation or only integers in matrix
    • Local Finite Element should provide information about pullback
  • dune-functions as a foundation for discretization modules
  • parallel grid interface including parallel grid construction: WG (Robert, Markus, Linus, Oliver, Andreas, Christian, Nils)
    • communicate on Grid will return a future object, should act like std::future< void >/MPIFuture?
    • interface for repartition should be discussed based on AluGrid/UGGrid implementations
    • conclude that existing entity iterators are sufficient to compute border entity ranges
    • overlapSize and ghostSize?
    • ghost elements in ALUGrid, fix documentation
  • provide constexpr functions to gain DoF for entities etc. (Christian and Steffen extract use-cases from PDELab)

Build System

Input

  • Oliver: Alias dunecontrol cmake for dunecontrol configure
  • Build without dunecontrol
    • “Master CMake project” with subprojects for each module
    • conan.io package manager

Result from working group

  • Steffen has an aged proposal
  • if not too much work for downstream modules, adapt his approach
  • CMake features tests (e.g. searching for MPI) are only performed once
  • no longer call to module-specific test from cmake/modules/DuneMacros.cmake, they should be revised and integrated in the top-level CMakeLists.txt
  • libraries are re-exposed with CMake target mechanism
  • every dune module has a CMake target, maybe header only, pulling in all module dependency to external librarys (including dependencies between Dune modules)
  • down-stream modules, which do not have CMake feature tests, should work without breaking change (some calls should be removed or changed, but for a smooth transistion it should be possible to provide according methods for one release)
  • config.h renamed per module, e.g., dune-common-config.h
  • no longer support static and dynamic libraries
  • plan: Steffen will tidy up his prototype, further development in branches, we will discuss before merging (hopefully without breaking too much)

Website

  • Add a rotating image gallery (JavaScript anyone?)
  • (Issue #54) Grid documentation: Make it easier to find list of grid features

Miscellaneous

  • What does Entity::regular() do?
    • Nobody knows whether it’s needed
    • Remove it
  • GeometryType::GeometryType(int dim) and GeometryType::GeometryType(unsigned int dim)
    • only work for vertices and lines
    • remove
  • Improve deprecation macros to encode version
  • MPIHelper::instance() why not const ref?

Release Procedure

  • Time-Based releases
    • Requires automatic testing

I/O

  • Do we want to support generic backup / restore using GridFactory or something similar?
  • Use Python bridge for backup / restore
  • Improve backup / restore documentation

dune-localfunctions interface

Result from working group - dynamic interface has a lot of flaws and few users - run-time interface uses type erasure - infrastructure for type erasure exists in parts in dune-functions - create merge request for dune-localfunctions - deprecate dynamic interface

  • issues with interpolate, no consensus

  • provide a way to get points of degree of freedom for local subentity

  • currently discretization modules remap local keys anyway, but should be kept

Future of GitLab infrastructure

  • People taking care of GitLab might leave academia in summer 2019
  • Migrate to GitLab Cloud, downsides are Git commit hooks, less control
  • current server issues are resolved

extend Dune grid interface

  • methods from ALUGrid that would be beneficial for all
  • parallel grid creation

    • UG should implement them, too (Oliver Sander thinks it could be done)
    • two methods insertVertex and insertProcessBorder
    • change accepted, waiting for merge request
  • rebalance grid partition

    • method repartition
    • just discussion, no decision

unify grid readers

  • dune-grid issue 23, dune-grid merge request 90
  • readImp should have a second form accepting an input stream
  • return parameters for element/boundary data should be unified
  • Maybe use an object instead of static methods, maybe this object should behave more like a grid factory

output of matrices and vectors

  • need a simple interface to output matrices and vertices
  • Linus will propose a merge request

asynchron MPI

  • dune-common merge request 526
  • introduce asynchronous MPI features like future
  • data abstraction for communicate and serialization
  • comments in MR

result of I/O group

General formats?

  • DGF (simple data), Gmsh (simple data), …
  • VTK (visual + simple data)
  • XDMF/HDF5 (visual + complex data)

Check-pointing

  • use backup-restore facility (does it get a stream?)
  • check-pointing is specialized for each user/discretization module
  • exadune has a prototype for serializing a DG simulation in HDF5
  • dune-pdelab has an implementation, dune-fem has an implementation for restart
  • generalized interface in dune is generally wishful, but should we invest the time? and who?
  • Checkpointing: dune-fem/dumux/pdelab have their own solutions. Should we invest work to clean those up and have something in the core modules?

HDF5

  • dune-hdf5
  • put all implementations in an experimental folder
  • improve HDF CMake check
  • leightweight HDF5 C++ Wrapper
  • HDF for dumping grid and data for visualization
  • XDMFWriter optionally gets HDF5Writer from outside

Vtk

  • VtkWriter double precision -> try runtime penalty for if/else for every field (runtime) (-> Timo)
    • VtkWriter gets outputFieldType for grid (default to float)
    • every function gets field type in FieldInfo (default to float)
    • otherwise template argument for Writer and every field
  • deprecate old VtkFunction
  • set counter bei sequence writer (-> Bernd)
    • setting the vector of time steps from outside might be what this actually means
    • should be suitable for restart

Reader

  • Reader should have a corresponding writer and the other way around with hopefully high number of matching features
  • Sequential reader interface, reads on process 0, distributes (-> Dumux team)
    • Supports different grid managers (depending on what the format gives us, e.g. structured/unstructured)
    • gives out unique_ptr
    • gives out data (codim-dim codim-0 boundaries) as std::vectorstd::vector<FieldType>
    • provides mappings (in case of resorting), grid factory?
    • can do load-balacing of data
Creative Commons License   |  Legal Statements / Impressum  |  generated with Hugo v0.30.2 (Jan 22, 23:19, 2019)