Wolfgang Bangerth

Rainer Agelek, Michael Anderson, Wolfgang Bangerth et al.

Finite element codes typically use data structures that represent unstructured meshes as collections of cells, faces, and edges, each of which require associated coordinate systems. One then needs to store how the coordinate system of each edge relates to that of neighboring cells. On the other hand, we can simplify data structures and algorithms if we can a priori orient coordinate systems in such a way that the coordinate systems on the edges follows uniquely from those on the cells \textit{by rule}. Such rules require that \textit{every} unstructured mesh allows assigning directions to edges that satisfy the convention in adjacent cells. We show that the convention chosen for unstructured quadrilateral meshes in the \texttt{deal.II} library always allows to orient meshes. It can therefore be used to make codes simpler, faster, and less bug prone. We present an algorithm that orients meshes in $O(N)$ operations. We then show that consistent orientations are not always possible for 3d hexahedral meshes. Thus, cells generally need to store the direction of adjacent edges, but our approach also allows the characterization of cases where this is not necessary. The 3d extension of our algorithm either orients edges consistently, or aborts, both within $O(N)$ steps.

Arezou Ghesmati, Wolfgang Bangerth, Bruno Turcksin

We derive a residual-based a posteriori error estimator for the conforming hp-Adaptive Finite Element Method (hp-AFEM) for the steady state Stokes problem describing the slow motion of an incompressible fluid. This error estimator is obtained by extending the idea of a posteriori error estimation for the classical $h$-version of AFEM. We also establish the reliability and efficiency of the error estimator. The proofs are based on the well-known Clement-type interpolation operator introduced in 2005 in the context of the hp-AFEM. Numerical experiments show the performance of an adaptive hp-FEM algorithm using the proposed a posteriori error estimator.

Wolfgang Bangerth

Mathematical software has traditionally been built in the form of "packages" that build on each other. A substantial fraction of these packages is written in C++ and, as a consequence, the interface of a package is described in the form of header files that downstream packages and applications can then #include. C++ has inherited this approach towards exporting interfaces from C, but the approach is clunky, unreliable, and slow. As a consequence, C++20 has introduced a "module" system in which packages explicitly export declarations and code that compilers then store in machine-readable form and that downstream users can "import" -- a system in line with what many other programming languages have used for decades. Herein, I explore how one can convert large mathematical software packages written in C++ to this system, using the deal.II finite element library with its around 800,000 lines of code as an example. I describe an approach that allows providing both header-based and module-based interfaces from the same code base, discuss the challenges one encounters, and how modules actually work in practice in a variety of technical and human metrics. The results show that with a non-trivial, but also not prohibitive effort, the conversion to modules is possible, resulting in a reduction in compile time for the converted library itself; on the other hand, for downstream projects, compile times show no clear trend. I end with thoughts about long-term strategies for converting the entire ecosystem of mathematical software over the coming years or decades.

Daniel S. Katz, Kyle E. Niemeyer, Sandra Gesing et al.

This report records and discusses the Fourth Workshop on Sustainable Software for Science: Practice and Experiences (WSSSPE4). The report includes a description of the keynote presentation of the workshop, the mission and vision statements that were drafted at the workshop and finalized shortly after it, a set of idea papers, position papers, experience papers, demos, and lightning talks, and a panel discussion. The main part of the report covers the set of working groups that formed during the meeting, and for each, discusses the participants, the objective and goal, and how the objective can be reached, along with contact information for readers who may want to join the group. Finally, we present results from a survey of the workshop attendees.