\usetikzlibrary{shapes.misc}
\tikzset{cross/.style={cross out, draw=black, minimum size=2*(#1-\pgflinewidth), inner sep=0pt, outer sep=0pt},
-%default radius will be 1pt.
+%default radius will be 1pt.
cross/.default={2pt}}
%
\foreach \i in {0,1, 2, 3}
\fill (\i) circle (1.1pt) node [below] {};
-
-
+
+
\foreach \i in {4,5,6,7,8}
\draw (\i) node[cross, draw=red, rotate=-20] {};
\foreach \i in {0,1,2,3}
\fill (\i) circle (1.5pt) node [below] {};
-
-
+
+
\foreach \i in {4,5,6,7,8,9}
\draw (\i) node[cross, draw=red, rotate=-20] {};
\foreach \i in {0,1,2,3,4}
\fill (\i) circle (1.3pt) node [below] {};
-
-
+
+
%\foreach \i in {5, 6, 7, 8, 9, 10, 11, 12, 13}
% \draw (\i) node[cross] {};
\foreach \i in {0,1,2,3,4,5}
\fill (\i) circle (1.5pt) node [below] {};
-
+
\foreach \i in {6,7,8,9,10,11,12,13,14}
\draw (\i) node[cross, draw=red, rotate=-20] {};
\foreach \i in {0,1,2,3,4,5,6,7}
\fill (\i) circle (1.3pt) node [below] {};
-
+
\foreach \i in {8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26}
\draw (\i) node[cross, draw=red, rotate=-20] {};
\end{tabular}
\end{table}
-The current release of \dealii adds support for simplex meshes (consisting of triangles in 2D; tetrahedra in 3D) and mixed meshes (consisting of triangles and/or
-quadrilaterals in 2D; tetrahedra, pyramids, wedges, and/or hexahedra in 3D).
+The current release of \dealii adds support for simplex meshes (consisting of triangles in 2D; tetrahedra in 3D) and mixed meshes (consisting of triangles and/or
+quadrilaterals in 2D; tetrahedra, pyramids, wedges, and/or hexahedra in 3D).
Many freely available mesh-generation tools produce such kind of meshes; while users of \dealii used to have to pre-process such meshes and convert them to pure hex meshes, they
can now directly work with them.
\subsubsection{Refactoring of internal data structures}
-To enable simplex and mixed mesh support, we performed a major refactoring of the internal data structures of \dealii. In particular, the \texttt{Triangulation} class and
-the \texttt{DoFHandler} class have undergone large changes.
+To enable simplex and mixed mesh support, we performed a major refactoring of the internal data structures of \dealii. In particular, the \texttt{Triangulation} class and
+the \texttt{DoFHandler} class have undergone large changes.
The template parameters of the internal data structures of \texttt{Triangulation}
have been removed and the type of each cell and of each face (only in 3D) is stored. The function
\texttt{Triangulation::create\_\allowbreak triangulation()}, which converts a given list of
-cells and vertices to the internal data structures, has been rewritten
-inspired by \citep{logg09} and a speed-up of up to 5 has been reached. Minor adjustments
-have been made to \texttt{parallel::shared::Triangulation} and \texttt{parallel::\allowbreak fullydistributed::\allowbreak Triangulation} such that
+cells and vertices to the internal data structures, has been rewritten
+inspired by \citep{logg09} and a speed-up of up to 5 has been reached. Minor adjustments
+have been made to \texttt{parallel::shared::Triangulation} and \texttt{parallel::\allowbreak fullydistributed::\allowbreak Triangulation} such that
the new mesh types can be processed also in parallel.
The internal data structures of \texttt{DoFHandler} used to be hard-coded for pure
\texttt{hp::DoFHandler} into the \texttt{DoFHandler}. The class \texttt{hp::DoFHandler}, which is now a dummy derivation of \texttt{DoFHandler}, currently only exists for compatibility reasons. For
more details see Subsection~\ref{TODO}.
-\subsubsection{Generating meshes }
+\subsubsection{Generating meshes}
The most obvious way to generate a simplex or a mixed mesh is to read the mesh from a file
-generated by an external mesh generator. Currently, we support the
+generated by an external mesh generator. Currently, we support the
file formats \texttt{VTK}, \texttt{MSH}, \texttt{EXODUS II}.
Alternatively, one can create a pure hypercube mesh with the known functions
in the \texttt{GridGenerator} namespace and convert the obtained mesh to a
-pure simplex mesh with the function
+pure simplex mesh with the function
\texttt{convert\_\allowbreak hypercube\_\allowbreak to\_\allowbreak simplex\_\allowbreak mesh()} from the \texttt{GridGenerator} namespace.
\subsubsection{Simplex mesh}
FEValues<dim, spacedim> fe_values(mapping, fe, quad, flags);
\end{c++}
The list of currently supported finite-element classes is provided in Table~\ref{tab:simplex:fe}. Currently,
-only linear iso-parametric mapping (\texttt{MappingFE} and \texttt{MappingFEFields}) is available. For quadrature, the classes \texttt{QGaussSimplex}, \texttt{QWitherdenVincentSimplex},
+only linear iso-parametric mapping (\texttt{MappingFE} and \texttt{MappingFEFields}) is available. For quadrature, the classes \texttt{QGaussSimplex}, \texttt{QWitherdenVincentSimplex},
\texttt{QGaussPyamid}, and \texttt{QGaussWedge} are
available.
\subsubsection{Mixed mesh}
-For mixed meshes, concepts known from the $hp$-context have been applied:
- different finite-element classes are assigned to different cell types. In the
+For mixed meshes, concepts known from the $hp$-context have been applied:
+ different finite-element classes are assigned to different cell types. In the
case of a 2D mixed mesh, which can only consists of triangles and
quadrilaterals, the finite element defined on a triangle (e.g., \texttt{FE\_SimplexP})
and on a quadrilateral (e.g., \texttt{FE\_Q}) can be collected in a \texttt{hp::FECollection}:
-\begin{c++}
+\begin{c++}
hp::FECollection<dim, spacedim> fe
{FE_SimplexP<dim, spacedim>(degree), FE_Q<dim, spacedim>(degree)};
\end{c++}
Similarly, \texttt{hp::QCollection} and \texttt{hp::MappingCollection} can be used
-to construct appropriate collections. Furthermore, the right active finite-element index, which points to the right
+to construct appropriate collections. Furthermore, the right active finite-element index, which points to the right
finite element of that cell, has to be assigned to each cell:
-\begin{c++}
+\begin{c++}
DoFHandler<dim> dof_handler(tria);
for (const auto &cell : dof_handler.active_cell_iterators())
dof_handler.distribute_dofs(fe);
\end{c++}
-\subsubsection{Practical implications}
+\subsubsection{Practical implications}
The introduction of simplex and mixed meshes leads to some implications
-for the user if these features should be used. For instance, each cell might have a different type with
-different number of vertices, lines, and faces so that these quantities can not be
+for the user if these features should be used. For instance, each cell might have a different type with
+different number of vertices, lines, and faces so that these quantities can not be
compile-time constants anymore. This information used to be queried from
the \texttt{GeometryInfo} class. To avoid using this class, we have extended
relevant classes, e.g., \texttt{TriaAccessor} or \texttt{TriaCellAccessor},
\end{c++}
Alternatively, one can use an iterator-based approach to loop over all faces
of a cell, introduced in the last release. The relevant functions have been adjusted to be able to deal with
-various number of faces.
+various number of faces.
\begin{c++}
for(const auto & cell : tria.active_cell_iterators())
for(const auto & face : cell->face_iterators())
(void) face;
\end{c++}
Furthermore, the number of degrees of freedom might differ between cells so that
-local data storage units needed for assembly might need to be resized for each
+local data storage units needed for assembly might need to be resized for each
cell as it is already good practice in the $hp$-context:
\begin{c++}
std::vector<double> local_rhs;
\end{c++}
-Furthermore, it is crucial to use the right FE--mapping--quadrature family
-for the right cell type. In particular, this means that users cannot
-rely on default parameters regarding mapping and/or quadrature in the
+Furthermore, it is crucial to use the right FE--mapping--quadrature family
+for the right cell type. In particular, this means that users cannot
+rely on default parameters regarding mapping and/or quadrature in the
context of simplex meshes since these are defined for hypercube cells.
We recommend to choose the needed mapping,
FE, and quadrature rules at a single central place and pass these throughout the program
spaces via a tensor product, one provides d-dimensional quadrature rules.
The templated versions of \texttt{FEEvaluation} and \texttt{FEFaceEvaluation} cannot be used: the number of degrees of freedom and the number of quadrature points are determined at runtime. More details can be found in Subsection~\ref{subsec:mf}.
-By the time of writing, we do not use internally any advance techniques for evaluating values and
-gradients at the quadrature points as we do for tensor-product elements and
-instead rely on full interpolation matrices. This is for now acceptable since only low-order elements are
-supported.
+By the time of writing, we do not use internally any advance techniques for evaluating values and
+gradients at the quadrature points as we do for tensor-product elements and
+instead rely on full interpolation matrices. This is for now acceptable since only low-order elements are
+supported.
-\subsubsection{Miscellaneous}
+\subsubsection{Miscellaneous}
We have created two new tutorials presenting the new simplex (\texttt{step-3b}) and mixed mesh features
(\texttt{step-3c}). Similarly as \texttt{step-3}, they solve a Poisson problem, however, focus
on the changed workflow.
-By the time of writing, there have been 74 tests (in the folder \texttt{tests/simplex})
+By the time of writing, there have been 74 tests (in the folder \texttt{tests/simplex})
targeting the new simplex and mixed mesh support. In particular, the folder also
contains ported variants of the following tutorials: 1, 2, 3, 4, 6, 7, 8, 12, 17, 18, 20, 23, 31, 38,
-40, 55, 67, 68, and 74. These might be also good starting points.
+40, 55, 67, 68, and 74. These might be also good starting points.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Until now, \dealii has only supported local smoothing multigrid algorithms~\citep{ClevengerHeisterKanschatKronbichler2019}. With release 9.3, the support for global coarsening of continuous (\texttt{FE\_Q}, \texttt{FE\_SimplexP}) and discontinuous (\texttt{FE\_DGQ}, \texttt{FE\_SimplexDGP}) elements in a geometric and a polynomial sense has been added. These multigrid variants promise less iteration numbers and better parallel scalability with the disadvantage of having to deal with hanging nodes during smoothing and of more work per iteration overall.
-Global-coarsening algorithms~\citep{becker00} either coarsen each cell of a triangulation or reduce the polynomial degree of the finite element of each cell and hereby obtain a new system with less unknowns (also known as "coarse level").
+Global-coarsening algorithms~\citep{becker00} either coarsen each cell of a triangulation or reduce the polynomial degree of the finite element of each cell and hereby obtain a new system with less unknowns (also known as "coarse level").
Repeating such kind of coarsening results in a sequence of multigrid levels.
The transfer between two levels has been encoded in the new class \texttt{MGTwoLevelTransfer}, which can be set up via the functions \texttt{MGTwoLevelTransfer::\allowbreak reinit\_\allowbreak geometric\_\allowbreak transfer()} or \texttt{MGTwo\allowbreak LevelTransfer::\allowbreak reinit\_\allowbreak polynomial\_\allowbreak transfer()} for given
\texttt{DoFHandler} and \texttt{AffineConstraint} classes of two levels. The resulting transfer operators
-between two levels can be collected in a single object
+between two levels can be collected in a single object
(\texttt{MGTransferGlobalCoarsening}) that can be used just as \texttt{MGTransferMatrixFree} and can be passed to the actual \texttt{Multigrid}
algorithm. The option that users can set up the transfer operators between two levels on their own enables
the mix of polynomial and geometric coarsening, as needed. It should also be noted that a transfer between continuous
and discontinuous elements is possible by providing \texttt{DoFHandler}s set up with this kind of elements.
-Internally, the transfer operators categorize fine/coarse cell pairs according to the
-occurrence of refinement
-(refinement or no-refinement) and to the polynomial-degree pair ($k_f$-$k_c$) into groups.
+Internally, the transfer operators categorize fine/coarse cell pairs according to the
+occurrence of refinement
+(refinement or no-refinement) and to the polynomial-degree pair ($k_f$-$k_c$) into groups.
The projection and restriction are performed with efficient matrix-free kernels applying
1D projection and restriction matrices in the case of hypercube cells and via full projection and
restriction matrices in the case of simplex cells.
The user is responsible for setting up the levels (including the operators and the
-smoothers). Please note that global coarsening can currently only be performed between active levels.
+smoothers). Please note that global coarsening can currently only be performed between active levels.
The user can apply utility
-functions from the \texttt{MGTransferGlobalCoarseningTools} namespace to set up the levels. For
+functions from the \texttt{MGTransferGlobalCoarseningTools} namespace to set up the levels. For
constructing the diagonal or the system matrix for a matrix-free operator,
needed for the smoother or the coarse-grid solver,
the functions \texttt{create\_diagonal()} and \texttt{create\_matrix()} from
the polynomial degree of the finite element $k$ and the number of the 1D quadrature points $q$.
For application codes that rely on operators of many different degrees (e.g., because
they use $p$-multigrid or $hp$-algorithms), the instantiation
-means a long compilation time.
+means a long compilation time.
In the current release, we have improved the \texttt{FEEvaluation} and the \texttt{FEFaceEvaluation} class implementations that do
not rely on the template parameters $k$ and $q$ (expressed in the code
FEEvaluation<dim, -1, 0, n_components, Number, VectorizedArrayType>
phi(range, dofhandler_index, quadrature_index, first_selected_component);
\end{c++}
-The meaning of the new first argument is
+The meaning of the new first argument is
discussed in Subsubsection~\ref{subsubsection:mf:hp}.
-These classes select at runtime---for common low and medium polynomial degree/quadrature combinations ($k\le 6$ and $q\in\{ k+1, k+2, \lfloor (3k)/2 \rfloor \}$)---efficient precompiled implementations and default to non-templated
-evaluation kernels else.
+These classes select at runtime---for common low and medium polynomial degree/quadrature combinations ($k\le 6$ and $q\in\{ k+1, k+2, \lfloor (3k)/2 \rfloor \}$)---efficient precompiled implementations and default to non-templated
+evaluation kernels else.
In the case that even higher polynomial degrees are needed, one can precompile the
relevant internal classes
DEAL_II_NAMESPACE_OPEN
template struct dealii::internal::FEEvaluationFactory
- <dim, VectorizedArrayType::value_type, VectorizedArrayType>;
+ <dim, VectorizedArrayType::value_type, VectorizedArrayType>;
DEAL_II_NAMESPACE_CLOSE
\end{c++}
release, we have extended the setup routines of \texttt{MatrixFree} so that it now also
provides parallel $hp$-support.
-Until now, the \texttt{FEEvaluation} classes used the template parameters $k$ and $q$ to select the correct active FE and quadrature index and users had
+Until now, the \texttt{FEEvaluation} classes used the template parameters $k$ and $q$ to select the correct active FE and quadrature index and users had
to use the function \texttt{MatrixFree::create\_cell\_\allowbreak subrange\_\allowbreak hp()} or
-\texttt{::create\_cell\_\allowbreak subrange\_\allowbreak hp\_\allowbreak by\_index()} to create subranges of cells with
-the same polynomial degree. This led to user codes that were hard to read due to complicated jump tables.
+\texttt{::create\_cell\_\allowbreak subrange\_\allowbreak hp\_\allowbreak by\_index()} to create subranges of cells with
+the same polynomial degree. This led to user codes that were hard to read due to complicated jump tables.
The creation of subranges is now performed internally, and the non-templated versions
of the \texttt{FEEvaluation} classes are extended for the $hp$-case. To nevertheless determine
can be deduced (in the simplex case also the face type). These changes enable
users to write matrix-free code independently of whether $hp$-capabilities are used or not.
-The new tutorial \texttt{step-75} presents how to use the new $hp$-related features in \texttt{MatrixFree}
+The new tutorial \texttt{step-75} presents how to use the new $hp$-related features in \texttt{MatrixFree}
in the context of a hybrid-multigrid solver.
-\subsubsection{MPI-3.0 shared-memory support}
-The classes \texttt{MatrixFree} and \texttt{LinearAlgebra::\allowbreak distributed::\allowbreak Vector} have been extended with
+\subsubsection{MPI-3.0 shared-memory support}
+The classes \texttt{MatrixFree} and \texttt{LinearAlgebra::\allowbreak distributed::\allowbreak Vector} have been extended with
MPI-3.0 shared-memory features. If \texttt{MatrixFree} has been configured by setting
\texttt{MatrixFree::AdditionalData::communicator\_sm} by an appropriate user-provided subcommunicator,
vectors are created by \texttt{MatrixFree::create\_dof\_vector()} in such a way that the
-memory of processes in this subcommunicator can be accessed. In particular, this means
-that the \texttt{FEEvaluation} classes can access the degrees of freedom owned by
-other processes and in certain cases local
+memory of processes in this subcommunicator can be accessed. In particular, this means
+that the \texttt{FEEvaluation} classes can access the degrees of freedom owned by
+other processes and in certain cases local
communication can be skipped. To prevent race conditions, \texttt{MatrixFree} uses local
barriers at the beginning and the end of loops (\texttt{loop()}, \texttt{cell\_loop()}, \texttt{loop\_cell\_centric()}).
The namespace \texttt{MatrixFreeTools} has been introduced. It collects various utility
functions useful in the context of application of \texttt{MatrixFree}. In particular,
-it contains different functions to extract quantities related to a matrix, e.g., the
+it contains different functions to extract quantities related to a matrix, e.g., the
computation of the diagonal or a matrix with a matrix-free approach.
With version 9.2, we have introduced cell-centric loops. They have been extended to unstructured
\begin{c++}
phi_normal.evaluate(cell, points, normal_values, EvaluationFlags::values);
for (unsigned int q = 0; q < n_points; ++q)
- phi_force.submit_value(phi_normal.get_value(q) *
+ phi_force.submit_value(phi_normal.get_value(q) *
phi_curvature.get_value(q) * JxW[q], q);
phi_force.integrate(cell, points, force_values, EvaluationFlags::values);
\end{c++}
-The quadrature points and the connected \texttt{JxW} can, e.g., come from a
+The quadrature points and the connected \texttt{JxW} can, e.g., come from a
codim-1 mesh. Determining to which \texttt{cell} a quadrature point belongs
to on the background mesh, incl. the reference-cell coordinates \texttt{points},
can be determined with know functions like \texttt{GridTools::find\_all\_active\_cells\_around\_point()}.
applications. That said, the following are worth mentioning since they
may have been more widely used:
\begin{itemize}
- \item
+ \item
\end{itemize}
projects / release-papers.git / commitdiff