From cb66ea9c6b64f0a964536734a0a0e342cb9d8953 Mon Sep 17 00:00:00 2001 From: Timo Heister Date: Sat, 3 Nov 2012 03:00:07 +0000 Subject: [PATCH] format comments in step-6 using emacs so that they are not all over the place git-svn-id: https://svn.dealii.org/trunk@27327 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-6/step-6.cc | 239 +++++++++++++++--------------- 1 file changed, 117 insertions(+), 122 deletions(-) diff --git a/deal.II/examples/step-6/step-6.cc b/deal.II/examples/step-6/step-6.cc index 90c31101f1..0ffceb1f8a 100644 --- a/deal.II/examples/step-6/step-6.cc +++ b/deal.II/examples/step-6/step-6.cc @@ -63,19 +63,18 @@ #include - // When using locally refined grids, - // we will get so-called hanging - // nodes. However, the standard - // finite element methods assumes - // that the discrete solution spaces - // be continuous, so we need to make - // sure that the degrees of freedom + // When using locally refined grids, we will + // get so-called hanging + // nodes. However, the standard finite + // element methods assumes that the discrete + // solution spaces be continuous, so we need + // to make sure that the degrees of freedom // on hanging nodes conform to some - // constraints such that the global - // solution is continuous. We are -// also going to store the boundary conditions in this object. The - // following file contains a class - // which is used to handle these + // constraints such that the global solution + // is continuous. We are also going to store + // the boundary conditions in this + // object. The following file contains a + // class which is used to handle these // constraints: #include @@ -441,25 +440,25 @@ void Step6::setup_system () constraints); - // Now we are ready to interpolate the ZeroFunction to our - // boundary with indicator 0 (the whole boundary) and store - // the resulting constraints in our constraints - // object. Note that we do not to apply the boundary - // conditions after assembly, like we did in earlier steps. - // As almost all the stuff, - // the interpolation of boundary - // values works also for higher - // order elements without the need - // to change your code for that. We - // note that for proper results, it - // is important that the - // elimination of boundary nodes - // from the system of equations - // happens *after* the elimination - // of hanging nodes. For that reason - // we are filling the boundary values into - // the ContraintMatrix after the hanging node - // constraints. + // Now we are ready to interpolate the + // ZeroFunction to our boundary with + // indicator 0 (the whole boundary) and + // store the resulting constraints in our + // constraints object. Note + // that we do not to apply the boundary + // conditions after assembly, like we did + // in earlier steps. As almost all the + // stuff, the interpolation of boundary + // values works also for higher order + // elements without the need to change your + // code for that. We note that for proper + // results, it is important that the + // elimination of boundary nodes from the + // system of equations happens *after* the + // elimination of hanging nodes. For that + // reason we are filling the boundary + // values into the ContraintMatrix after + // the hanging node constraints. VectorTools::interpolate_boundary_values (dof_handler, 0, ZeroFunction(), @@ -478,19 +477,22 @@ void Step6::setup_system () // added any more: constraints.close (); - // Now we first build our - // compressed sparsity pattern like - // we did in the previous - // examples. Nevertheless, we do - // not copy it to the final - // sparsity pattern immediately. - // Note that we call a variant of make_sparsity_pattern that takes - // the ConstraintMatrix as the third argument. We are letting - // the routine know, the we will never write into the locations - // given by constraints by setting the argument - // keep_constrained_dofs to false. If we were to - // condense the constraints after assembling, we would have - // to pass true instead. + // Now we first build our compressed + // sparsity pattern like we did in the + // previous examples. Nevertheless, we do + // not copy it to the final sparsity + // pattern immediately. Note that we call + // a variant of make_sparsity_pattern that + // takes the ConstraintMatrix as the third + // argument. We are letting the routine + // know, the we will never write into the + // locations given by + // constraints by setting the + // argument + // keep_constrained_dofs to + // false. If we were to condense the + // constraints after assembling, we would + // have to pass true instead. CompressedSparsityPattern c_sparsity(dof_handler.n_dofs()); DoFTools::make_sparsity_pattern(dof_handler, c_sparsity, @@ -519,48 +521,46 @@ void Step6::setup_system () // Next, we have to assemble the // matrix again. There are two code // changes compared to step-5: -// -// First, we have to use - // a higher-order quadrature formula - // to account for the higher - // polynomial degree in the finite - // element shape functions. This is - // easy to change: the constructor of - // the QGauss class takes the - // number of quadrature points in - // each space direction. Previously, - // we had two points for bilinear - // elements. Now we should use three - // points for biquadratic elements. - -// Second, to copy the local matrix and vector on each cell -// into the global system, we are no longer using a hand-written -// loop. Instead, we use ConstraintMatrix::distribute_local_to_global -// that internally executes this loop and eliminates all the constraints -// at the same time. -// - // The rest of the code that forms - // the local contributions remains unchanged. It is - // worth noting, however, that under - // the hood several things are - // different than before. First, the - // variables dofs_per_cell and + // + // First, we have to use a higher-order + // quadrature formula to account for the + // higher polynomial degree in the finite + // element shape functions. This is easy to + // change: the constructor of the + // QGauss class takes the number + // of quadrature points in each space + // direction. Previously, we had two points + // for bilinear elements. Now we should use + // three points for biquadratic elements. + // + // Second, to copy the local matrix and + // vector on each cell into the global + // system, we are no longer using a + // hand-written loop. Instead, we use + // ConstraintMatrix::distribute_local_to_global + // that internally executes this loop and + // eliminates all the constraints at the same + // time. + // + // The rest of the code that forms the local + // contributions remains unchanged. It is + // worth noting, however, that under the hood + // several things are different than + // before. First, the variables + // dofs_per_cell and // n_q_points now are 9 each, - // where they were 4 - // before. Introducing such variables - // as abbreviations is a good - // strategy to make code work with - // different elements without having - // to change too much code. Secondly, - // the fe_values object of course - // needs to do other things as well, - // since the shape functions are now - // quadratic, rather than linear, in - // each coordinate variable. Again, - // however, this is something that is - // completely transparent to user - // code and nothing that you have to - // worry about. + // where they were 4 before. Introducing such + // variables as abbreviations is a good + // strategy to make code work with different + // elements without having to change too much + // code. Secondly, the fe_values + // object of course needs to do other things + // as well, since the shape functions are now + // quadratic, rather than linear, in each + // coordinate variable. Again, however, this + // is something that is completely + // transparent to user code and nothing that + // you have to worry about. template void Step6::assemble_system () { @@ -612,49 +612,44 @@ void Step6::assemble_system () // transfer the contributions from @p cell_matrix and @cell_rhs into the global objects. constraints.distribute_local_to_global(cell_matrix, cell_rhs, local_dof_indices, system_matrix, system_rhs); } -// Now we are done assembling the linear system. - // The constrained nodes are - // still in the linear system - // (there is a one on the diagonal - // of the matrix and all other - // entries for this line are set to - // zero) but the computed values - // are invalid. We compute the correct - // values for these nodes at the - // end of the solve function. + // Now we are done assembling the linear + // system. The constrained nodes are still + // in the linear system (there is a one on + // the diagonal of the matrix and all other + // entries for this line are set to zero) + // but the computed values are invalid. We + // compute the correct values for these + // nodes at the end of the + // solve function. } // @sect4{Step6::solve} - // We continue with gradual - // improvements. The function that - // solves the linear system again - // uses the SSOR preconditioner, and - // is again unchanged except that we - // have to incorporate hanging node - // constraints. As mentioned above, - // the degrees of freedom - // from the ConstraintMatrix corresponding to hanging node - // constraints and boundary values have been removed from - // the linear system by giving the - // rows and columns of the matrix a - // special treatment. This way, the - // values for these degrees of - // freedom have wrong, but - // well-defined values after solving - // the linear system. What we then - // have to do is to use the - // constraints to assign to them the - // values that they should have. This - // process, called distributing - // constraints, computes the values - // of constrained nodes from the - // values of the unconstrained ones, - // and requires only a single - // additional function call that you - // find at the end of this function: + // We continue with gradual improvements. The + // function that solves the linear system + // again uses the SSOR preconditioner, and is + // again unchanged except that we have to + // incorporate hanging node constraints. As + // mentioned above, the degrees of freedom + // from the ConstraintMatrix corresponding to + // hanging node constraints and boundary + // values have been removed from the linear + // system by giving the rows and columns of + // the matrix a special treatment. This way, + // the values for these degrees of freedom + // have wrong, but well-defined values after + // solving the linear system. What we then + // have to do is to use the constraints to + // assign to them the values that they should + // have. This process, called + // distributing constraints, + // computes the values of constrained nodes + // from the values of the unconstrained ones, + // and requires only a single additional + // function call that you find at the end of + // this function: template void Step6::solve () -- 2.39.5