From 0fedd28710565bf0e26e8f8ed7e4f239afe8b391 Mon Sep 17 00:00:00 2001 From: Marc Fehling Date: Thu, 22 Apr 2021 18:37:37 -0600 Subject: [PATCH] Strip trailing spaces. --- 9.3/paper.tex | 130 +++++++++++++++++++++++++------------------------- 1 file changed, 65 insertions(+), 65 deletions(-) diff --git a/9.3/paper.tex b/9.3/paper.tex index 8380c1c..276fce2 100644 --- a/9.3/paper.tex +++ b/9.3/paper.tex @@ -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 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 fe {FE_SimplexP(degree), FE_Q(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 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 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 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 - ; + ; 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} -- 2.39.5