Reference documentation for deal.II version GIT relicensing-249-g48dc7357c7 2024-03-29 12:30:02+00:00
\(\newcommand{\dealvcentcolon}{\mathrel{\mathop{:}}}\) \(\newcommand{\dealcoloneq}{\dealvcentcolon\mathrel{\mkern-1.2mu}=}\) \(\newcommand{\jump}[1]{\left[\!\left[ #1 \right]\!\right]}\) \(\newcommand{\average}[1]{\left\{\!\left\{ #1 \right\}\!\right\}}\)
Loading...
Searching...
No Matches
step-37.h
Go to the documentation of this file.
1) const
757 *   {
758 *   return 1. / (0.05 + 2. * p.square());
759 *   }
760 *  
761 *  
762 *  
763 *   template <int dim>
764 *   double Coefficient<dim>::value(const Point<dim> &p,
765 *   const unsigned int component) const
766 *   {
767 *   return value<double>(p, component);
768 *   }
769 *  
770 *  
771 * @endcode
772 *
773 *
774 * <a name="step_37-Matrixfreeimplementation"></a>
775 * <h3>Matrix-free implementation</h3>
776 *
777
778 *
779 * The following class, called <code>LaplaceOperator</code>, implements the
780 * differential operator. For all practical purposes, it is a matrix, i.e.,
781 * you can ask it for its size (member functions <code>m(), n()</code>) and
782 * you can apply it to a vector (the <code>vmult()</code> function). The
783 * difference to a real matrix of course lies in the fact that this class
784 * does not actually store the <i>elements</i> of the matrix, but only knows
785 * how to compute the action of the operator when applied to a vector.
786 *
787
788 *
789 * The infrastructure describing the matrix size, the initialization from a
790 * MatrixFree object, and the various interfaces to matrix-vector products
791 * through vmult() and Tvmult() methods, is provided by the class
792 * MatrixFreeOperator::Base from which this class derives. The
793 * LaplaceOperator class defined here only has to provide a few interfaces,
794 * namely the actual action of the operator through the apply_add() method
795 * that gets used in the vmult() functions, and a method to compute the
796 * diagonal entries of the underlying matrix. We need the diagonal for the
797 * definition of the multigrid smoother. Since we consider a problem with
798 * variable coefficient, we further implement a method that can fill the
799 * coefficient values.
800 *
801
802 *
803 * Note that the file <code>include/deal.II/matrix_free/operators.h</code>
804 * already contains an implementation of the Laplacian through the class
805 * MatrixFreeOperators::LaplaceOperator. For educational purposes, the
806 * operator is re-implemented in this tutorial program, explaining the
807 * ingredients and concepts used there.
808 *
809
810 *
811 * This program makes use of the data cache for finite element operator
812 * application that is integrated in deal.II. This data cache class is
813 * called MatrixFree. It contains mapping information (Jacobians) and index
814 * relations between local and global degrees of freedom. It also contains
815 * constraints like the ones from hanging nodes or Dirichlet boundary
816 * conditions. Moreover, it can issue a loop over all cells in %parallel,
817 * making sure that only cells are worked on that do not share any degree of
818 * freedom (this makes the loop thread-safe when writing into destination
819 * vectors). This is a more advanced strategy compared to the WorkStream
820 * class described in the @ref threads module. Of course, to not destroy
821 * thread-safety, we have to be careful when writing into class-global
822 * structures.
823 *
824
825 *
826 * The class implementing the Laplace operator has three template arguments,
827 * one for the dimension (as many deal.II classes carry), one for the degree
828 * of the finite element (which we need to enable efficient computations
829 * through the FEEvaluation class), and one for the underlying scalar
830 * type. We want to use <code>double</code> numbers (i.e., double precision,
831 * 64-bit floating point) for the final matrix, but floats (single
832 * precision, 32-bit floating point numbers) for the multigrid level
833 * matrices (as that is only a preconditioner, and floats can be processed
834 * twice as fast). The class FEEvaluation also takes a template argument for
835 * the number of quadrature points in one dimension. In the code below, we
836 * hard-code it to <code>fe_degree+1</code>. If we wanted to change it
837 * independently of the polynomial degree, we would need to add a template
838 * parameter as is done in the MatrixFreeOperators::LaplaceOperator class.
839 *
840
841 *
842 * As a sidenote, if we implemented several different operations on the same
843 * grid and degrees of freedom (like a @ref GlossMassMatrix "mass matrix" and a Laplace matrix), we
844 * would define two classes like the current one for each of the operators
845 * (derived from the MatrixFreeOperators::Base class), and let both of them
846 * refer to the same MatrixFree data cache from the general problem
847 * class. The interface through MatrixFreeOperators::Base requires us to
848 * only provide a minimal set of functions. This concept allows for writing
849 * complex application codes with many matrix-free operations.
850 *
851
852 *
853 * @note Storing values of type <code>VectorizedArray<number></code>
854 * requires care: Here, we use the deal.II table class which is prepared to
855 * hold the data with correct alignment. However, storing e.g. an
856 * <code>std::vector<VectorizedArray<number> ></code> is not possible with
857 * vectorization: A certain alignment of the data with the memory address
858 * boundaries is required (essentially, a VectorizedArray that is 32 bytes
859 * long in case of AVX needs to start at a memory address that is divisible
860 * by 32). The table class (as well as the AlignedVector class it is based
861 * on) makes sure that this alignment is respected, whereas std::vector does
862 * not in general, which may lead to segmentation faults at strange places
863 * for some systems or suboptimal performance for other systems.
864 *
865 * @code
866 *   template <int dim, int fe_degree, typename number>
867 *   class LaplaceOperator
868 *   : public MatrixFreeOperators::
869 *   Base<dim, LinearAlgebra::distributed::Vector<number>>
870 *   {
871 *   public:
872 *   using value_type = number;
873 *  
874 *   LaplaceOperator();
875 *  
876 *   void clear() override;
877 *  
878 *   void evaluate_coefficient(const Coefficient<dim> &coefficient_function);
879 *  
880 *   virtual void compute_diagonal() override;
881 *  
882 *   private:
883 *   virtual void apply_add(
885 *   const LinearAlgebra::distributed::Vector<number> &src) const override;
886 *  
887 *   void
888 *   local_apply(const MatrixFree<dim, number> &data,
891 *   const std::pair<unsigned int, unsigned int> &cell_range) const;
892 *  
893 *   void local_compute_diagonal(
894 *   const MatrixFree<dim, number> &data,
896 *   const unsigned int &dummy,
897 *   const std::pair<unsigned int, unsigned int> &cell_range) const;
898 *  
899 *   Table<2, VectorizedArray<number>> coefficient;
900 *   };
901 *  
902 *  
903 *  
904 * @endcode
905 *
906 * This is the constructor of the @p LaplaceOperator class. All it does is
907 * to call the default constructor of the base class
908 * MatrixFreeOperators::Base, which in turn is based on the Subscriptor
909 * class that asserts that this class is not accessed after going out of scope
910 * e.g. in a preconditioner.
911 *
912 * @code
913 *   template <int dim, int fe_degree, typename number>
914 *   LaplaceOperator<dim, fe_degree, number>::LaplaceOperator()
915 *   : MatrixFreeOperators::Base<dim,
917 *   {}
918 *  
919 *  
920 *  
921 *   template <int dim, int fe_degree, typename number>
922 *   void LaplaceOperator<dim, fe_degree, number>::clear()
923 *   {
924 *   coefficient.reinit(0, 0);
926 *   clear();
927 *   }
928 *  
929 *  
930 *  
931 * @endcode
932 *
933 *
934 * <a name="step_37-Computationofcoefficient"></a>
935 * <h4>Computation of coefficient</h4>
936 *
937
938 *
939 * To initialize the coefficient, we directly give it the Coefficient class
940 * defined above and then select the method
941 * <code>coefficient_function.value</code> with vectorized number (which the
942 * compiler can deduce from the point data type). The use of the
943 * FEEvaluation class (and its template arguments) will be explained below.
944 *
945 * @code
946 *   template <int dim, int fe_degree, typename number>
947 *   void LaplaceOperator<dim, fe_degree, number>::evaluate_coefficient(
948 *   const Coefficient<dim> &coefficient_function)
949 *   {
950 *   const unsigned int n_cells = this->data->n_cell_batches();
952 *  
953 *   coefficient.reinit(n_cells, phi.n_q_points);
954 *   for (unsigned int cell = 0; cell < n_cells; ++cell)
955 *   {
956 *   phi.reinit(cell);
957 *   for (const unsigned int q : phi.quadrature_point_indices())
958 *   coefficient(cell, q) =
959 *   coefficient_function.value(phi.quadrature_point(q));
960 *   }
961 *   }
962 *  
963 *  
964 *  
965 * @endcode
966 *
967 *
968 * <a name="step_37-LocalevaluationofLaplaceoperator"></a>
969 * <h4>Local evaluation of Laplace operator</h4>
970 *
971
972 *
973 * Here comes the main function of this class, the evaluation of the
974 * matrix-vector product (or, in general, a finite element operator
975 * evaluation). This is done in a function that takes exactly four
976 * arguments, the MatrixFree object, the destination and source vectors, and
977 * a range of cells that are to be worked on. The method
978 * <code>cell_loop</code> in the MatrixFree class will internally call this
979 * function with some range of cells that is obtained by checking which
980 * cells are possible to work on simultaneously so that write operations do
981 * not cause any race condition. Note that the cell range used in the loop
982 * is not directly the number of (active) cells in the current mesh, but
983 * rather a collection of batches of cells. In other word, "cell" may be
984 * the wrong term to begin with, since FEEvaluation groups data from several
985 * cells together. This means that in the loop over quadrature points we are
986 * actually seeing a group of quadrature points of several cells as one
987 * block. This is done to enable a higher degree of vectorization. The
988 * number of such "cells" or "cell batches" is stored in MatrixFree and can
989 * be queried through MatrixFree::n_cell_batches(). Compared to the deal.II
990 * cell iterators, in this class all cells are laid out in a plain array
991 * with no direct knowledge of level or neighborship relations, which makes
992 * it possible to index the cells by unsigned integers.
993 *
994
995 *
996 * The implementation of the Laplace operator is quite simple: First, we
997 * need to create an object FEEvaluation that contains the computational
998 * kernels and has data fields to store temporary results (e.g. gradients
999 * evaluated on all quadrature points on a collection of a few cells). Note
1000 * that temporary results do not use a lot of memory, and since we specify
1001 * template arguments with the element order, the data is stored on the
1002 * stack (without expensive memory allocation). Usually, one only needs to
1003 * set two template arguments, the dimension as a first argument and the
1004 * degree of the finite element as the second argument (this is equal to the
1005 * number of degrees of freedom per dimension minus one for FE_Q
1006 * elements). However, here we also want to be able to use float numbers for
1007 * the multigrid preconditioner, which is the last (fifth) template
1008 * argument. Therefore, we cannot rely on the default template arguments and
1009 * must also fill the third and fourth field, consequently. The third
1010 * argument specifies the number of quadrature points per direction and has
1011 * a default value equal to the degree of the element plus one. The fourth
1012 * argument sets the number of components (one can also evaluate
1013 * vector-valued functions in systems of PDEs, but the default is a scalar
1014 * element), and finally the last argument sets the number type.
1015 *
1016
1017 *
1018 * Next, we loop over the given cell range and then we continue with the
1019 * actual implementation: <ol> <li>Tell the FEEvaluation object the (macro)
1020 * cell we want to work on. <li>Read in the values of the source vectors
1021 * (@p read_dof_values), including the resolution of constraints. This
1022 * stores @f$u_\mathrm{cell}@f$ as described in the introduction. <li>Compute
1023 * the unit-cell gradient (the evaluation of finite element
1024 * functions). Since FEEvaluation can combine value computations with
1025 * gradient computations, it uses a unified interface to all kinds of
1026 * derivatives of order between zero and two. We only want gradients, no
1027 * values and no second derivatives, so we set the function arguments to
1028 * true in the gradient slot (second slot), and to false in the values slot
1029 * (first slot). There is also a third slot for the Hessian which is
1030 * false by default, so it needs not be given. Note that the FEEvaluation
1031 * class internally evaluates shape functions in an efficient way where one
1032 * dimension is worked on at a time (using the tensor product form of shape
1033 * functions and quadrature points as mentioned in the introduction). This
1034 * gives complexity equal to @f$\mathcal O(d^2 (p+1)^{d+1})@f$ for polynomial
1035 * degree @f$p@f$ in @f$d@f$ dimensions, compared to the naive approach with loops
1036 * over all local degrees of freedom and quadrature points that is used in
1037 * FEValues and costs @f$\mathcal O(d (p+1)^{2d})@f$. <li>Next comes the
1038 * application of the Jacobian transformation, the multiplication by the
1039 * variable coefficient and the quadrature weight. FEEvaluation has an
1040 * access function @p get_gradient that applies the Jacobian and returns the
1041 * gradient in real space. Then, we just need to multiply by the (scalar)
1042 * coefficient, and let the function @p submit_gradient apply the second
1043 * Jacobian (for the test function) and the quadrature weight and Jacobian
1044 * determinant (JxW). Note that the submitted gradient is stored in the same
1045 * data field as where it is read from in @p get_gradient. Therefore, you
1046 * need to make sure to not read from the same quadrature point again after
1047 * having called @p submit_gradient on that particular quadrature point. In
1048 * general, it is a good idea to copy the result of @p get_gradient when it
1049 * is used more often than once. <li>Next follows the summation over
1050 * quadrature points for all test functions that corresponds to the actual
1051 * integration step. For the Laplace operator, we just multiply by the
1052 * gradient, so we call the integrate function with the respective argument
1053 * set. If you have an equation where you test by both the values of the
1054 * test functions and the gradients, both template arguments need to be set
1055 * to true. Calling first the integrate function for values and then
1056 * gradients in a separate call leads to wrong results, since the second
1057 * call will internally overwrite the results from the first call. Note that
1058 * there is no function argument for the second derivative for integrate
1059 * step. <li>Eventually, the local contributions in the vector
1060 * @f$v_\mathrm{cell}@f$ as mentioned in the introduction need to be added into
1061 * the result vector (and constraints are applied). This is done with a call
1062 * to @p distribute_local_to_global, the same name as the corresponding
1063 * function in the AffineConstraints (only that we now store the local vector
1064 * in the FEEvaluation object, as are the indices between local and global
1065 * degrees of freedom). </ol>
1066 *
1067 * @code
1068 *   template <int dim, int fe_degree, typename number>
1069 *   void LaplaceOperator<dim, fe_degree, number>::local_apply(
1070 *   const MatrixFree<dim, number> &data,
1073 *   const std::pair<unsigned int, unsigned int> &cell_range) const
1074 *   {
1076 *  
1077 *   for (unsigned int cell = cell_range.first; cell < cell_range.second; ++cell)
1078 *   {
1079 *   AssertDimension(coefficient.size(0), data.n_cell_batches());
1080 *   AssertDimension(coefficient.size(1), phi.n_q_points);
1081 *  
1082 *   phi.reinit(cell);
1083 *   phi.read_dof_values(src);
1084 *   phi.evaluate(EvaluationFlags::gradients);
1085 *   for (const unsigned int q : phi.quadrature_point_indices())
1086 *   phi.submit_gradient(coefficient(cell, q) * phi.get_gradient(q), q);
1087 *   phi.integrate(EvaluationFlags::gradients);
1088 *   phi.distribute_local_to_global(dst);
1089 *   }
1090 *   }
1091 *  
1092 *  
1093 *  
1094 * @endcode
1095 *
1096 * This function implements the loop over all cells for the
1097 * Base::apply_add() interface. This is done with the @p cell_loop of the
1098 * MatrixFree class, which takes the operator() of this class with arguments
1099 * MatrixFree, OutVector, InVector, cell_range. When working with MPI
1100 * parallelization (but no threading) as is done in this tutorial program,
1101 * the cell loop corresponds to the following three lines of code:
1102 *
1103
1104 *
1105 * <div class=CodeFragmentInTutorialComment>
1106 * @code
1107 * src.update_ghost_values();
1108 * local_apply(*this->data, dst, src, std::make_pair(0U,
1109 * data.n_cell_batches()));
1110 * dst.compress(VectorOperation::add);
1111 * @endcode
1112 * </div>
1113 *
1114
1115 *
1116 * Here, the two calls update_ghost_values() and compress() perform the data
1117 * exchange on processor boundaries for MPI, once for the source vector
1118 * where we need to read from entries owned by remote processors, and once
1119 * for the destination vector where we have accumulated parts of the
1120 * residuals that need to be added to the respective entry of the owner
1121 * processor. However, MatrixFree::cell_loop does not only abstract away
1122 * those two calls, but also performs some additional optimizations. On the
1123 * one hand, it will split the update_ghost_values() and compress() calls in
1124 * a way to allow for overlapping communication and computation. The
1125 * local_apply function is then called with three cell ranges representing
1126 * partitions of the cell range from 0 to MatrixFree::n_cell_batches(). On
1127 * the other hand, cell_loop also supports thread parallelism in which case
1128 * the cell ranges are split into smaller chunks and scheduled in an
1129 * advanced way that avoids access to the same vector entry by several
1130 * threads. That feature is explained in @ref step_48 "step-48".
1131 *
1132
1133 *
1134 * Note that after the cell loop, the constrained degrees of freedom need to
1135 * be touched once more for sensible vmult() operators: Since the assembly
1136 * loop automatically resolves constraints (just as the
1137 * AffineConstraints::distribute_local_to_global() call does), it does not
1138 * compute any contribution for constrained degrees of freedom, leaving the
1139 * respective entries zero. This would represent a matrix that had empty
1140 * rows and columns for constrained degrees of freedom. However, iterative
1141 * solvers like CG only work for non-singular matrices. The easiest way to
1142 * do that is to set the sub-block of the matrix that corresponds to
1143 * constrained DoFs to an identity matrix, in which case application of the
1144 * matrix would simply copy the elements of the right hand side vector into
1145 * the left hand side. Fortunately, the vmult() implementations
1146 * MatrixFreeOperators::Base do this automatically for us outside the
1147 * apply_add() function, so we do not need to take further action here.
1148 *
1149
1150 *
1151 * When using the combination of MatrixFree and FEEvaluation in parallel
1152 * with MPI, there is one aspect to be careful about &mdash; the indexing
1153 * used for accessing the vector. For performance reasons, MatrixFree and
1154 * FEEvaluation are designed to access vectors in MPI-local index space also
1155 * when working with multiple processors. Working in local index space means
1156 * that no index translation needs to be performed at the place the vector
1157 * access happens, apart from the unavoidable indirect addressing. However,
1158 * local index spaces are ambiguous: While it is standard convention to
1159 * access the locally owned range of a vector with indices between 0 and the
1160 * local size, the numbering is not so clear for the ghosted entries and
1161 * somewhat arbitrary. For the matrix-vector product, only the indices
1162 * appearing on locally owned cells (plus those referenced via hanging node
1163 * constraints) are necessary. However, in deal.II we often set all the
1164 * degrees of freedom on ghosted elements as ghosted vector entries, called
1165 * the
1166 * @ref GlossLocallyRelevantDof "locally relevant DoFs described in the glossary".
1167 * In that case, the MPI-local index of a ghosted vector entry can in
1168 * general be different in the two possible ghost sets, despite referring
1169 * to the same global index. To avoid problems, FEEvaluation checks that
1170 * the partitioning of the vector used for the matrix-vector product does
1171 * indeed match with the partitioning of the indices in MatrixFree by a
1172 * check called
1173 * LinearAlgebra::distributed::Vector::partitioners_are_compatible. To
1174 * facilitate things, the MatrixFreeOperators::Base class includes a
1175 * mechanism to fit the ghost set to the correct layout. This happens in the
1176 * ghost region of the vector, so keep in mind that the ghost region might
1177 * be modified in both the destination and source vector after a call to a
1178 * vmult() method. This is legitimate because the ghost region of a
1179 * distributed deal.II vector is a mutable section and filled on
1180 * demand. Vectors used in matrix-vector products must not be ghosted upon
1181 * entry of vmult() functions, so no information gets lost.
1182 *
1183 * @code
1184 *   template <int dim, int fe_degree, typename number>
1185 *   void LaplaceOperator<dim, fe_degree, number>::apply_add(
1186 *   LinearAlgebra::distributed::Vector<number> &dst,
1187 *   const LinearAlgebra::distributed::Vector<number> &src) const
1188 *   {
1189 *   this->data->cell_loop(&LaplaceOperator::local_apply, this, dst, src);
1190 *   }
1191 *  
1192 *  
1193 *  
1194 * @endcode
1195 *
1196 * The following function implements the computation of the diagonal of the
1197 * operator. Computing matrix entries of a matrix-free operator evaluation
1198 * turns out to be more complicated than evaluating the
1199 * operator. Fundamentally, we could obtain a matrix representation of the
1200 * operator by applying the operator on <i>all</i> unit vectors. Of course,
1201 * that would be very inefficient since we would need to perform <i>n</i>
1202 * operator evaluations to retrieve the whole matrix. Furthermore, this
1203 * approach would completely ignore the matrix sparsity. On an individual
1204 * cell, however, this is the way to go and actually not that inefficient as
1205 * there usually is a coupling between all degrees of freedom inside the
1206 * cell.
1207 *
1208
1209 *
1210 * We first initialize the diagonal vector to the correct parallel
1211 * layout. This vector is encapsulated in a member called
1212 * inverse_diagonal_entries of type DiagonalMatrix in the base class
1213 * MatrixFreeOperators::Base. This member is a shared pointer that we first
1214 * need to initialize and then get the vector representing the diagonal
1215 * entries in the matrix. As to the actual diagonal computation, we again
1216 * use the cell_loop infrastructure of MatrixFree to invoke a local worker
1217 * routine called local_compute_diagonal(). Since we will only write into a
1218 * vector but not have any source vector, we put a dummy argument of type
1219 * <tt>unsigned int</tt> in place of the source vector to confirm with the
1220 * cell_loop interface. After the loop, we need to set the vector entries
1221 * subject to Dirichlet boundary conditions to one (either those on the
1222 * boundary described by the AffineConstraints object inside MatrixFree or
1223 * the indices at the interface between different grid levels in adaptive
1224 * multigrid). This is done through the function
1226 * with the setting in the matrix-vector product provided by the Base
1227 * operator. Finally, we need to invert the diagonal entries which is the
1228 * form required by the Chebyshev smoother based on the Jacobi iteration. In
1229 * the loop, we assert that all entries are non-zero, because they should
1230 * either have obtained a positive contribution from integrals or be
1231 * constrained and treated by @p set_constrained_entries_to_one() following
1232 * cell_loop.
1233 *
1234 * @code
1235 *   template <int dim, int fe_degree, typename number>
1236 *   void LaplaceOperator<dim, fe_degree, number>::compute_diagonal()
1237 *   {
1238 *   this->inverse_diagonal_entries.reset(
1240 *   LinearAlgebra::distributed::Vector<number> &inverse_diagonal =
1241 *   this->inverse_diagonal_entries->get_vector();
1242 *   this->data->initialize_dof_vector(inverse_diagonal);
1243 *   unsigned int dummy = 0;
1244 *   this->data->cell_loop(&LaplaceOperator::local_compute_diagonal,
1245 *   this,
1246 *   inverse_diagonal,
1247 *   dummy);
1248 *  
1249 *   this->set_constrained_entries_to_one(inverse_diagonal);
1250 *  
1251 *   for (unsigned int i = 0; i < inverse_diagonal.locally_owned_size(); ++i)
1252 *   {
1253 *   Assert(inverse_diagonal.local_element(i) > 0.,
1254 *   ExcMessage("No diagonal entry in a positive definite operator "
1255 *   "should be zero"));
1256 *   inverse_diagonal.local_element(i) =
1257 *   1. / inverse_diagonal.local_element(i);
1258 *   }
1259 *   }
1260 *  
1261 *  
1262 *  
1263 * @endcode
1264 *
1265 * In the local compute loop, we compute the diagonal by a loop over all
1266 * columns in the local matrix and putting the entry 1 in the <i>i</i>th
1267 * slot and a zero entry in all other slots, i.e., we apply the cell-wise
1268 * differential operator on one unit vector at a time. The inner part
1269 * invoking FEEvaluation::evaluate, the loop over quadrature points, and
1270 * FEEvalution::integrate, is exactly the same as in the local_apply
1271 * function. Afterwards, we pick out the <i>i</i>th entry of the local
1272 * result and put it to a temporary storage (as we overwrite all entries in
1273 * the array behind FEEvaluation::get_dof_value() with the next loop
1274 * iteration). Finally, the temporary storage is written to the destination
1275 * vector. Note how we use FEEvaluation::get_dof_value() and
1276 * FEEvaluation::submit_dof_value() to read and write to the data field that
1277 * FEEvaluation uses for the integration on the one hand and writes into the
1278 * global vector on the other hand.
1279 *
1280
1281 *
1282 * Given that we are only interested in the matrix diagonal, we simply throw
1283 * away all other entries of the local matrix that have been computed along
1284 * the way. While it might seem wasteful to compute the complete cell matrix
1285 * and then throw away everything but the diagonal, the integration are so
1286 * efficient that the computation does not take too much time. Note that the
1287 * complexity of operator evaluation per element is @f$\mathcal
1288 * O((p+1)^{d+1})@f$ for polynomial degree @f$k@f$, so computing the whole matrix
1289 * costs us @f$\mathcal O((p+1)^{2d+1})@f$ operations, not too far away from
1290 * @f$\mathcal O((p+1)^{2d})@f$ complexity for computing the diagonal with
1291 * FEValues. Since FEEvaluation is also considerably faster due to
1292 * vectorization and other optimizations, the diagonal computation with this
1293 * function is actually the fastest (simple) variant. (It would be possible
1294 * to compute the diagonal with sum factorization techniques in @f$\mathcal
1295 * O((p+1)^{d+1})@f$ operations involving specifically adapted
1296 * kernels&mdash;but since such kernels are only useful in that particular
1297 * context and the diagonal computation is typically not on the critical
1298 * path, they have not been implemented in deal.II.)
1299 *
1300
1301 *
1302 * Note that the code that calls distribute_local_to_global on the vector to
1303 * accumulate the diagonal entries into the global matrix has some
1304 * limitations. For operators with hanging node constraints that distribute
1305 * an integral contribution of a constrained DoF to several other entries
1306 * inside the distribute_local_to_global call, the vector interface used
1307 * here does not exactly compute the diagonal entries, but lumps some
1308 * contributions located on the diagonal of the local matrix that would end
1309 * up in a off-diagonal position of the global matrix to the diagonal. The
1310 * result is correct up to discretization accuracy as explained in <a
1311 * href="http://dx.doi.org/10.4208/cicp.101214.021015a">Kormann (2016),
1312 * section 5.3</a>, but not mathematically equal. In this tutorial program,
1313 * no harm can happen because the diagonal is only used for the multigrid
1314 * level matrices where no hanging node constraints appear.
1315 *
1316 * @code
1317 *   template <int dim, int fe_degree, typename number>
1318 *   void LaplaceOperator<dim, fe_degree, number>::local_compute_diagonal(
1319 *   const MatrixFree<dim, number> &data,
1321 *   const unsigned int &,
1322 *   const std::pair<unsigned int, unsigned int> &cell_range) const
1323 *   {
1325 *  
1326 *   AlignedVector<VectorizedArray<number>> diagonal(phi.dofs_per_cell);
1327 *  
1328 *   for (unsigned int cell = cell_range.first; cell < cell_range.second; ++cell)
1329 *   {
1330 *   AssertDimension(coefficient.size(0), data.n_cell_batches());
1331 *   AssertDimension(coefficient.size(1), phi.n_q_points);
1332 *  
1333 *   phi.reinit(cell);
1334 *   for (unsigned int i = 0; i < phi.dofs_per_cell; ++i)
1335 *   {
1336 *   for (unsigned int j = 0; j < phi.dofs_per_cell; ++j)
1337 *   phi.submit_dof_value(VectorizedArray<number>(), j);
1338 *   phi.submit_dof_value(make_vectorized_array<number>(1.), i);
1339 *  
1340 *   phi.evaluate(EvaluationFlags::gradients);
1341 *   for (const unsigned int q : phi.quadrature_point_indices())
1342 *   phi.submit_gradient(coefficient(cell, q) * phi.get_gradient(q),
1343 *   q);
1344 *   phi.integrate(EvaluationFlags::gradients);
1345 *   diagonal[i] = phi.get_dof_value(i);
1346 *   }
1347 *   for (unsigned int i = 0; i < phi.dofs_per_cell; ++i)
1348 *   phi.submit_dof_value(diagonal[i], i);
1349 *   phi.distribute_local_to_global(dst);
1350 *   }
1351 *   }
1352 *  
1353 *  
1354 *  
1355 * @endcode
1356 *
1357 *
1358 * <a name="step_37-LaplaceProblemclass"></a>
1359 * <h3>LaplaceProblem class</h3>
1360 *
1361
1362 *
1363 * This class is based on the one in @ref step_16 "step-16". However, we replaced the
1364 * SparseMatrix<double> class by our matrix-free implementation, which means
1365 * that we can also skip the sparsity patterns. Notice that we define the
1366 * LaplaceOperator class with the degree of finite element as template
1367 * argument (the value is defined at the top of the file), and that we use
1368 * float numbers for the multigrid level matrices.
1369 *
1370
1371 *
1372 * The class also has a member variable to keep track of all the detailed
1373 * timings for setting up the entire chain of data before we actually go
1374 * about solving the problem. In addition, there is an output stream (that
1375 * is disabled by default) that can be used to output details for the
1376 * individual setup operations instead of the summary only that is printed
1377 * out by default.
1378 *
1379
1380 *
1381 * Since this program is designed to be used with MPI, we also provide the
1382 * usual @p pcout output stream that only prints the information of the
1383 * processor with MPI rank 0. The grid used for this programs can either be
1384 * a distributed triangulation based on p4est (in case deal.II is configured
1385 * to use p4est), otherwise it is a serial grid that only runs without MPI.
1386 *
1387 * @code
1388 *   template <int dim>
1389 *   class LaplaceProblem
1390 *   {
1391 *   public:
1392 *   LaplaceProblem();
1393 *   void run();
1394 *  
1395 *   private:
1396 *   void setup_system();
1397 *   void assemble_rhs();
1398 *   void solve();
1399 *   void output_results(const unsigned int cycle) const;
1400 *  
1401 *   #ifdef DEAL_II_WITH_P4EST
1403 *   #else
1405 *   #endif
1406 *  
1407 *   FE_Q<dim> fe;
1408 *   DoFHandler<dim> dof_handler;
1409 *  
1411 *  
1412 *   AffineConstraints<double> constraints;
1413 *   using SystemMatrixType =
1414 *   LaplaceOperator<dim, degree_finite_element, double>;
1415 *   SystemMatrixType system_matrix;
1416 *  
1417 *   MGConstrainedDoFs mg_constrained_dofs;
1418 *   using LevelMatrixType = LaplaceOperator<dim, degree_finite_element, float>;
1419 *   MGLevelObject<LevelMatrixType> mg_matrices;
1420 *  
1423 *  
1424 *   double setup_time;
1425 *   ConditionalOStream pcout;
1426 *   ConditionalOStream time_details;
1427 *   };
1428 *  
1429 *  
1430 *  
1431 * @endcode
1432 *
1433 * When we initialize the finite element, we of course have to use the
1434 * degree specified at the top of the file as well (otherwise, an exception
1435 * will be thrown at some point, since the computational kernel defined in
1436 * the templated LaplaceOperator class and the information from the finite
1437 * element read out by MatrixFree will not match). The constructor of the
1438 * triangulation needs to set an additional flag that tells the grid to
1439 * conform to the 2:1 cell balance over vertices, which is needed for the
1440 * convergence of the geometric multigrid routines. For the distributed
1441 * grid, we also need to specifically enable the multigrid hierarchy.
1442 *
1443 * @code
1444 *   template <int dim>
1445 *   LaplaceProblem<dim>::LaplaceProblem()
1446 *   #ifdef DEAL_II_WITH_P4EST
1447 *   : triangulation(MPI_COMM_WORLD,
1450 *   dim>::construct_multigrid_hierarchy)
1451 *   #else
1453 *   #endif
1454 *   , fe(degree_finite_element)
1455 *   , dof_handler(triangulation)
1456 *   , setup_time(0.)
1457 *   , pcout(std::cout, Utilities::MPI::this_mpi_process(MPI_COMM_WORLD) == 0)
1458 * @endcode
1459 *
1460 * The LaplaceProblem class holds an additional output stream that
1461 * collects detailed timings about the setup phase. This stream, called
1462 * time_details, is disabled by default through the @p false argument
1463 * specified here. For detailed timings, removing the @p false argument
1464 * prints all the details.
1465 *
1466 * @code
1467 *   , time_details(std::cout,
1468 *   false &&
1469 *   Utilities::MPI::this_mpi_process(MPI_COMM_WORLD) == 0)
1470 *   {}
1471 *  
1472 *  
1473 *  
1474 * @endcode
1475 *
1476 *
1477 * <a name="step_37-LaplaceProblemsetup_system"></a>
1478 * <h4>LaplaceProblem::setup_system</h4>
1479 *
1480
1481 *
1482 * The setup stage is in analogy to @ref step_16 "step-16" with relevant changes due to the
1483 * LaplaceOperator class. The first thing to do is to set up the DoFHandler,
1484 * including the degrees of freedom for the multigrid levels, and to
1485 * initialize constraints from hanging nodes and homogeneous Dirichlet
1486 * conditions. Since we intend to use this programs in %parallel with MPI,
1487 * we need to make sure that the constraints get to know the locally
1488 * relevant degrees of freedom, otherwise the storage would explode when
1489 * using more than a few hundred millions of degrees of freedom, see
1490 * @ref step_40 "step-40".
1491 *
1492
1493 *
1494 * Once we have created the multigrid dof_handler and the constraints, we
1495 * can call the reinit function for the global matrix operator as well as
1496 * each level of the multigrid scheme. The main action is to set up the
1497 * <code> MatrixFree </code> instance for the problem. The base class of the
1498 * <code>LaplaceOperator</code> class, MatrixFreeOperators::Base, is
1499 * initialized with a shared pointer to MatrixFree object. This way, we can
1500 * simply create it here and then pass it on to the system matrix and level
1501 * matrices, respectively. For setting up MatrixFree, we need to activate
1502 * the update flag in the AdditionalData field of MatrixFree that enables
1503 * the storage of quadrature point coordinates in real space (by default, it
1504 * only caches data for gradients (inverse transposed Jacobians) and JxW
1505 * values). Note that if we call the reinit function without specifying the
1506 * level (i.e., giving <code>level = numbers::invalid_unsigned_int</code>),
1507 * MatrixFree constructs a loop over the active cells. In this tutorial, we
1508 * do not use threads in addition to MPI, which is why we explicitly disable
1510 * MatrixFree::AdditionalData::none. Finally, the coefficient is evaluated
1511 * and vectors are initialized as explained above.
1512 *
1513 * @code
1514 *   template <int dim>
1515 *   void LaplaceProblem<dim>::setup_system()
1516 *   {
1517 *   Timer time;
1518 *   setup_time = 0;
1519 *   {
1520 *   system_matrix.clear();
1521 *   mg_matrices.clear_elements();
1522 *  
1523 *   dof_handler.distribute_dofs(fe);
1524 *   dof_handler.distribute_mg_dofs();
1525 *  
1526 *   pcout << "Number of degrees of freedom: " << dof_handler.n_dofs()
1527 *   << std::endl;
1528 *  
1529 *   constraints.clear();
1530 *   constraints.reinit(dof_handler.locally_owned_dofs(),
1531 *   DoFTools::extract_locally_relevant_dofs(dof_handler));
1532 *   DoFTools::make_hanging_node_constraints(dof_handler, constraints);
1534 *   mapping, dof_handler, 0, Functions::ZeroFunction<dim>(), constraints);
1535 *   constraints.close();
1536 *   }
1537 *   setup_time += time.wall_time();
1538 *   time_details << "Distribute DoFs & B.C. (CPU/wall) " << time.cpu_time()
1539 *   << "s/" << time.wall_time() << 's' << std::endl;
1540 *   time.restart();
1541 *   {
1542 *   {
1543 *   typename MatrixFree<dim, double>::AdditionalData additional_data;
1544 *   additional_data.tasks_parallel_scheme =
1546 *   additional_data.mapping_update_flags =
1548 *   std::shared_ptr<MatrixFree<dim, double>> system_mf_storage(
1549 *   new MatrixFree<dim, double>());
1550 *   system_mf_storage->reinit(mapping,
1551 *   dof_handler,
1552 *   constraints,
1553 *   QGauss<1>(fe.degree + 1),
1554 *   additional_data);
1555 *   system_matrix.initialize(system_mf_storage);
1556 *   }
1557 *  
1558 *   system_matrix.evaluate_coefficient(Coefficient<dim>());
1559 *  
1560 *   system_matrix.initialize_dof_vector(solution);
1561 *   system_matrix.initialize_dof_vector(system_rhs);
1562 *   }
1563 *   setup_time += time.wall_time();
1564 *   time_details << "Setup matrix-free system (CPU/wall) " << time.cpu_time()
1565 *   << "s/" << time.wall_time() << 's' << std::endl;
1566 *   time.restart();
1567 *  
1568 * @endcode
1569 *
1570 * Next, initialize the matrices for the multigrid method on all the
1571 * levels. The data structure MGConstrainedDoFs keeps information about
1572 * the indices subject to boundary conditions as well as the indices on
1573 * edges between different refinement levels as described in the @ref step_16 "step-16"
1574 * tutorial program. We then go through the levels of the mesh and
1575 * construct the constraints and matrices on each level. These follow
1576 * closely the construction of the system matrix on the original mesh,
1577 * except the slight difference in naming when accessing information on
1578 * the levels rather than the active cells.
1579 *
1580 * @code
1581 *   {
1582 *   const unsigned int nlevels = triangulation.n_global_levels();
1583 *   mg_matrices.resize(0, nlevels - 1);
1584 *  
1585 *   const std::set<types::boundary_id> dirichlet_boundary_ids = {0};
1586 *   mg_constrained_dofs.initialize(dof_handler);
1587 *   mg_constrained_dofs.make_zero_boundary_constraints(
1588 *   dof_handler, dirichlet_boundary_ids);
1589 *  
1590 *   for (unsigned int level = 0; level < nlevels; ++level)
1591 *   {
1592 *   AffineConstraints<double> level_constraints(
1593 *   dof_handler.locally_owned_mg_dofs(level),
1595 *   for (const types::global_dof_index dof_index :
1596 *   mg_constrained_dofs.get_boundary_indices(level))
1597 *   level_constraints.constrain_dof_to_zero(dof_index);
1598 *   level_constraints.close();
1599 *  
1600 *   typename MatrixFree<dim, float>::AdditionalData additional_data;
1601 *   additional_data.tasks_parallel_scheme =
1603 *   additional_data.mapping_update_flags =
1605 *   additional_data.mg_level = level;
1606 *   std::shared_ptr<MatrixFree<dim, float>> mg_mf_storage_level =
1607 *   std::make_shared<MatrixFree<dim, float>>();
1608 *   mg_mf_storage_level->reinit(mapping,
1609 *   dof_handler,
1610 *   level_constraints,
1611 *   QGauss<1>(fe.degree + 1),
1612 *   additional_data);
1613 *  
1614 *   mg_matrices[level].initialize(mg_mf_storage_level,
1615 *   mg_constrained_dofs,
1616 *   level);
1617 *   mg_matrices[level].evaluate_coefficient(Coefficient<dim>());
1618 *   }
1619 *   }
1620 *   setup_time += time.wall_time();
1621 *   time_details << "Setup matrix-free levels (CPU/wall) " << time.cpu_time()
1622 *   << "s/" << time.wall_time() << 's' << std::endl;
1623 *   }
1624 *  
1625 *  
1626 *  
1627 * @endcode
1628 *
1629 *
1630 * <a name="step_37-LaplaceProblemassemble_rhs"></a>
1631 * <h4>LaplaceProblem::assemble_rhs</h4>
1632 *
1633
1634 *
1635 * The assemble function is very simple since all we have to do is to
1636 * assemble the right hand side. Thanks to FEEvaluation and all the data
1637 * cached in the MatrixFree class, which we query from
1638 * MatrixFreeOperators::Base, this can be done in a few lines. Since this
1639 * call is not wrapped into a MatrixFree::cell_loop (which would be an
1640 * alternative), we must not forget to call compress() at the end of the
1641 * assembly to send all the contributions of the right hand side to the
1642 * owner of the respective degree of freedom.
1643 *
1644 * @code
1645 *   template <int dim>
1646 *   void LaplaceProblem<dim>::assemble_rhs()
1647 *   {
1648 *   Timer time;
1649 *  
1650 *   system_rhs = 0;
1652 *   *system_matrix.get_matrix_free());
1653 *   for (unsigned int cell = 0;
1654 *   cell < system_matrix.get_matrix_free()->n_cell_batches();
1655 *   ++cell)
1656 *   {
1657 *   phi.reinit(cell);
1658 *   for (const unsigned int q : phi.quadrature_point_indices())
1659 *   phi.submit_value(make_vectorized_array<double>(1.0), q);
1660 *   phi.integrate(EvaluationFlags::values);
1661 *   phi.distribute_local_to_global(system_rhs);
1662 *   }
1663 *   system_rhs.compress(VectorOperation::add);
1664 *  
1665 *   setup_time += time.wall_time();
1666 *   time_details << "Assemble right hand side (CPU/wall) " << time.cpu_time()
1667 *   << "s/" << time.wall_time() << 's' << std::endl;
1668 *   }
1669 *  
1670 *  
1671 *  
1672 * @endcode
1673 *
1674 *
1675 * <a name="step_37-LaplaceProblemsolve"></a>
1676 * <h4>LaplaceProblem::solve</h4>
1677 *
1678
1679 *
1680 * The solution process is similar as in @ref step_16 "step-16". We start with the setup of
1681 * the transfer. For LinearAlgebra::distributed::Vector, there is a very
1682 * fast transfer class called MGTransferMatrixFree that does the
1683 * interpolation between the grid levels with the same fast sum
1684 * factorization kernels that get also used in FEEvaluation.
1685 *
1686 * @code
1687 *   template <int dim>
1688 *   void LaplaceProblem<dim>::solve()
1689 *   {
1690 *   Timer time;
1691 *   MGTransferMatrixFree<dim, float> mg_transfer(mg_constrained_dofs);
1692 *   mg_transfer.build(dof_handler);
1693 *   setup_time += time.wall_time();
1694 *   time_details << "MG build transfer time (CPU/wall) " << time.cpu_time()
1695 *   << "s/" << time.wall_time() << "s\n";
1696 *   time.restart();
1697 *  
1698 * @endcode
1699 *
1700 * As a smoother, this tutorial program uses a Chebyshev iteration instead
1701 * of SOR in @ref step_16 "step-16". (SOR would be very difficult to implement because we
1702 * do not have the matrix elements available explicitly, and it is
1703 * difficult to make it work efficiently in %parallel.) The smoother is
1704 * initialized with our level matrices and the mandatory additional data
1705 * for the Chebyshev smoother. We use a relatively high degree here (5),
1706 * since matrix-vector products are comparably cheap. We choose to smooth
1707 * out a range of @f$[1.2 \hat{\lambda}_{\max}/15,1.2 \hat{\lambda}_{\max}]@f$
1708 * in the smoother where @f$\hat{\lambda}_{\max}@f$ is an estimate of the
1709 * largest eigenvalue (the factor 1.2 is applied inside
1710 * PreconditionChebyshev). In order to compute that eigenvalue, the
1711 * Chebyshev initialization performs a few steps of a CG algorithm
1712 * without preconditioner. Since the highest eigenvalue is usually the
1713 * easiest one to find and a rough estimate is enough, we choose 10
1714 * iterations. Finally, we also set the inner preconditioner type in the
1715 * Chebyshev method which is a Jacobi iteration. This is represented by
1716 * the DiagonalMatrix class that gets the inverse diagonal entry provided
1717 * by our LaplaceOperator class.
1718 *
1719
1720 *
1721 * On level zero, we initialize the smoother differently because we want
1722 * to use the Chebyshev iteration as a solver. PreconditionChebyshev
1723 * allows the user to switch to solver mode where the number of iterations
1724 * is internally chosen to the correct value. In the additional data
1725 * object, this setting is activated by choosing the polynomial degree to
1726 * @p numbers::invalid_unsigned_int. The algorithm will then attack all
1727 * eigenvalues between the smallest and largest one in the coarse level
1728 * matrix. The number of steps in the Chebyshev smoother are chosen such
1729 * that the Chebyshev convergence estimates guarantee to reduce the
1730 * residual by the number specified in the variable @p
1731 * smoothing_range. Note that for solving, @p smoothing_range is a
1732 * relative tolerance and chosen smaller than one, in this case, we select
1733 * three orders of magnitude, whereas it is a number larger than 1 when
1734 * only selected eigenvalues are smoothed.
1735 *
1736
1737 *
1738 * From a computational point of view, the Chebyshev iteration is a very
1739 * attractive coarse grid solver as long as the coarse size is
1740 * moderate. This is because the Chebyshev method performs only
1741 * matrix-vector products and vector updates, which typically parallelize
1742 * better to the largest cluster size with more than a few tens of
1743 * thousands of cores than inner product involved in other iterative
1744 * methods. The former involves only local communication between neighbors
1745 * in the (coarse) mesh, whereas the latter requires global communication
1746 * over all processors.
1747 *
1748 * @code
1749 *   using SmootherType =
1750 *   PreconditionChebyshev<LevelMatrixType,
1752 *   mg::SmootherRelaxation<SmootherType,
1754 *   mg_smoother;
1756 *   smoother_data.resize(0, triangulation.n_global_levels() - 1);
1757 *   for (unsigned int level = 0; level < triangulation.n_global_levels();
1758 *   ++level)
1759 *   {
1760 *   if (level > 0)
1761 *   {
1762 *   smoother_data[level].smoothing_range = 15.;
1763 *   smoother_data[level].degree = 5;
1764 *   smoother_data[level].eig_cg_n_iterations = 10;
1765 *   }
1766 *   else
1767 *   {
1768 *   smoother_data[0].smoothing_range = 1e-3;
1769 *   smoother_data[0].degree = numbers::invalid_unsigned_int;
1770 *   smoother_data[0].eig_cg_n_iterations = mg_matrices[0].m();
1771 *   }
1772 *   mg_matrices[level].compute_diagonal();
1773 *   smoother_data[level].preconditioner =
1774 *   mg_matrices[level].get_matrix_diagonal_inverse();
1775 *   }
1776 *   mg_smoother.initialize(mg_matrices, smoother_data);
1777 *  
1779 *   mg_coarse;
1780 *   mg_coarse.initialize(mg_smoother);
1781 *  
1782 * @endcode
1783 *
1784 * The next step is to set up the interface matrices that are needed for the
1785 * case with hanging nodes. The adaptive multigrid realization in deal.II
1786 * implements an approach called local smoothing. This means that the
1787 * smoothing on the finest level only covers the local part of the mesh
1788 * defined by the fixed (finest) grid level and ignores parts of the
1789 * computational domain where the terminal cells are coarser than this
1790 * level. As the method progresses to coarser levels, more and more of the
1791 * global mesh will be covered. At some coarser level, the whole mesh will
1792 * be covered. Since all level matrices in the multigrid method cover a
1793 * single level in the mesh, no hanging nodes appear on the level matrices.
1794 * At the interface between multigrid levels, homogeneous Dirichlet boundary
1795 * conditions are set while smoothing. When the residual is transferred to
1796 * the next coarser level, however, the coupling over the multigrid
1797 * interface needs to be taken into account. This is done by the so-called
1798 * interface (or edge) matrices that compute the part of the residual that
1799 * is missed by the level matrix with
1800 * homogeneous Dirichlet conditions. We refer to the @ref mg_paper
1801 * "Multigrid paper by Janssen and Kanschat" for more details.
1802 *
1803
1804 *
1805 * For the implementation of those interface matrices, there is already a
1806 * pre-defined class MatrixFreeOperators::MGInterfaceOperator that wraps
1808 * MatrixFreeOperators::Base::vmult_interface_up() in a new class with @p
1809 * vmult() and @p Tvmult() operations (that were originally written for
1810 * matrices, hence expecting those names). Note that vmult_interface_down
1811 * is used during the restriction phase of the multigrid V-cycle, whereas
1812 * vmult_interface_up is used during the prolongation phase.
1813 *
1814
1815 *
1816 * Once the interface matrix is created, we set up the remaining Multigrid
1817 * preconditioner infrastructure in complete analogy to @ref step_16 "step-16" to obtain
1818 * a @p preconditioner object that can be applied to a matrix.
1819 *
1820 * @code
1821 *   mg::Matrix<LinearAlgebra::distributed::Vector<float>> mg_matrix(
1822 *   mg_matrices);
1823 *  
1824 *   MGLevelObject<MatrixFreeOperators::MGInterfaceOperator<LevelMatrixType>>
1825 *   mg_interface_matrices;
1826 *   mg_interface_matrices.resize(0, triangulation.n_global_levels() - 1);
1827 *   for (unsigned int level = 0; level < triangulation.n_global_levels();
1828 *   ++level)
1829 *   mg_interface_matrices[level].initialize(mg_matrices[level]);
1830 *   mg::Matrix<LinearAlgebra::distributed::Vector<float>> mg_interface(
1831 *   mg_interface_matrices);
1832 *  
1833 *   Multigrid<LinearAlgebra::distributed::Vector<float>> mg(
1834 *   mg_matrix, mg_coarse, mg_transfer, mg_smoother, mg_smoother);
1835 *   mg.set_edge_matrices(mg_interface, mg_interface);
1836 *  
1837 *   PreconditionMG<dim,
1838 *   LinearAlgebra::distributed::Vector<float>,
1839 *   MGTransferMatrixFree<dim, float>>
1840 *   preconditioner(dof_handler, mg, mg_transfer);
1841 *  
1842 * @endcode
1843 *
1844 * The setup of the multigrid routines is quite easy and one cannot see
1845 * any difference in the solve process as compared to @ref step_16 "step-16". All the
1846 * magic is hidden behind the implementation of the LaplaceOperator::vmult
1847 * operation. Note that we print out the solve time and the accumulated
1848 * setup time through standard out, i.e., in any case, whereas detailed
1849 * times for the setup operations are only printed in case the flag for
1850 * detail_times in the constructor is changed.
1851 *
1852
1853 *
1854 *
1855 * @code
1856 *   SolverControl solver_control(100, 1e-12 * system_rhs.l2_norm());
1857 *   SolverCG<LinearAlgebra::distributed::Vector<double>> cg(solver_control);
1858 *   setup_time += time.wall_time();
1859 *   time_details << "MG build smoother time (CPU/wall) " << time.cpu_time()
1860 *   << "s/" << time.wall_time() << "s\n";
1861 *   pcout << "Total setup time (wall) " << setup_time << "s\n";
1862 *  
1863 *   time.reset();
1864 *   time.start();
1865 *   constraints.set_zero(solution);
1866 *   cg.solve(system_matrix, solution, system_rhs, preconditioner);
1867 *  
1868 *   constraints.distribute(solution);
1869 *  
1870 *   pcout << "Time solve (" << solver_control.last_step() << " iterations)"
1871 *   << (solver_control.last_step() < 10 ? " " : " ") << "(CPU/wall) "
1872 *   << time.cpu_time() << "s/" << time.wall_time() << "s\n";
1873 *   }
1874 *  
1875 *  
1876 *  
1877 * @endcode
1878 *
1879 *
1880 * <a name="step_37-LaplaceProblemoutput_results"></a>
1881 * <h4>LaplaceProblem::output_results</h4>
1882 *
1883
1884 *
1885 * Here is the data output, which is a simplified version of @ref step_5 "step-5". We use
1886 * the standard VTU (= compressed VTK) output for each grid produced in the
1887 * refinement process. In addition, we use a compression algorithm that is
1888 * optimized for speed rather than disk usage. The default setting (which
1889 * optimizes for disk usage) makes saving the output take about 4 times as
1890 * long as running the linear solver, while setting
1891 * DataOutBase::CompressionLevel to
1892 * best_speed lowers this to only one fourth the time
1893 * of the linear solve.
1894 *
1895
1896 *
1897 * We disable the output when the mesh gets too large. A variant of this
1898 * program has been run on hundreds of thousands MPI ranks with as many as
1899 * 100 billion grid cells, which is not directly accessible to classical
1900 * visualization tools.
1901 *
1902 * @code
1903 *   template <int dim>
1904 *   void LaplaceProblem<dim>::output_results(const unsigned int cycle) const
1905 *   {
1906 *   Timer time;
1907 *   if (triangulation.n_global_active_cells() > 1000000)
1908 *   return;
1909 *  
1910 *   DataOut<dim> data_out;
1911 *  
1912 *   solution.update_ghost_values();
1913 *   data_out.attach_dof_handler(dof_handler);
1914 *   data_out.add_data_vector(solution, "solution");
1915 *   data_out.build_patches(mapping);
1916 *  
1917 *   DataOutBase::VtkFlags flags;
1919 *   data_out.set_flags(flags);
1920 *   data_out.write_vtu_with_pvtu_record(
1921 *   "./", "solution", cycle, MPI_COMM_WORLD, 3);
1922 *  
1923 *   time_details << "Time write output (CPU/wall) " << time.cpu_time()
1924 *   << "s/" << time.wall_time() << "s\n";
1925 *   }
1926 *  
1927 *  
1928 *  
1929 * @endcode
1930 *
1931 *
1932 * <a name="step_37-LaplaceProblemrun"></a>
1933 * <h4>LaplaceProblem::run</h4>
1934 *
1935
1936 *
1937 * The function that runs the program is very similar to the one in
1938 * @ref step_16 "step-16". We do few refinement steps in 3d compared to 2d, but that's
1939 * it.
1940 *
1941
1942 *
1943 * Before we run the program, we output some information about the detected
1944 * vectorization level as discussed in the introduction.
1945 *
1946 * @code
1947 *   template <int dim>
1948 *   void LaplaceProblem<dim>::run()
1949 *   {
1950 *   {
1951 *   const unsigned int n_vect_doubles = VectorizedArray<double>::size();
1952 *   const unsigned int n_vect_bits = 8 * sizeof(double) * n_vect_doubles;
1953 *  
1954 *   pcout << "Vectorization over " << n_vect_doubles
1955 *   << " doubles = " << n_vect_bits << " bits ("
1956 *   << Utilities::System::get_current_vectorization_level() << ')'
1957 *   << std::endl;
1958 *   }
1959 *  
1960 *   for (unsigned int cycle = 0; cycle < 9 - dim; ++cycle)
1961 *   {
1962 *   pcout << "Cycle " << cycle << std::endl;
1963 *  
1964 *   if (cycle == 0)
1965 *   {
1966 *   GridGenerator::hyper_cube(triangulation, 0., 1.);
1967 *   triangulation.refine_global(3 - dim);
1968 *   }
1969 *   triangulation.refine_global(1);
1970 *   setup_system();
1971 *   assemble_rhs();
1972 *   solve();
1973 *   output_results(cycle);
1974 *   pcout << std::endl;
1975 *   };
1976 *   }
1977 *   } // namespace Step37
1978 *  
1979 *  
1980 *  
1981 * @endcode
1982 *
1983 *
1984 * <a name="step_37-Thecodemaincodefunction"></a>
1985 * <h3>The <code>main</code> function</h3>
1986 *
1987
1988 *
1989 * Apart from the fact that we set up the MPI framework according to @ref step_40 "step-40",
1990 * there are no surprises in the main function.
1991 *
1992 * @code
1993 *   int main(int argc, char *argv[])
1994 *   {
1995 *   try
1996 *   {
1997 *   using namespace Step37;
1998 *  
1999 *   Utilities::MPI::MPI_InitFinalize mpi_init(argc, argv, 1);
2000 *  
2001 *   LaplaceProblem<dimension> laplace_problem;
2002 *   laplace_problem.run();
2003 *   }
2004 *   catch (std::exception &exc)
2005 *   {
2006 *   std::cerr << std::endl
2007 *   << std::endl
2008 *   << "----------------------------------------------------"
2009 *   << std::endl;
2010 *   std::cerr << "Exception on processing: " << std::endl
2011 *   << exc.what() << std::endl
2012 *   << "Aborting!" << std::endl
2013 *   << "----------------------------------------------------"
2014 *   << std::endl;
2015 *   return 1;
2016 *   }
2017 *   catch (...)
2018 *   {
2019 *   std::cerr << std::endl
2020 *   << std::endl
2021 *   << "----------------------------------------------------"
2022 *   << std::endl;
2023 *   std::cerr << "Unknown exception!" << std::endl
2024 *   << "Aborting!" << std::endl
2025 *   << "----------------------------------------------------"
2026 *   << std::endl;
2027 *   return 1;
2028 *   }
2029 *  
2030 *   return 0;
2031 *   }
2032 * @endcode
2033<a name="step_37-Results"></a><h1>Results</h1>
2034
2035
2036<a name="step_37-Programoutput"></a><h3>Program output</h3>
2037
2038
2039Since this example solves the same problem as @ref step_5 "step-5" (except for
2040a different coefficient), there is little to say about the
2041solution. We show a picture anyway, illustrating the size of the
2042solution through both isocontours and volume rendering:
2043
2044<img src="https://www.dealii.org/images/steps/developer/step-37.solution.png" alt="">
2045
2046Of more interest is to evaluate some aspects of the multigrid solver.
2047When we run this program in 2D for quadratic (@f$Q_2@f$) elements, we get the
2048following output (when run on one core in release mode):
2049@code
2050Vectorization over 2 doubles = 128 bits (SSE2)
2051Cycle 0
2052Number of degrees of freedom: 81
2053Total setup time (wall) 0.00159788s
2054Time solve (6 iterations) (CPU/wall) 0.000951s/0.000951052s
2055
2056Cycle 1
2057Number of degrees of freedom: 289
2058Total setup time (wall) 0.00114608s
2059Time solve (6 iterations) (CPU/wall) 0.000935s/0.000934839s
2060
2061Cycle 2
2062Number of degrees of freedom: 1089
2063Total setup time (wall) 0.00244665s
2064Time solve (6 iterations) (CPU/wall) 0.00207s/0.002069s
2065
2066Cycle 3
2067Number of degrees of freedom: 4225
2068Total setup time (wall) 0.00678205s
2069Time solve (6 iterations) (CPU/wall) 0.005616s/0.00561595s
2070
2071Cycle 4
2072Number of degrees of freedom: 16641
2073Total setup time (wall) 0.0241671s
2074Time solve (6 iterations) (CPU/wall) 0.019543s/0.0195441s
2075
2076Cycle 5
2077Number of degrees of freedom: 66049
2078Total setup time (wall) 0.0967851s
2079Time solve (6 iterations) (CPU/wall) 0.07457s/0.0745709s
2080
2081Cycle 6
2082Number of degrees of freedom: 263169
2083Total setup time (wall) 0.346374s
2084Time solve (6 iterations) (CPU/wall) 0.260042s/0.265033s
2085@endcode
2086
2087As in @ref step_16 "step-16", we see that the number of CG iterations remains constant with
2088increasing number of degrees of freedom. A constant number of iterations
2089(together with optimal computational properties) means that the computing time
2090approximately quadruples as the problem size quadruples from one cycle to the
2091next. The code is also very efficient in terms of storage. Around 2-4 million
2092degrees of freedom fit into 1 GB of memory, see also the MPI results below. An
2093interesting fact is that solving one linear system is cheaper than the setup,
2094despite not building a matrix (approximately half of which is spent in the
2095DoFHandler::distribute_dofs() and DoFHandler::distribute_mg_dofs()
2096calls). This shows the high efficiency of this approach, but also that the
2097deal.II data structures are quite expensive to set up and the setup cost must
2098be amortized over several system solves.
2099
2100Not much changes if we run the program in three spatial dimensions. Since we
2101use uniform mesh refinement, we get eight times as many elements and
2102approximately eight times as many degrees of freedom with each cycle:
2103
2104@code
2105Vectorization over 2 doubles = 128 bits (SSE2)
2106Cycle 0
2107Number of degrees of freedom: 125
2108Total setup time (wall) 0.00231099s
2109Time solve (6 iterations) (CPU/wall) 0.000692s/0.000922918s
2110
2111Cycle 1
2112Number of degrees of freedom: 729
2113Total setup time (wall) 0.00289083s
2114Time solve (6 iterations) (CPU/wall) 0.001534s/0.0024128s
2115
2116Cycle 2
2117Number of degrees of freedom: 4913
2118Total setup time (wall) 0.0143182s
2119Time solve (6 iterations) (CPU/wall) 0.010785s/0.0107841s
2120
2121Cycle 3
2122Number of degrees of freedom: 35937
2123Total setup time (wall) 0.087064s
2124Time solve (6 iterations) (CPU/wall) 0.063522s/0.06545s
2125
2126Cycle 4
2127Number of degrees of freedom: 274625
2128Total setup time (wall) 0.596306s
2129Time solve (6 iterations) (CPU/wall) 0.427757s/0.431765s
2130
2131Cycle 5
2132Number of degrees of freedom: 2146689
2133Total setup time (wall) 4.96491s
2134Time solve (6 iterations) (CPU/wall) 3.53126s/3.56142s
2135@endcode
2136
2137Since it is so easy, we look at what happens if we increase the polynomial
2138degree. When selecting the degree as four in 3D, i.e., on @f$\mathcal Q_4@f$
2139elements, by changing the line <code>const unsigned int
2140degree_finite_element=4;</code> at the top of the program, we get the
2141following program output:
2142
2143@code
2144Vectorization over 2 doubles = 128 bits (SSE2)
2145Cycle 0
2146Number of degrees of freedom: 729
2147Total setup time (wall) 0.00633097s
2148Time solve (6 iterations) (CPU/wall) 0.002829s/0.00379395s
2149
2150Cycle 1
2151Number of degrees of freedom: 4913
2152Total setup time (wall) 0.0174279s
2153Time solve (6 iterations) (CPU/wall) 0.012255s/0.012254s
2154
2155Cycle 2
2156Number of degrees of freedom: 35937
2157Total setup time (wall) 0.082655s
2158Time solve (6 iterations) (CPU/wall) 0.052362s/0.0523629s
2159
2160Cycle 3
2161Number of degrees of freedom: 274625
2162Total setup time (wall) 0.507943s
2163Time solve (6 iterations) (CPU/wall) 0.341811s/0.345788s
2164
2165Cycle 4
2166Number of degrees of freedom: 2146689
2167Total setup time (wall) 3.46251s
2168Time solve (7 iterations) (CPU/wall) 3.29638s/3.3265s
2169
2170Cycle 5
2171Number of degrees of freedom: 16974593
2172Total setup time (wall) 27.8989s
2173Time solve (7 iterations) (CPU/wall) 26.3705s/27.1077s
2174@endcode
2175
2176Since @f$\mathcal Q_4@f$ elements on a certain mesh correspond to @f$\mathcal Q_2@f$
2177elements on half the mesh size, we can compare the run time at cycle 4 with
2178fourth degree polynomials with cycle 5 using quadratic polynomials, both at
21792.1 million degrees of freedom. The surprising effect is that the solver for
2180@f$\mathcal Q_4@f$ element is actually slightly faster than for the quadratic
2181case, despite using one more linear iteration. The effect that higher-degree
2182polynomials are similarly fast or even faster than lower degree ones is one of
2183the main strengths of matrix-free operator evaluation through sum
2184factorization, see the <a
2185href="http://dx.doi.org/10.1016/j.compfluid.2012.04.012">matrix-free
2186paper</a>. This is fundamentally different to matrix-based methods that get
2187more expensive per unknown as the polynomial degree increases and the coupling
2188gets denser.
2189
2190In addition, also the setup gets a bit cheaper for higher order, which is
2191because fewer elements need to be set up.
2192
2193Finally, let us look at the timings with degree 8, which corresponds to
2194another round of mesh refinement in the lower order methods:
2195
2196@code
2197Vectorization over 2 doubles = 128 bits (SSE2)
2198Cycle 0
2199Number of degrees of freedom: 4913
2200Total setup time (wall) 0.0842004s
2201Time solve (8 iterations) (CPU/wall) 0.019296s/0.0192959s
2202
2203Cycle 1
2204Number of degrees of freedom: 35937
2205Total setup time (wall) 0.327048s
2206Time solve (8 iterations) (CPU/wall) 0.07517s/0.075999s
2207
2208Cycle 2
2209Number of degrees of freedom: 274625
2210Total setup time (wall) 2.12335s
2211Time solve (8 iterations) (CPU/wall) 0.448739s/0.453698s
2212
2213Cycle 3
2214Number of degrees of freedom: 2146689
2215Total setup time (wall) 16.1743s
2216Time solve (8 iterations) (CPU/wall) 3.95003s/3.97717s
2217
2218Cycle 4
2219Number of degrees of freedom: 16974593
2220Total setup time (wall) 130.8s
2221Time solve (8 iterations) (CPU/wall) 31.0316s/31.767s
2222@endcode
2223
2224Here, the initialization seems considerably slower than before, which is
2225mainly due to the computation of the diagonal of the matrix, which actually
2226computes a 729 x 729 matrix on each cell and throws away everything but the
2227diagonal. The solver times, however, are again very close to the quartic case,
2228showing that the linear increase with the polynomial degree that is
2229theoretically expected is almost completely offset by better computational
2230characteristics and the fact that higher order methods have a smaller share of
2231degrees of freedom living on several cells that add to the evaluation
2232complexity.
2233
2234<a name="step_37-Comparisonwithasparsematrix"></a><h3>Comparison with a sparse matrix</h3>
2235
2236
2237In order to understand the capabilities of the matrix-free implementation, we
2238compare the performance of the 3d example above with a sparse matrix
2239implementation based on TrilinosWrappers::SparseMatrix by measuring both the
2240computation times for the initialization of the problem (distribute DoFs,
2241setup and assemble matrices, setup multigrid structures) and the actual
2242solution for the matrix-free variant and the variant based on sparse
2243matrices. We base the preconditioner on float numbers and the actual matrix
2244and vectors on double numbers, as shown above. Tests are run on an Intel Core
2245i7-5500U notebook processor (two cores and <a
2246href="http://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</a>
2247support, i.e., four operations on doubles can be done with one CPU
2248instruction, which is heavily used in FEEvaluation), optimized mode, and two
2249MPI ranks.
2250
2251<table align="center" class="doxtable">
2252 <tr>
2253 <th>&nbsp;</th>
2254 <th colspan="2">Sparse matrix</th>
2255 <th colspan="2">Matrix-free implementation</th>
2256 </tr>
2257 <tr>
2258 <th>n_dofs</th>
2259 <th>Setup + assemble</th>
2260 <th>&nbsp;Solve&nbsp;</th>
2261 <th>Setup + assemble</th>
2262 <th>&nbsp;Solve&nbsp;</th>
2263 </tr>
2264 <tr>
2265 <td align="right">125</td>
2266 <td align="center">0.0042s</td>
2267 <td align="center">0.0012s</td>
2268 <td align="center">0.0022s</td>
2269 <td align="center">0.00095s</td>
2270 </tr>
2271 <tr>
2272 <td align="right">729</td>
2273 <td align="center">0.012s</td>
2274 <td align="center">0.0040s</td>
2275 <td align="center">0.0027s</td>
2276 <td align="center">0.0021s</td>
2277 </tr>
2278 <tr>
2279 <td align="right">4,913</td>
2280 <td align="center">0.082s</td>
2281 <td align="center">0.012s</td>
2282 <td align="center">0.011s</td>
2283 <td align="center">0.0057s</td>
2284 </tr>
2285 <tr>
2286 <td align="right">35,937</td>
2287 <td align="center">0.73s</td>
2288 <td align="center">0.13s</td>
2289 <td align="center">0.048s</td>
2290 <td align="center">0.040s</td>
2291 </tr>
2292 <tr>
2293 <td align="right">274,625</td>
2294 <td align="center">5.43s</td>
2295 <td align="center">1.01s</td>
2296 <td align="center">0.33s</td>
2297 <td align="center">0.25s</td>
2298 </tr>
2299 <tr>
2300 <td align="right">2,146,689</td>
2301 <td align="center">43.8s</td>
2302 <td align="center">8.24s</td>
2303 <td align="center">2.42s</td>
2304 <td align="center">2.06s</td>
2305 </tr>
2306</table>
2307
2308The table clearly shows that the matrix-free implementation is more than twice
2309as fast for the solver, and more than six times as fast when it comes to
2310initialization costs. As the problem size is made a factor 8 larger, we note
2311that the times usually go up by a factor eight, too (as the solver iterations
2312are constant at six). The main deviation is in the sparse matrix between 5k
2313and 36k degrees of freedom, where the time increases by a factor 12. This is
2314the threshold where the (L3) cache in the processor can no longer hold all
2315data necessary for the matrix-vector products and all matrix elements must be
2316fetched from main memory.
2317
2318Of course, this picture does not necessarily translate to all cases, as there
2319are problems where knowledge of matrix entries enables much better solvers (as
2320happens when the coefficient is varying more strongly than in the above
2321example). Moreover, it also depends on the computer system. The present system
2322has good memory performance, so sparse matrices perform comparably
2323well. Nonetheless, the matrix-free implementation gives a nice speedup already
2324for the <i>Q</i><sub>2</sub> elements used in this example. This becomes
2325particularly apparent for time-dependent or nonlinear problems where sparse
2326matrices would need to be reassembled over and over again, which becomes much
2327easier with this class. And of course, thanks to the better complexity of the
2328products, the method gains increasingly larger advantages when the order of the
2329elements increases (the matrix-free implementation has costs
23304<i>d</i><sup>2</sup><i>p</i> per degree of freedom, compared to
23312<i>p<sup>d</sup></i> for the sparse matrix, so it will win anyway for order 4
2332and higher in 3d).
2333
2334<a name="step_37-ResultsforlargescaleparallelcomputationsonSuperMUC"></a><h3> Results for large-scale parallel computations on SuperMUC</h3>
2335
2336
2337As explained in the introduction and the in-code comments, this program can be
2338run in parallel with MPI. It turns out that geometric multigrid schemes work
2339really well and can scale to very large machines. To the authors' knowledge,
2340the geometric multigrid results shown here are the largest computations done
2341with deal.II as of late 2016, run on up to 147,456 cores of the <a
2342href="https://www.lrz.de/services/compute/supermuc/systemdescription/">complete
2343SuperMUC Phase 1</a>. The ingredients for scalability beyond 1000 cores are
2344that no data structure that depends on the global problem size is held in its
2345entirety on a single processor and that the communication is not too frequent
2346in order not to run into latency issues of the network. For PDEs solved with
2347iterative solvers, the communication latency is often the limiting factor,
2348rather than the throughput of the network. For the example of the SuperMUC
2349system, the point-to-point latency between two processors is between 1e-6 and
23501e-5 seconds, depending on the proximity in the MPI network. The matrix-vector
2351products with @p LaplaceOperator from this class involves several
2352point-to-point communication steps, interleaved with computations on each
2353core. The resulting latency of a matrix-vector product is around 1e-4
2354seconds. Global communication, for example an @p MPI_Allreduce operation that
2355accumulates the sum of a single number per rank over all ranks in the MPI
2356network, has a latency of 1e-4 seconds. The multigrid V-cycle used in this
2357program is also a form of global communication. Think about the coarse grid
2358solve that happens on a single processor: It accumulates the contributions
2359from all processors before it starts. When completed, the coarse grid solution
2360is transferred to finer levels, where more and more processors help in
2361smoothing until the fine grid. Essentially, this is a tree-like pattern over
2362the processors in the network and controlled by the mesh. As opposed to the
2363@p MPI_Allreduce operations where the tree in the reduction is optimized to the
2364actual links in the MPI network, the multigrid V-cycle does this according to
2365the partitioning of the mesh. Thus, we cannot expect the same
2366optimality. Furthermore, the multigrid cycle is not simply a walk up and down
2367the refinement tree, but also communication on each level when doing the
2368smoothing. In other words, the global communication in multigrid is more
2369challenging and related to the mesh that provides less optimization
2370opportunities. The measured latency of the V-cycle is between 6e-3 and 2e-2
2371seconds, i.e., the same as 60 to 200 MPI_Allreduce operations.
2372
2373The following figure shows a scaling experiments on @f$\mathcal Q_3@f$
2374elements. Along the lines, the problem size is held constant as the number of
2375cores is increasing. When doubling the number of cores, one expects a halving
2376of the computational time, indicated by the dotted gray lines. The results
2377show that the implementation shows almost ideal behavior until an absolute
2378time of around 0.1 seconds is reached. The solver tolerances have been set
2379such that the solver performs five iterations. This way of plotting data is
2380the <b>strong scaling</b> of the algorithm. As we go to very large core
2381counts, the curves flatten out a bit earlier, which is because of the
2382communication network in SuperMUC where communication between processors
2383farther away is slightly slower.
2384
2385<img src="https://www.dealii.org/images/steps/developer/step-37.scaling_strong.png" alt="">
2386
2387In addition, the plot also contains results for <b>weak scaling</b> that lists
2388how the algorithm behaves as both the number of processor cores and elements
2389is increased at the same pace. In this situation, we expect that the compute
2390time remains constant. Algorithmically, the number of CG iterations is
2391constant at 5, so we are good from that end. The lines in the plot are
2392arranged such that the top left point in each data series represents the same
2393size per processor, namely 131,072 elements (or approximately 3.5 million
2394degrees of freedom per core). The gray lines indicating ideal strong scaling
2395are by the same factor of 8 apart. The results show again that the scaling is
2396almost ideal. The parallel efficiency when going from 288 cores to 147,456
2397cores is at around 75% for a local problem size of 750,000 degrees of freedom
2398per core which takes 1.0s on 288 cores, 1.03s on 2304 cores, 1.19s on 18k
2399cores, and 1.35s on 147k cores. The algorithms also reach a very high
2400utilization of the processor. The largest computation on 147k cores reaches
2401around 1.7 PFLOPs/s on SuperMUC out of an arithmetic peak of 3.2 PFLOPs/s. For
2402an iterative PDE solver, this is a very high number and significantly more is
2403often only reached for dense linear algebra. Sparse linear algebra is limited
2404to a tenth of this value.
2405
2406As mentioned in the introduction, the matrix-free method reduces the memory
2407consumption of the data structures. Besides the higher performance due to less
2408memory transfer, the algorithms also allow for very large problems to fit into
2409memory. The figure below shows the computational time as we increase the
2410problem size until an upper limit where the computation exhausts memory. We do
2411this for 1k cores, 8k cores, and 65k cores and see that the problem size can
2412be varied over almost two orders of magnitude with ideal scaling. The largest
2413computation shown in this picture involves 292 billion (@f$2.92 \cdot 10^{11}@f$)
2414degrees of freedom. On a DG computation of 147k cores, the above algorithms
2415were also run involving up to 549 billion (2^39) DoFs.
2416
2417<img src="https://www.dealii.org/images/steps/developer/step-37.scaling_size.png" alt="">
2418
2419Finally, we note that while performing the tests on the large-scale system
2420shown above, improvements of the multigrid algorithms in deal.II have been
2421developed. The original version contained the sub-optimal code based on
2422MGSmootherPrecondition where some MPI_Allreduce commands (checking whether
2423all vector entries are zero) were done on each smoothing
2424operation on each level, which only became apparent on 65k cores and
2425more. However, the following picture shows that the improvement already pay
2426off on a smaller scale, here shown on computations on up to 14,336 cores for
2427@f$\mathcal Q_5@f$ elements:
2428
2429<img src="https://www.dealii.org/images/steps/developer/step-37.scaling_oldnew.png" alt="">
2430
2431
2432<a name="step_37-Adaptivity"></a><h3> Adaptivity</h3>
2433
2434
2435As explained in the code, the algorithm presented here is prepared to run on
2436adaptively refined meshes. If only part of the mesh is refined, the multigrid
2437cycle will run with local smoothing and impose Dirichlet conditions along the
2438interfaces which differ in refinement level for smoothing through the
2439MatrixFreeOperators::Base class. Due to the way the degrees of freedom are
2440distributed over levels, relating the owner of the level cells to the owner of
2441the first descendant active cell, there can be an imbalance between different
2442processors in MPI, which limits scalability by a factor of around two to five.
2443
2444<a name="step_37-Possibilitiesforextensions"></a><h3> Possibilities for extensions</h3>
2445
2446
2447<a name="step_37-Kellyerrorestimator"></a><h4> Kelly error estimator </h4>
2448
2449
2450As mentioned above the code is ready for locally adaptive h-refinement.
2451For the Poisson equation one can employ the Kelly error indicator,
2452implemented in the KellyErrorEstimator class. However one needs to be careful
2453with the ghost indices of parallel vectors.
2454In order to evaluate the jump terms in the error indicator, each MPI process
2455needs to know locally relevant DoFs.
2456However MatrixFree::initialize_dof_vector() function initializes the vector only with
2457some locally relevant DoFs.
2458The ghost indices made available in the vector are a tight set of only those indices
2459that are touched in the cell integrals (including constraint resolution).
2460This choice has performance reasons, because sending all locally relevant degrees
2461of freedom would be too expensive compared to the matrix-vector product.
2462Consequently the solution vector as-is is
2463not suitable for the KellyErrorEstimator class.
2464The trick is to change the ghost part of the partition, for example using a
2465temporary vector and LinearAlgebra::distributed::Vector::copy_locally_owned_data_from()
2466as shown below.
2467
2468@code
2469const IndexSet locally_relevant_dofs = DoFTools::extract_locally_relevant_dofs(dof_handler);
2470LinearAlgebra::distributed::Vector<double> copy_vec(solution);
2471solution.reinit(dof_handler.locally_owned_dofs(),
2472 locally_relevant_dofs,
2473 triangulation.get_communicator());
2474solution.copy_locally_owned_data_from(copy_vec);
2475constraints.distribute(solution);
2476solution.update_ghost_values();
2477@endcode
2478
2479<a name="step_37-Sharedmemoryparallelization"></a><h4> Shared-memory parallelization</h4>
2480
2481
2482This program is parallelized with MPI only. As an alternative, the MatrixFree
2483loop can also be issued in hybrid mode, for example by using MPI parallelizing
2484over the nodes of a cluster and with threads through Intel TBB within the
2485shared memory region of one node. To use this, one would need to both set the
2486number of threads in the MPI_InitFinalize data structure in the main function,
2487and set the MatrixFree::AdditionalData::tasks_parallel_scheme to
2488partition_color to actually do the loop in parallel. This use case is
2489discussed in @ref step_48 "step-48".
2490
2491<a name="step_37-InhomogeneousDirichletboundaryconditions"></a><h4> Inhomogeneous Dirichlet boundary conditions </h4>
2492
2493
2494The presented program assumes homogeneous Dirichlet boundary conditions. When
2495going to non-homogeneous conditions, the situation is a bit more intricate. To
2496understand how to implement such a setting, let us first recall how these
2497arise in the mathematical formulation and how they are implemented in a
2498matrix-based variant. In essence, an inhomogeneous Dirichlet condition sets
2499some of the nodal values in the solution to given values rather than
2500determining them through the variational principles,
2501@f{eqnarray*}{
2502u_h(\mathbf{x}) = \sum_{i\in \mathcal N} \varphi_i(\mathbf{x}) u_i =
2503\sum_{i\in \mathcal N \setminus \mathcal N_D} \varphi_i(\mathbf{x}) u_i +
2504\sum_{i\in \mathcal N_D} \varphi_i(\mathbf{x}) g_i,
2505@f}
2506where @f$u_i@f$ denotes the nodal values of the solution and @f$\mathcal N@f$ denotes
2507the set of all nodes. The set @f$\mathcal N_D\subset \mathcal N@f$ is the subset
2508of the nodes that are subject to Dirichlet boundary conditions where the
2509solution is forced to equal @f$u_i = g_i = g(\mathbf{x}_i)@f$ as the interpolation
2510of boundary values on the Dirichlet-constrained node points @f$i\in \mathcal
2511N_D@f$. We then insert this solution
2512representation into the weak form, e.g. the Laplacian shown above, and move
2513the known quantities to the right hand side:
2514@f{eqnarray*}{
2515(\nabla \varphi_i, \nabla u_h)_\Omega &=& (\varphi_i, f)_\Omega \quad \Rightarrow \\
2516\sum_{j\in \mathcal N \setminus \mathcal N_D}(\nabla \varphi_i,\nabla \varphi_j)_\Omega \, u_j &=&
2517(\varphi_i, f)_\Omega
2518-\sum_{j\in \mathcal N_D} (\nabla \varphi_i,\nabla\varphi_j)_\Omega\, g_j.
2519@f}
2520In this formula, the equations are tested for all basis functions @f$\varphi_i@f$
2521with @f$i\in N \setminus \mathcal N_D@f$ that are not related to the nodes
2522constrained by Dirichlet conditions.
2523
2524In the implementation in deal.II, the integrals @f$(\nabla \varphi_i,\nabla \varphi_j)_\Omega@f$
2525on the right hand side are already contained in the local matrix contributions
2526we assemble on each cell. When using
2528@ref step_6 "step-6" and @ref step_7 "step-7" tutorial programs, we can account for the contribution of
2529inhomogeneous constraints <i>j</i> by multiplying the columns <i>j</i> and
2530rows <i>i</i> of the local matrix according to the integrals @f$(\varphi_i,
2531\varphi_j)_\Omega@f$ by the inhomogeneities and subtracting the resulting from
2532the position <i>i</i> in the global right-hand-side vector, see also the @ref
2533constraints module. In essence, we use some of the integrals that get
2534eliminated from the left hand side of the equation to finalize the right hand
2535side contribution. Similar mathematics are also involved when first writing
2536all entries into a left hand side matrix and then eliminating matrix rows and
2537columns by MatrixTools::apply_boundary_values().
2538
2539In principle, the components that belong to the constrained degrees of freedom
2540could be eliminated from the linear system because they do not carry any
2541information. In practice, in deal.II we always keep the size of the linear
2542system the same to avoid handling two different numbering systems and avoid
2543confusion about the two different index sets. In order to ensure that the
2544linear system does not get singular when not adding anything to constrained
2545rows, we then add dummy entries to the matrix diagonal that are otherwise
2546unrelated to the real entries.
2547
2548In a matrix-free method, we need to take a different approach, since the @p
2549LaplaceOperator class represents the matrix-vector product of a
2550<b>homogeneous</b> operator (the left-hand side of the last formula). It does
2551not matter whether the AffineConstraints object passed to the
2552MatrixFree::reinit() contains inhomogeneous constraints or not, the
2553MatrixFree::cell_loop() call will only resolve the homogeneous part of the
2554constraints as long as it represents a <b>linear</b> operator.
2555
2556In our matrix-free code, the right hand side computation where the
2557contribution of inhomogeneous conditions ends up is completely decoupled from
2558the matrix operator and handled by a different function above. Thus, we need
2559to explicitly generate the data that enters the right hand side rather than
2560using a byproduct of the matrix assembly. Since we already know how to apply
2561the operator on a vector, we could try to use those facilities for a vector
2562where we only set the Dirichlet values:
2563@code
2564 // interpolate boundary values on vector solution
2565 std::map<types::global_dof_index, double> boundary_values;
2567 dof_handler,
2568 0,
2569 BoundaryValueFunction<dim>(),
2570 boundary_values);
2571 for (const std::pair<const types::global_dof_index, double> &pair : boundary_values)
2572 if (solution.locally_owned_elements().is_element(pair.first))
2573 solution(pair.first) = pair.second;
2574@endcode
2575or, equivalently, if we already had filled the inhomogeneous constraints into
2576an AffineConstraints object,
2577@code
2578 solution = 0;
2579 constraints.distribute(solution);
2580@endcode
2581
2582We could then pass the vector @p solution to the @p
2583LaplaceOperator::vmult_add() function and add the new contribution to the @p
2584system_rhs vector that gets filled in the @p LaplaceProblem::assemble_rhs()
2585function. However, this idea does not work because the
2586FEEvaluation::read_dof_values() call used inside the vmult() functions assumes
2587homogeneous values on all constraints (otherwise the operator would not be a
2588linear operator but an affine one). To also retrieve the values of the
2589inhomogeneities, we could select one of two following strategies.
2590
2591<a name="step_37-UseFEEvaluationread_dof_values_plaintoavoidresolvingconstraints"></a><h5> Use FEEvaluation::read_dof_values_plain() to avoid resolving constraints </h5>
2592
2593
2594The class FEEvaluation has a facility that addresses precisely this
2595requirement: For non-homogeneous Dirichlet values, we do want to skip the
2596implicit imposition of homogeneous (Dirichlet) constraints upon reading the
2597data from the vector @p solution. For example, we could extend the @p
2598LaplaceProblem::assemble_rhs() function to deal with inhomogeneous Dirichlet
2599values as follows, assuming the Dirichlet values have been interpolated into
2600the object @p constraints:
2601@code
2602template <int dim>
2603void LaplaceProblem<dim>::assemble_rhs()
2604{
2605 solution = 0;
2606 constraints.distribute(solution);
2607 solution.update_ghost_values();
2608 system_rhs = 0;
2609
2610 const Table<2, VectorizedArray<double>> &coefficient = system_matrix.get_coefficient();
2611 FEEvaluation<dim, degree_finite_element> phi(*system_matrix.get_matrix_free());
2612 for (unsigned int cell = 0;
2613 cell < system_matrix.get_matrix_free()->n_cell_batches();
2614 ++cell)
2615 {
2616 phi.reinit(cell);
2617 phi.read_dof_values_plain(solution);
2618 phi.evaluate(EvaluationFlags::gradients);
2619 for (const unsigned int q : phi.quadrature_point_indices())
2620 {
2621 phi.submit_gradient(-coefficient(cell, q) * phi.get_gradient(q), q);
2622 phi.submit_value(make_vectorized_array<double>(1.0), q);
2623 }
2625 phi.distribute_local_to_global(system_rhs);
2626 }
2627 system_rhs.compress(VectorOperation::add);
2628}
2629@endcode
2630
2631In this code, we replaced the FEEvaluation::read_dof_values() function for the
2632tentative solution vector by FEEvaluation::read_dof_values_plain() that
2633ignores all constraints. Due to this setup, we must make sure that other
2634constraints, e.g. by hanging nodes, are correctly distributed to the input
2635vector already as they are not resolved as in
2636FEEvaluation::read_dof_values_plain(). Inside the loop, we then evaluate the
2637Laplacian and repeat the second derivative call with
2638FEEvaluation::submit_gradient() from the @p LaplaceOperator class, but with the
2639sign switched since we wanted to subtract the contribution of Dirichlet
2640conditions on the right hand side vector according to the formula above. When
2641we invoke the FEEvaluation::integrate() call, we then set both arguments
2642regarding the value slot and first derivative slot to true to account for both
2643terms added in the loop over quadrature points. Once the right hand side is
2644assembled, we then go on to solving the linear system for the homogeneous
2645problem, say involving a variable @p solution_update. After solving, we can
2646add @p solution_update to the @p solution vector that contains the final
2647(inhomogeneous) solution.
2648
2649Note that the negative sign for the Laplacian alongside with a positive sign
2650for the forcing that we needed to build the right hand side is a more general
2651concept: We have implemented nothing else than Newton's method for nonlinear
2652equations, but applied to a linear system. We have used an initial guess for
2653the variable @p solution in terms of the Dirichlet boundary conditions and
2654computed a residual @f$r = f - Au_0@f$. The linear system was then solved as
2655@f$\Delta u = A^{-1} (f-Au)@f$ and we finally computed @f$u = u_0 + \Delta u@f$. For a
2656linear system, we obviously reach the exact solution after a single
2657iteration. If we wanted to extend the code to a nonlinear problem, we would
2658rename the @p assemble_rhs() function into a more descriptive name like @p
2659assemble_residual() that computes the (weak) form of the residual, whereas the
2660@p LaplaceOperator::apply_add() function would get the linearization of the
2661residual with respect to the solution variable.
2662
2663<a name="step_37-UseLaplaceOperatorwithasecondAffineConstraintsobjectwithoutDirichletconditions"></a><h5> Use LaplaceOperator with a second AffineConstraints object without Dirichlet conditions </h5>
2664
2665
2666A second alternative to get the right hand side that re-uses the @p
2667LaplaceOperator::apply_add() function is to instead add a second LaplaceOperator
2668that skips Dirichlet constraints. To do this, we initialize a second MatrixFree
2669object which does not have any boundary value constraints. This @p matrix_free
2670object is then passed to a @p LaplaceOperator class instance @p
2671inhomogeneous_operator that is only used to create the right hand side:
2672@code
2673template <int dim>
2674void LaplaceProblem<dim>::assemble_rhs()
2675{
2676 system_rhs = 0;
2677 AffineConstraints<double> no_constraints;
2678 no_constraints.close();
2679 LaplaceOperator<dim, degree_finite_element, double> inhomogeneous_operator;
2680
2681 typename MatrixFree<dim, double>::AdditionalData additional_data;
2682 additional_data.mapping_update_flags =
2684 std::shared_ptr<MatrixFree<dim, double>> matrix_free(
2686 matrix_free->reinit(dof_handler,
2687 no_constraints,
2688 QGauss<1>(fe.degree + 1),
2689 additional_data);
2690 inhomogeneous_operator.initialize(matrix_free);
2691
2692 solution = 0.0;
2693 constraints.distribute(solution);
2694 inhomogeneous_operator.evaluate_coefficient(Coefficient<dim>());
2695 inhomogeneous_operator.vmult(system_rhs, solution);
2696 system_rhs *= -1.0;
2697
2699 *inhomogeneous_operator.get_matrix_free());
2700 for (unsigned int cell = 0;
2701 cell < inhomogeneous_operator.get_matrix_free()->n_cell_batches();
2702 ++cell)
2703 {
2704 phi.reinit(cell);
2705 for (const unsigned int q : phi.quadrature_point_indices())
2706 phi.submit_value(make_vectorized_array<double>(1.0), q);
2707 phi.integrate(EvaluationFlags::values);
2708 phi.distribute_local_to_global(system_rhs);
2709 }
2710 system_rhs.compress(VectorOperation::add);
2711}
2712@endcode
2713
2714A more sophisticated implementation of this technique could reuse the original
2715MatrixFree object. This can be done by initializing the MatrixFree object with
2716multiple blocks, where each block corresponds to a different AffineConstraints
2717object. Doing this would require making substantial modifications to the
2718LaplaceOperator class, but the MatrixFreeOperators::LaplaceOperator class that
2719comes with the library can do this. See the discussion on blocks in
2720MatrixFreeOperators::Base for more information on how to set up blocks.
2721
2722<a name="step_37-Furtherperformanceimprovements"></a><h4> Further performance improvements </h4>
2723
2724
2725While the performance achieved in this tutorial program is already very good,
2726there is functionality in deal.II to further improve the performance. On the
2727one hand, increasing the polynomial degree to three or four will further
2728improve the time per unknown. (Even higher degrees typically get slower again,
2729because the multigrid iteration counts increase slightly with the chosen
2730simple smoother. One could then use hybrid multigrid algorithms to use
2731polynomial coarsening through MGTransferGlobalCoarsening, to reduce the impact
2732of the coarser level on the communication latency.) A more significant
2733improvement can be obtained by data-locality optimizations. The class
2734PreconditionChebyshev, when combined with a `DiagonalMatrix` inner
2735preconditioner as in the present class, can overlap the vector operations with
2736the matrix-vector product. As the former are typically constrained by memory
2737bandwidth, reducing the number of loads helps to achieve this goal. The two
2738ingredients to achieve this are
2739<ol>
2740<li> to provide LaplaceOperator class of this tutorial program with a `vmult`
2741function that takes two `std::function` objects, which can be passed on to
2742MatrixFree::cell_loop with the respective signature (PreconditionChebyshev
2743will then pick up this interface and schedule its vector operations), and </li>
2744<li> to compute a numbering that optimizes for data locality, as provided by
2746</ol>
2747 *
2748 *
2749<a name="step_37-PlainProg"></a>
2750<h1> The plain program</h1>
2751@include "step-37.cc"
2752*/
void distribute_local_to_global(const InVector &local_vector, const std::vector< size_type > &local_dof_indices, OutVector &global_vector) const
void distribute(VectorType &vec) const
void attach_dof_handler(const DoFHandler< dim, spacedim > &)
void read_dof_values(const VectorType &src, const unsigned int first_index=0, const std::bitset< n_lanes > &mask=std::bitset< n_lanes >().flip())
void evaluate(const EvaluationFlags::EvaluationFlags evaluation_flag)
Definition fe_q.h:550
void reinit(const size_type size, const bool omit_zeroing_entries=false)
void initialize(const MGSmootherBase< VectorType > &coarse_smooth)
void resize(const unsigned int new_minlevel, const unsigned int new_maxlevel, Args &&...args)
void set_constrained_entries_to_one(VectorType &dst) const
Definition operators.h:1443
void vmult_add(VectorType &dst, const VectorType &src) const
Definition operators.h:1475
void vmult_interface_down(VectorType &dst, const VectorType &src) const
Definition operators.h:1623
std::shared_ptr< DiagonalMatrix< VectorType > > inverse_diagonal_entries
Definition operators.h:447
unsigned int n_cell_batches() const
void initialize_dof_vector(VectorType &vec, const unsigned int dof_handler_index=0) const
void cell_loop(const std::function< void(const MatrixFree< dim, Number, VectorizedArrayType > &, OutVector &, const InVector &, const std::pair< unsigned int, unsigned int > &)> &cell_operation, OutVector &dst, const InVector &src, const bool zero_dst_vector=false) const
Definition point.h:111
constexpr numbers::NumberTraits< Number >::real_type square() const
Definition timer.h:117
Point< 3 > vertices[4]
Point< 2 > second
Definition grid_out.cc:4614
Point< 2 > first
Definition grid_out.cc:4613
unsigned int level
Definition grid_out.cc:4616
__global__ void reduction(Number *result, const Number *v, const size_type N)
__global__ void set(Number *val, const Number s, const size_type N)
#define Assert(cond, exc)
#define AssertDimension(dim1, dim2)
void loop(IteratorType begin, std_cxx20::type_identity_t< IteratorType > end, DOFINFO &dinfo, INFOBOX &info, const std::function< void(DOFINFO &, typename INFOBOX::CellInfo &)> &cell_worker, const std::function< void(DOFINFO &, typename INFOBOX::CellInfo &)> &boundary_worker, const std::function< void(DOFINFO &, DOFINFO &, typename INFOBOX::CellInfo &, typename INFOBOX::CellInfo &)> &face_worker, AssemblerType &assembler, const LoopControl &lctrl=LoopControl())
Definition loop.h:442
void make_hanging_node_constraints(const DoFHandler< dim, spacedim > &dof_handler, AffineConstraints< number > &constraints)
@ update_JxW_values
Transformed quadrature weights.
@ update_gradients
Shape function gradients.
@ update_quadrature_points
Transformed quadrature points.
void matrix_free_data_locality(DoFHandler< dim, spacedim > &dof_handler, const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free)
IndexSet extract_locally_relevant_dofs(const DoFHandler< dim, spacedim > &dof_handler)
IndexSet extract_locally_relevant_level_dofs(const DoFHandler< dim, spacedim > &dof_handler, const unsigned int level)
void scale(const double scaling_factor, Triangulation< dim, spacedim > &triangulation)
spacedim & mapping
spacedim const Point< spacedim > & p
Definition grid_tools.h:980
const std::vector< bool > & used
spacedim & mesh
Definition grid_tools.h:979
if(marked_vertices.size() !=0) for(auto it
for(unsigned int j=best_vertex+1;j< vertices.size();++j) if(vertices_to_use[j])
@ matrix
Contents is actually a matrix.
@ diagonal
Matrix is diagonal.
@ general
No special properties.
void compute_diagonal(const MatrixFree< dim, Number, VectorizedArrayType > &matrix_free, VectorType &diagonal_global, const std::function< void(FEEvaluation< dim, fe_degree, n_q_points_1d, n_components, Number, VectorizedArrayType > &)> &local_vmult, const unsigned int dof_no=0, const unsigned int quad_no=0, const unsigned int first_selected_component=0)
Point< spacedim > point(const gp_Pnt &p, const double tolerance=1e-10)
Definition utilities.cc:191
SymmetricTensor< 2, dim, Number > e(const Tensor< 2, dim, Number > &F)
SymmetricTensor< 2, dim, Number > b(const Tensor< 2, dim, Number > &F)
SymmetricTensor< 2, dim, Number > d(const Tensor< 2, dim, Number > &F, const Tensor< 2, dim, Number > &dF_dt)
void apply(const Kokkos::TeamPolicy< MemorySpace::Default::kokkos_space::execution_space >::member_type &team_member, const Kokkos::View< Number *, MemorySpace::Default::kokkos_space > shape_data, const ViewTypeIn in, ViewTypeOut out)
void free(T *&pointer)
Definition cuda.h:96
std::vector< unsigned int > serial(const std::vector< unsigned int > &targets, const std::function< RequestType(const unsigned int)> &create_request, const std::function< AnswerType(const unsigned int, const RequestType &)> &answer_request, const std::function< void(const unsigned int, const AnswerType &)> &process_answer, const MPI_Comm comm)
T sum(const T &t, const MPI_Comm mpi_communicator)
unsigned int this_mpi_process(const MPI_Comm mpi_communicator)
Definition mpi.cc:143
T reduce(const T &local_value, const MPI_Comm comm, const std::function< T(const T &, const T &)> &combiner, const unsigned int root_process=0)
std::string compress(const std::string &input)
Definition utilities.cc:389
void interpolate_boundary_values(const Mapping< dim, spacedim > &mapping, const DoFHandler< dim, spacedim > &dof, const std::map< types::boundary_id, const Function< spacedim, number > * > &function_map, std::map< types::global_dof_index, number > &boundary_values, const ComponentMask &component_mask={})
spacedim const DoFHandler< dim, spacedim > const FullMatrix< double > & transfer
void run(const Iterator &begin, const std_cxx20::type_identity_t< Iterator > &end, Worker worker, Copier copier, const ScratchData &sample_scratch_data, const CopyData &sample_copy_data, const unsigned int queue_length, const unsigned int chunk_size)
unsigned int n_cells(const internal::TriangulationImplementation::NumberCache< 1 > &c)
Definition tria.cc:15017
void copy(const T *begin, const T *end, U *dest)
int(&) functions(const void *v1, const void *v2)
void assemble(const MeshWorker::DoFInfoBox< dim, DOFINFO > &dinfo, A *assembler)
Definition loop.h:70
void reinit(MatrixBlock< MatrixType > &v, const BlockSparsityPattern &p)
Definition mg.h:81
static const unsigned int invalid_unsigned_int
Definition types.h:220
const InputIterator OutputIterator out
Definition parallel.h:167
const Iterator const std_cxx20::type_identity_t< Iterator > & end
Definition parallel.h:610
const InputIterator OutputIterator const Function & function
Definition parallel.h:168
const Iterator & begin
Definition parallel.h:609
STL namespace.
const ::parallel::distributed::Triangulation< dim, spacedim > * triangulation
DataOutBase::CompressionLevel compression_level
TasksParallelScheme tasks_parallel_scheme
DEAL_II_HOST constexpr Number determinant(const SymmetricTensor< 2, dim, Number > &)
DEAL_II_HOST constexpr SymmetricTensor< 2, dim, Number > invert(const SymmetricTensor< 2, dim, Number > &)
std::array< Number, 1 > eigenvalues(const SymmetricTensor< 2, 1, Number > &T)
VectorizedArray< Number, width > make_vectorized_array(const Number &u)