]> https://gitweb.dealii.org/ - release-papers.git/commitdiff
Strip trailing spaces.
authorMarc Fehling <mafehling.git@gmail.com>
Fri, 23 Apr 2021 00:37:37 +0000 (18:37 -0600)
committerMarc Fehling <mafehling.git@gmail.com>
Fri, 23 Apr 2021 01:54:48 +0000 (19:54 -0600)
9.3/paper.tex

index 8380c1c396b1d86b158db17fa2e139545ec32806..276fce292f6d859beac2e0e23b750a32992d6ec0 100644 (file)
@@ -43,7 +43,7 @@
 
 \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}}
 
 %
@@ -317,8 +317,8 @@ can be found
 
 \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] {};
 
@@ -344,8 +344,8 @@ can be found
 
 \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] {};
 
@@ -378,8 +378,8 @@ can be found
 
 \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] {};
 
@@ -415,7 +415,7 @@ can be found
 
 \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] {};
 
@@ -466,7 +466,7 @@ can be found
 
 \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] {};
 
@@ -501,22 +501,22 @@ can be found
   \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
@@ -526,15 +526,15 @@ CRS-like data structures. Due to the need of CRS data structures in the
 \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}
@@ -554,27 +554,27 @@ dof_handler.distribute_dofs(fe);
 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())
@@ -589,11 +589,11 @@ 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},
@@ -606,14 +606,14 @@ for(const auto & cell : tria.active_cell_iterators())
 \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;
@@ -638,9 +638,9 @@ const auto face_reference_cell = reference_cell.face_reference_cell(i);
 \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
@@ -661,21 +661,21 @@ Instead of providing a 1D quadrature rule, which is extended to higher dimension
 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.
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -690,29 +690,29 @@ TODO
 
 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
@@ -734,7 +734,7 @@ templated to reach high performance. In particular, the template parameters incl
 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
@@ -743,11 +743,11 @@ with "-1" and "0"):
 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
@@ -760,7 +760,7 @@ and \texttt{VectorizedArrayType}s in the following way:
 
 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++}
 
@@ -771,10 +771,10 @@ parallel matrix-based simulations can be performed with the $hp$-infrastructure.
 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
@@ -783,17 +783,17 @@ the constructors of the \texttt{FEEvaluation} classes, from which the relevant i
 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()}).
 
@@ -807,7 +807,7 @@ For more details and a successful application in the library \texttt{hyper.deal}
 
 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
@@ -830,11 +830,11 @@ in code:
 \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()}.
@@ -891,7 +891,7 @@ 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 
+  \item
 \end{itemize}
 
 

In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

Douglas Adams


Typeset in Trocchi and Trocchi Bold Sans Serif.