From: David Wells Date: Thu, 16 Apr 2020 20:51:10 +0000 (-0400) Subject: step-8: Improve doxygen links. X-Git-Tag: v9.2.0-rc1~211^2~4 X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9f33afd45033315cc17a208c17d1c1e4b8df0ecb;p=dealii.git step-8: Improve doxygen links. We do not need to surround these class names with . --- diff --git a/examples/step-8/step-8.cc b/examples/step-8/step-8.cc index 52f7de2a75..122ece1bec 100644 --- a/examples/step-8/step-8.cc +++ b/examples/step-8/step-8.cc @@ -70,11 +70,10 @@ namespace Step8 // the step-6 example. // // The only change is the use of a different class for the fe - // variable: Instead of a concrete finite element class such as - // FE_Q, we now use a more generic one, - // FESystem. In fact, FESystem is not really a + // variable: Instead of a concrete finite element class such as FE_Q, we now + // use a more generic one, FESystem. In fact, FESystem is not really a // finite element itself in that it does not implement shape functions of - // its own. Rather, it is a class that can be used to stack several other + // its own. Rather, it is a class that can be used to stack several other // elements together to form one vector-valued finite element. In our case, // we will compose the vector-valued element of FE_Q(1) // objects, as shown below in the constructor of this class. @@ -126,8 +125,8 @@ namespace Step8 // subsequent calls would only have to do redundant checks). In addition, // checking and possibly resizing the vector is an operation that can not be // removed if we can't rely on the assumption that the vector already has - // the correct size; this is in contract to the Assert call - // that is completely removed if the program is compiled in optimized mode. + // the correct size; this is in contract to the Assert call that is + // completely removed if the program is compiled in optimized mode. // // Likewise, if by some accident someone tried to compile and run the // program in only one space dimension (in which the elastic equations do @@ -149,8 +148,8 @@ namespace Step8 // zero as well. // // For this, let us first define two objects that denote the centers of - // these areas. Note that upon construction of the Point - // objects, all components are set to zero. + // these areas. Note that upon construction of the Point objects, all + // components are set to zero. Point point_1, point_2; point_1(0) = 0.5; point_2(0) = -0.5; @@ -188,19 +187,19 @@ namespace Step8 // functions of a scalar element). Of course, the number of scalar finite // elements we would like to stack together equals the number of components // the solution function has, which is dim since we consider - // displacement in each space direction. The FESystem class can - // handle this: we pass it the finite element of which we would like to - // compose the system of, and how often it shall be repeated: + // displacement in each space direction. The FESystem class can handle this: + // we pass it the finite element of which we would like to compose the + // system of, and how often it shall be repeated: template ElasticProblem::ElasticProblem() : dof_handler(triangulation) , fe(FE_Q(1), dim) {} - // In fact, the FESystem class has several more constructors - // which can perform more complex operations than just stacking together - // several scalar finite elements of the same type into one; we will get to - // know these possibilities in later examples. + // In fact, the FESystem class has several more constructors which can + // perform more complex operations than just stacking together several + // scalar finite elements of the same type into one; we will get to know + // these possibilities in later examples. @@ -217,15 +216,15 @@ namespace Step8 // @sect4{ElasticProblem::setup_system} // Setting up the system of equations is identical to the function used in - // the step-6 example. The DoFHandler class and all other - // classes used here are fully aware that the finite element we want to use - // is vector-valued, and take care of the vector-valuedness of the finite - // element themselves. (In fact, they do not, but this does not need to - // bother you: since they only need to know how many degrees of freedom - // there are per vertex, line and cell, and they do not ask what they - // represent, i.e. whether the finite element under consideration is - // vector-valued or whether it is, for example, a scalar Hermite element - // with several degrees of freedom on each vertex). + // the step-6 example. The DoFHandler class and all other classes used here + // are fully aware that the finite element we want to use is vector-valued, + // and take care of the vector-valuedness of the finite element + // themselves. (In fact, they do not, but this does not need to bother you: + // since they only need to know how many degrees of freedom there are per + // vertex, line and cell, and they do not ask what they represent, + // i.e. whether the finite element under consideration is vector-valued or + // whether it is, for example, a scalar Hermite element with several degrees + // of freedom on each vertex). template void ElasticProblem::setup_system() { @@ -260,15 +259,15 @@ namespace Step8 // examples. // // The first parts of this function are the same as before, however: setting - // up a suitable quadrature formula, initializing an FEValues - // object for the (vector-valued) finite element we use as well as the - // quadrature object, and declaring a number of auxiliary arrays. In - // addition, we declare the ever same two abbreviations: - // n_q_points and dofs_per_cell. The number of - // degrees of freedom per cell we now obviously ask from the composed finite - // element rather than from the underlying scalar Q1 element. Here, it is - // dim times the number of degrees of freedom per cell of the - // Q1 element, though this is not explicit knowledge we need to care about: + // up a suitable quadrature formula, initializing an FEValues object for the + // (vector-valued) finite element we use as well as the quadrature object, + // and declaring a number of auxiliary arrays. In addition, we declare the + // ever same two abbreviations: n_q_points and + // dofs_per_cell. The number of degrees of freedom per cell we + // now obviously ask from the composed finite element rather than from the + // underlying scalar Q1 element. Here, it is dim times the + // number of degrees of freedom per cell of the Q1 element, though this is + // not explicit knowledge we need to care about: template void ElasticProblem::assemble_system() { @@ -478,9 +477,8 @@ namespace Step8 // The output happens mostly as has been shown in previous examples // already. The only difference is that the solution function is vector - // valued. The DataOut class takes care of this automatically, - // but we have to give each component of the solution vector a different - // name. + // valued. The DataOut class takes care of this automatically, but we have + // to give each component of the solution vector a different name. // // To do this, the DataOut::add_vector() function wants a vector of // strings. Since the number of components is the same as the number @@ -497,10 +495,10 @@ namespace Step8 // // After listing the 1d, 2d, and 3d case, it is good style to let the // program die if we run upon a case which we did not consider. Remember - // that the Assert macro generates an exception if the - // condition in the first parameter is not satisfied. Of course, the - // condition false can never be satisfied, so the program - // will always abort whenever it gets to the default statement: + // that the Assert macro generates an exception if the condition in the + // first parameter is not satisfied. Of course, the condition + // false can never be satisfied, so the program will always + // abort whenever it gets to the default statement: template void ElasticProblem::output_results(const unsigned int cycle) const { @@ -568,13 +566,12 @@ namespace Step8 // an initial grid that is totally unsuitable for the problem at hand. // // The unfortunate thing is that if the discrete solution is constant, then - // the error indicators computed by the KellyErrorEstimator - // class are zero for each cell as well, and the call to - // refine_and_coarsen_fixed_number on the - // triangulation object will not flag any cells for refinement - // (why should it if the indicated error is zero for each cell?). The grid - // in the next iteration will therefore consist of four cells only as well, - // and the same problem occurs again. + // the error indicators computed by the KellyErrorEstimator class are zero + // for each cell as well, and the call to + // Triangulation::refine_and_coarsen_fixed_number() will not flag any cells + // for refinement (why should it if the indicated error is zero for each + // cell?). The grid in the next iteration will therefore consist of four + // cells only as well, and the same problem occurs again. // // The conclusion needs to be: while of course we will not choose the // initial grid to be well-suited for the accurate solution of the problem,