%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Overview}
-\dealii{} version 9.4.0 was released June TODO, 2022.
+\dealii{} version 9.4.0 was released June 10, 2022.
This paper provides an
overview of the new features of this release and serves as a citable
reference for the \dealii{} software library version 9.4. \dealii{} is an
\item Advances in multigrid infrastructure (see Section~\ref{sec:multigrid});
\item CutFEM support (see Section~\ref{sec:cut});
\item Performance improvement of particle infrastructure (see Section~\ref{sec:particles});
- \item Two new tutorial programs and a new code gallery program (see Section~\ref{subsec:steps}).
+ \item Two new tutorial programs (see Section~\ref{subsec:steps}).
\end{itemize}
%
While all of these major changes are discussed in detail in
Section~\ref{sec:major}, there
-are a number of other noteworthy changes in the current \dealii{} release
-that we briefly outline in the remainder of this section:
+are a number of other noteworthy changes in the current \dealii{} release,
+which we briefly outline in the remainder of this section:
%
\begin{itemize}
% \item \texttt{AffineConstraints::make\_consistent\_in\_parallel()} allows
% to make constraints consistent in parallel.
- \item \texttt{DataOutResample} does not output a numerical solution
- on the cells of the original triangulation but interpolates the result
- onto a second triangulation (that can be completely unrelated).
+ \item The \texttt{DataOutResample} class does not output a numerical solution
+ on the cells of the original triangulation, but interpolates the result
+ onto a second triangulation (which can be completely unrelated).
By using this class, one can output the result obtained on an
unstructured mesh on a structured one, which might be a more
memory-efficient storage format, or one can create a slice in 3D.
\item The new function \texttt{find\_point\_owner\_rank()} of \texttt{parallel::distributed::Triangulation} allows to find the MPI
rank of the subdomain of a distributed mesh that contains a given point.
- It is communication-free, leverages the functionality of p4est (>v.2.2),
- and its algorithm is described in \cite{burstedde2020parallel}. Based on the obtained information,
- communication pattern in \texttt{Utilties::MPI::RemotePointEvaluation} can be set up efficiently. Furthermore, this feature could be used in the future to allow
- particle simulations, where particle movement is not
+ It is communication-free and leverages the functionality of p4est (>v.2.2).
+ Its algorithm is described in \cite{burstedde2020parallel}. Based on the information obtained,
+ communication pattern in \texttt{Utilties::MPI::RemotePointEvaluation} can be set up efficiently. Furthermore, this function could be used in the future to allow
+ particle simulations where particle movement is not
limited by CFL conditions, as done in \cite{mirzadeh2016parallel}.
\end{itemize}
%
\section{Major changes to the library}
\label{sec:major}
-This release of \dealii{} contains a number of large and significant changes
-that will be discussed in this section.
-It of course also contains a
+This release of \dealii{} contains a number of large and significant changes,
+which will be discussed in this section.
+It of course also includes a
vast number of smaller changes and added functionality; the details of these
can be found
\href{https://dealii.org/developer/doxygen/deal.II/changes_between_9_3_0_and_9_4_0.html}
We continued to work on the simplex- and mixed-mesh support. We fixed
many bugs and generalized existing functions that only worked for
-hypercube shaped cells. Most notable new functions are:
+hypercube-shaped cells. The most notable new functions are:
\begin{figure}[!t]
\end{tikzpicture}
\caption{New refinement strategies for triangles and tetrahedrons: triangles
- are subdivided in 4 children and tetrahedrons 8 ones.}\label{fig:refinement}
+ are subdivided in 4 children and tetrahedrons in 8 ones.}\label{fig:refinement}
\end{figure}
\begin{itemize}
\item Experimental support of locally refined meshes. FEM on locally refined
meshes requires 1) the possibility to locally refine the mesh (see Figure~\ref{fig:refinement})
-and 2) appropriate hanging-node constraints. For 3D, we are in progress to
-implement the missing constraint definitions.
+and 2) appropriate hanging-node constraints. For 3D, the implementation of the missing constraint definitions is in progress.
\item TODO
\end{itemize}
-Furthermore, we continued to remove the usage of \texttt{GeometryInfo} from
-the library and to replace the instances by more general equivalent functions, which
-in many cases rely of \texttt{ReferenceCell}. Once all instance of
-\texttt{GeometryInfo} are remove, we will deprecate the class.
+Furthermore, we continued to remove the instance of usage of the \texttt{GeometryInfo} class from
+the library and to replace them by more general equivalent functions, which
+rely on \texttt{ReferenceCell} in many cases. Once all instances of
+\texttt{GeometryInfo} are removed, we will deprecate the class.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Repartitioning of distributed meshes}\label{sec:repartitioning}
-Until now, distributed meshes were either partitioned statically (\texttt{parallel::\allowbreak fullydistributed::\allowbreak Triangulation}; short \texttt{p::f::T}) or used a
+Until now, distributed meshes were either partitioned statically (\texttt{parallel::\allowbreak fullydistributed::\allowbreak Triangulation}; short \texttt{p::f::T}) or they used a
fixed policy to partition the cells among processes
-(\texttt{parallel::\allowbreak distributed::\allowbreak Triangulation}; short \texttt{p::d::T}). For latter, we
-use a Morton-order as the backend of that class---\texttt{p4est}---does. Fixed Morton-order
+(\texttt{parallel::\allowbreak distributed::\allowbreak Triangulation}; short \texttt{p::d::T}). For the latter, we
+use the Morton-order as the backend of \texttt{p::d::T}---\texttt{p4est}---does. A fixed Morton-order
might provide very good performance in terms in communication and
setup costs, but might be non-optimal when interfacing with other
-libraries that have fixed partitioning, most notably a Cartesian
+libraries that have fixed partitioning, e.g., a Cartesian
partitioning, themselves.
-New utility functions from the \texttt{RepartitioningPolicyTools} can be
-used now to create a new \texttt{p::f::T} instances,
+New utility functions from the \texttt{RepartitioningPolicyTools} namepace can be
+used now to create a new \texttt{p::f::T} instance,
given a distributed triangulation (\texttt{p::f::T} or \texttt{p::d::T}) and a vector with the new owners of locally
owned cells. The workflow is shown in the following listing:
\begin{c++}
tria_pft.create_triangulation(construction_data);
\end{c++}
Instead of using one of the predefined partitioning policies, users
-can write their own by implementing the \texttt{RepartitioningPolicyTools::Base} interface. Similarly to the
+can write their own ones by implementing the \texttt{RepartitioningPolicyTools::Base} interface. Similarly to the
active level, also the multigrid levels can be repartitioned arbitrarily.
\begin{figure}
\centering
\def\svgwidth{0.8\columnwidth}
\input{svg/repartitioning.pdf_tex}
- \caption{Visualization of the repartitioning process: after
- cells are assigned new ranks, each process collect sends the cells incl.
- ghost cells to the new owner. There incoming cells are processed, duplicates
- are removed and the local part of the triangulation is built.}\label{fig:repartitioning}
+ \caption{Visualization of the repartitioning process: after new ranks
+ are assigned to cells, each process collects and sends the cells, incl.
+ ghost cells, to the new owner. There, incoming cells are processed, duplicates
+ are removed, and the local part of the triangulation is built.}\label{fig:repartitioning}
\end{figure}
-The setup process is visualized in Figure~\ref{fig:repartitioning}. First cells, incl. their
-surrounding (ghost) cells and their parent cells, are collected and
+The setup process is visualized in Figure~\ref{fig:repartitioning}. At first, cells, incl. their
+surrounding (ghost) cells and parent cells, are collected and
sent to the new owner. On the
-receiving side, the set of all cells are combined and possible duplicates
+receiving side, the sets of all cells are combined and possible duplicates
are removed. This information is enough to construct a new triangulation.
For sending/receiving, we apply consensus-based algorithms~\cite{hoefler2010scalable}, which
-we introduced in the library in release 9.2~\cite{dealII92}. Consensus-based
+we introduced into the library in release 9.2~\cite{dealII92}. Consensus-based
algorithms are used also in \cite{ibanez2016pumi} for repartitioning.
In future releases, we plan to add support for repartitioning based on distributed graph
-partitioning libraries, e.g., \texttt{ParMETIS} of \texttt{Zotan}. Furthermore, we intend to extend the
+partitioning libraries, e.g., \texttt{ParMETIS} or \texttt{Zoltan}. Furthermore, we intend to extend
\texttt{p::f::T} with adaptivity support.
-With this and and the new repartitionging features, \texttt{p::f::T}
-could be selfconsistent like \texttt{p::d::T}, which is an important
+With this support and and the new repartitioning features, \texttt{p::f::T}
+could be self-consistent like \texttt{p::d::T}, which is an important
step towards the support of AMR also for distributed simplex and mixed meshes
(see also Subsection~\ref{sec:simplex}).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Advances in matrix-free infrastructure}\label{sec:mf}
-In the matrix-free infrastructure, we have added many new features. Most
-notably:
+In the matrix-free infrastructure, we have added a number of new features. The most
+notable ones are:
\begin{itemize}
-\item Improved support of Hessians: just like values and gradients can be
-evaluated and integrated during matrix-free loops, one can do this now
-also for Hessians both for cells and faces. This enables, e.g., to write
+\item Improved support of Hessians: just like values and gradients, Hessians can be
+now evaluated and integrated during matrix-free loops
+both for cells and faces. This enables, e.g., to write
a matrix-free version of step-47, which solves the biharmonic equation with DG.
-\item Cell-centric loops now also allow to access to gradients and Hessians
-of neighboring cells on faces. The major obstacle here was to reorientation
-of theses in the case of arbitrary orientated cells on unstructured meshes.
+\item Cell-centric loops now also allow to access gradients and Hessians
+of neighboring cells on faces. The major difficulty here was their reorientation
+in the case of arbitrary orientated cells on unstructured meshes.
\item Users can now create their own cell batches, by providing \texttt{FEEvaluation::reinit()} a list of cell IDs. \texttt{FEEvaluation}
accesses the appropriate data and reshuffles mapping data accordingly on
-the fly to enable vectorization over cells. The new feature is useful in many
-contexts. Examples are application with sharp interfaces (e.g., two phase flow
-or shock capturing) where one needs to treat cells that are ``cut'' by
-the interface in a special way. A challenge is that cell batchs
-might contain cut or not-cut cell, making vectorization potentially more complication. One way to deal with such cell batches it to apply masks if
+the fly in order to enable vectorization over cells. The new feature is useful in many
+contexts. Examples are application with sharp interfaces (e.g., two-phase flow
+or shock capturing), where one needs to treat cells that are ``cut'' by
+the interface in a special way. A challenge is that cell batches
+might contain cut or not-cut cells, making vectorization potentially more complicated. One way to deal with such cell batches is to apply masks if
the code paths do not diverge too much
-(many functions of \texttt{FEEvaluation} allows this). Another way is to
+(a lot of functions of \texttt{FEEvaluation} allows this). Another way is to
categorize cells during \texttt{MatrixFree::reinit()} in such a way that mixed cell batches do not occur. However, calling \texttt{MatrixFree::reinit()}
might be too expensive if a very dynamic system is given, which requires
-recatorization in each time step. Doing this on-the-fly might be a cheep alternative, even if not computationally optimal during matrix-free loops.
+recategorization in each time step. Doing this on the fly might be a cheep alternative, even if not computationally optimal during matrix-free loops.
\end{itemize}
Besides these new features, we improved the performance of
hanging-node-constraint evaluation on the CPU. Instead of performing
quasi-dense matrix-vector multiplications~\cite{KronbichlerKormann2012}, we now use an
approach based on inplace interpolation and sumfactorization, similarly
-as we already did in the GPU code~\cite{ljungkvist2017matrix}. The algorithm is described
-in \cite{munch2022hn} and performance numbers are shown, indicating a reduction
+as we already did in the GPU code~\cite{ljungkvist2017matrix}. In \cite{munch2022hn}, the algorithm is described
+and performance numbers are shown, indicating a reduction
of overhead of cells with hanging nodes by a factor of 10$\times$.
Furthermore, we have performed a major restructuring of internals
-of the \texttt{FEEvaluation} classes. This will enable us to add more
-simply the support of new element types in the future, e.g., of
-Raviart--Thomas and Nedelec elements.
+of the \texttt{FEEvaluation} classes. This will enable us to add the support of new element types, e.g., of
+Raviart--Thomas and Nedelec elements, more
+simply in the future.
%\begin{c++}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Advances in multigrid infrastructure}\label{sec:multigrid}
-In release 9.3~\cite{dealII93}, we added support for global coarsening multigrid in
-addition to the established local smoothing infrastructure. Global
+In release 9.3~\cite{dealII93}, we added support for global-coarsening multigrid in
+addition to the established local-smoothing infrastructure. Global
coarsening smoothens on the whole computational domain on each
-multigrid level, which are obtained by coarsening the finest mesh globally.
-For this purpose, we use a sequence of triangulations, on which we perform
-the smoothing only on the active levels. To create the sequence of
+multigrid level, which is obtained by coarsening the finest mesh globally.
+For this purpose, we use a sequence of triangulations, and we perform
+the smoothing only on their active levels. To create the sequence of
triangulations, one can use the functions \texttt{create\_geometric\_coarsening\_sequence()} from the
\texttt{MGTransferGlobalCoarseningTools} namespace. A new version takes an
-instance of \texttt{RepartitioningPolicyTools::Base} (see Subsection~\ref{sec:repartitioning}, which allow to specify the parallel
-distribution of each multigrid level (in contrast to the fixed---first-child---policy in the case of local smoothing). Furthermore, we added support of block vectors,
+instance of \texttt{RepartitioningPolicyTools::Base} (see Subsection~\ref{sec:repartitioning}) as argument, which allows to specify the parallel
+distribution of each multigrid level (in contrast to the fixed first-child policy in the case of local smoothing). Furthermore, we added support for block vectors,
fixed a number of limitations, and performed performance optimizations of
the transfer operator; particularly, the redundant copy from/to temporary vectors
-has been eliminated and the application of hanging-node constraints are applied
-efficiently the same way as in the matrix-free loops (see Subsection~\ref{sec:mf}).
+has been eliminated. Now, hanging-node constraints are applied
+efficiently in the same way as in the matrix-free loops (see Subsection~\ref{sec:mf}).
-In \cite{munch2022gc}, the performance of \texttt{deal.II}'s local-smoothing and global-coarsening
-infrastructure was compared for locally refined meshes. The results indicate that
-the local definition of multirgrid levels might introduce load imbalances
+In \cite{munch2022gc}, the performance of the local-smoothing and global-coarsening
+infrastructure of \texttt{deal.II} was compared for locally refined meshes. The results indicate that
+the local definition of multigrid levels might introduce load imbalances
in the case of local smoothing so that global coarsening is favorable despite
-of potentially more expensive inter-grid transfers. To judge the benefit
+potentially more expensive intergrid transfers. In order, to judge the benefits
of one approach against the other, \texttt{deal.II} provides new functions
\texttt{workload\_imbalance()} and \texttt{vertical\_communication\_efficiency()}
-in the \texttt{MGTools} namespace to estimate the workload imbalance and the
-vertical communication efficiency purely based on the given mesh. The publication also points out that not
-all types of smoothers are applicable for global coarsening, due to the
-presence of hanging-nodes, which is a motivation to add new smoother types
-to \dealii.
+in the \texttt{MGTools} namespace for the estimation of the workload imbalance and the
+vertical communication efficiency purely based on the given mesh. The publication \cite{munch2022gc} also points out that not
+all types of smoothers are applicable for global coarsening due to the
+presence of hanging nodes, which is a motivation to add new smoother types
+to \dealii in the future.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{CutFEM support}\label{sec:cut}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsection{New and improved tutorials and code gallery programs}
+\subsection{New and improved tutorials}
\label{subsec:steps}
Many of the \dealii{} tutorial programs were revised in a variety of
\href{https://dealii.org/developer/doxygen/deal.II/changes_between_9_3_0_and_9_4_0.html}
{around 40 incompatible changes}; see \cite{changes94}. The majority of these changes
should not be visible to typical user codes; some remove previously
-deprecated classes and functions; and the majority change internal
+deprecated classes and functions; and the majority changes internal
interfaces that are not usually used in external
applications. That said, the following are worth mentioning since they
may have been more widely used:
\begin{itemize}
\item In continuation of our attempt to merge the classes \texttt{DoFHandler} and \texttt{hp::DoFHandler}, we have removed the
- template parameter \texttt{DoFHandlerType} form many classes and
+ template parameter \texttt{DoFHandlerType} from number of classes and
functions and replaced it by \texttt{dim}/\texttt{spacedim}. Affected
classes are, e.g., \texttt{SolutionTransfer} and \texttt{DataOut}.
\item \texttt{FE\_RaviartThomasNodal} now uses a different polynomial space to allow
for a simpler use for faces in non-standard orientation. The new polynomials
-are anisotropic tensor products of Lagrange polynomials on the points of a
-Gauss--Lobatto quadrature formula. This change leads to different entries in
-the matrices and constraints, for example, but as the resulting polynomial
-space spans the same polynomials, no change in accuracy should be expected.
-\item We made different changes to the repartitoning of \texttt{parallel::distributed::Triangulation}. Most notably, we have have
-removed the default weight (10,000) for consistency reasons with the rest
+are anisotropic tensor products of Lagrange polynomials on the points of the
+Gauss--Lobatto quadrature formula. This change leads to different entries, for example, in
+the matrices and constraints, but no change in accuracy should be expected as the resulting polynomial
+space spans the same polynomials.
+\item We made different changes in the repartitioning of \texttt{parallel::distributed::Triangulation}. Most notably, we have
+removed the default weight (10,000) in order to ensure consistency with the rest
of the library.
\end{itemize}
\newcommand*\fsize{\dimexpr\f@size pt\relax}%
\newcommand*\lineheight[1]{\fontsize{\fsize}{#1\fsize}\selectfont}%
\ifx\svgwidth\undefined%
- \setlength{\unitlength}{684.71485517bp}%
+ \setlength{\unitlength}{685.42349496bp}%
\ifx\svgscale\undefined%
\relax%
\else%
\global\let\svgwidth\undefined%
\global\let\svgscale\undefined%
\makeatother%
- \begin{picture}(1,0.45602588)%
+ \begin{picture}(1,0.45555441)%
\lineheight{1}%
\setlength\tabcolsep{0pt}%
\put(0,0){\includegraphics[width=\unitlength,page=1]{repartitioning.pdf}}%
- \put(0.88363077,0.05285442){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 0\end{tabular}}}}%
- \put(0.91134681,0.05285442){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 1\end{tabular}}}}%
- \put(0.9388259,0.05285442){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 2\end{tabular}}}}%
- \put(0.96654194,0.05285442){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 3\end{tabular}}}}%
- \put(0.86106546,0.05285442){\color[rgb]{0,0,0}\makebox(0,0)[rt]{\lineheight{1.25}\smash{\begin{tabular}[t]{r}\tiny{ranks:}\end{tabular}}}}%
+ \put(0.88271721,0.05279977){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 0\end{tabular}}}}%
+ \put(0.9104046,0.05279977){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 1\end{tabular}}}}%
+ \put(0.93785528,0.05279977){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 2\end{tabular}}}}%
+ \put(0.96554266,0.05279977){\color[rgb]{0,0,0}\makebox(0,0)[lt]{\lineheight{1.25}\smash{\begin{tabular}[t]{l}\tiny 3\end{tabular}}}}%
+ \put(0.86017523,0.05279977){\color[rgb]{0,0,0}\makebox(0,0)[rt]{\lineheight{1.25}\smash{\begin{tabular}[t]{r}\tiny{ranks:}\end{tabular}}}}%
\put(0,0){\includegraphics[width=\unitlength,page=2]{repartitioning.pdf}}%
- \put(0.0907548,0.44492978){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old partitioning}\end{tabular}}}}%
- \put(0.09075479,0.00303788){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{new partitioning}\end{tabular}}}}%
+ \put(0.09066097,0.44446978){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old partitioning}\end{tabular}}}}%
+ \put(0.09066096,0.00303474){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{new partitioning}\end{tabular}}}}%
\put(0,0){\includegraphics[width=\unitlength,page=3]{repartitioning.pdf}}%
- \put(0.36459141,0.44492978){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old rank "0"}\end{tabular}}}}%
- \put(0.36459141,0.00303788){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old rank "1"}\end{tabular}}}}%
+ \put(0.36421447,0.44446978){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old rank "0"}\end{tabular}}}}%
+ \put(0.36421447,0.00303474){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{old rank "1"}\end{tabular}}}}%
\put(0,0){\includegraphics[width=\unitlength,page=4]{repartitioning.pdf}}%
- \put(0.9133016,0.22778746){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{new rank "0"}\end{tabular}}}}%
+ \put(0.91235736,0.22755196){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{new rank "0"}\end{tabular}}}}%
\put(0,0){\includegraphics[width=\unitlength,page=5]{repartitioning.pdf}}%
+ \put(0.40658635,0.2244243){\color[rgb]{0,0,0}\makebox(0,0)[t]{\lineheight{1.25}\smash{\begin{tabular}[t]{c}\textit{ghost cells}\end{tabular}}}}%
+ \put(0,0){\includegraphics[width=\unitlength,page=6]{repartitioning.pdf}}%
\end{picture}%
\endgroup%
projects / release-papers.git / commitdiff
