From: bangerth Date: Mon, 3 Jan 2011 01:18:16 +0000 (+0000) Subject: Reindent a couple places. X-Git-Url: https://gitweb.dealii.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=0a5eacf90da1127bf396f585fbe69fb5373dc68b;p=dealii-svn.git Reindent a couple places. git-svn-id: https://svn.dealii.org/trunk@23103 0785d39b-7218-0410-832d-ea1e28bc413d --- diff --git a/deal.II/examples/step-4/step-4.cc b/deal.II/examples/step-4/step-4.cc index 0acd29ccbb..1790130c28 100644 --- a/deal.II/examples/step-4/step-4.cc +++ b/deal.II/examples/step-4/step-4.cc @@ -242,36 +242,41 @@ double BoundaryValues::value (const Point &p, // template that makes use of the functions // above. As before, we will write everything // as templates that have a formal parameter - // dim that we assume unknown at the time - // we define the template functions. Only - // later, the compiler will find a - // declaration of LaplaceProblem@<2@> (in - // the main function, actually) and - // compile the entire class with dim - // replaced by 2, a process referred to as - // `instantiation of a template'. When doing - // so, it will also replace instances of + // dim that we assume unknown at + // the time we define the template + // functions. Only later, the compiler will + // find a declaration of + // LaplaceProblem@<2@> (in the + // main function, actually) and + // compile the entire class with + // dim replaced by 2, a process + // referred to as `instantiation of a + // template'. When doing so, it will also + // replace instances of // RightHandSide@ by - // RightHandSide@<2@> and instantiate the - // latter class from the class template. + // RightHandSide@<2@> and + // instantiate the latter class from the + // class template. // // In fact, the compiler will also find a - // declaration LaplaceProblem@<3@> in - // main(). This will cause it to again go - // back to the general - // LaplaceProblem@ template, replace - // all occurrences of dim, this time by - // 3, and compile the class a second - // time. Note that the two instantiations + // declaration + // LaplaceProblem@<3@> in + // main(). This will cause it to + // again go back to the general + // LaplaceProblem@ + // template, replace all occurrences of + // dim, this time by 3, and + // compile the class a second time. Note that + // the two instantiations // LaplaceProblem@<2@> and - // LaplaceProblem@<3@> are completely - // independent classes; their only common - // feature is that they are both instantiated - // from the same general template, but they - // are not convertible into each other, for - // example, and share no code (both - // instantiations are compiled completely - // independently). + // LaplaceProblem@<3@> are + // completely independent classes; their only + // common feature is that they are both + // instantiated from the same general + // template, but they are not convertible + // into each other, for example, and share no + // code (both instantiations are compiled + // completely independently). // @sect4{LaplaceProblem::LaplaceProblem} @@ -319,12 +324,12 @@ LaplaceProblem::LaplaceProblem () : // either. This function therefore looks // exactly like in the previous example, // although it performs actions that in their - // details are quite different if dim - // happens to be 3. The only significant - // difference from a user's perspective is - // the number of cells resulting, which is - // much higher in three than in two space - // dimensions! + // details are quite different if + // dim happens to be 3. The only + // significant difference from a user's + // perspective is the number of cells + // resulting, which is much higher in three + // than in two space dimensions! template void LaplaceProblem::make_grid_and_dofs () { @@ -407,11 +412,14 @@ void LaplaceProblem::assemble_system () // quadrature points on the cell we are // presently on (previously, we only // required values and gradients of the - // shape function from the FEValues - // object, as well as the quadrature - // weights, JxW). We can tell the - // FEValues object to do for us by also - // giving it the update_quadrature_points flag: + // shape function from the + // FEValues object, as well as + // the quadrature weights, + // JxW). We can tell the + // FEValues object to do for + // us by also giving it the + // update_quadrature_points + // flag: FEValues fe_values (fe, quadrature_formula, update_values | update_gradients | update_quadrature_points | update_JxW_values); @@ -437,15 +445,18 @@ void LaplaceProblem::assemble_system () // Note, that a cell is a quadrilateral in // two space dimensions, but a hexahedron // in 3D. In fact, the - // active_cell_iterator data type is - // something different, depending on the - // dimension we are in, but to the outside - // world they look alike and you will - // probably never see a difference although - // the classes that this typedef stands for - // are in fact completely unrelated: - typename DoFHandler::active_cell_iterator cell = dof_handler.begin_active(), - endc = dof_handler.end(); + // active_cell_iterator data + // type is something different, depending + // on the dimension we are in, but to the + // outside world they look alike and you + // will probably never see a difference + // although the classes that this typedef + // stands for are in fact completely + // unrelated: + typename DoFHandler::active_cell_iterator + cell = dof_handler.begin_active(), + endc = dof_handler.end(); + for (; cell!=endc; ++cell) { fe_values.reinit (cell); @@ -489,18 +500,18 @@ void LaplaceProblem::assemble_system () // As a final remark to these loops: // when we assemble the local // contributions into - // cell_matrix(i,j), - // we have to multiply - // the gradients of shape functions $i$ - // and $j$ at point q_point and multiply - // it with the scalar weights JxW. This - // is what actually happens: + // cell_matrix(i,j), we + // have to multiply the gradients of + // shape functions $i$ and $j$ at point + // q_point and multiply it with the + // scalar weights JxW. This is what + // actually happens: // fe_values.shape_grad(i,q_point) - // returns a dim dimensional - // vector, represented by a - // Tensor@<1,dim@> object, and the - // operator* that multiplies it with - // the result of + // returns a dim + // dimensional vector, represented by a + // Tensor@<1,dim@> object, + // and the operator* that multiplies it + // with the result of // fe_values.shape_grad(j,q_point) // makes sure that the dim // components of the two vectors are @@ -509,13 +520,14 @@ void LaplaceProblem::assemble_system () // that then is multiplied with the // weights. Internally, this operator* // makes sure that this happens - // correctly for all dim components - // of the vectors, whether dim be - // 2, 3, or any other space dimension; - // from a user's perspective, this is - // not something worth bothering with, - // however, making things a lot simpler - // if one wants to write code dimension + // correctly for all dim + // components of the vectors, whether + // dim be 2, 3, or any + // other space dimension; from a user's + // perspective, this is not something + // worth bothering with, however, + // making things a lot simpler if one + // wants to write code dimension // independently. // With the local systems assembled, @@ -538,14 +550,14 @@ void LaplaceProblem::assemble_system () // As the final step in this function, we // wanted to have non-homogeneous boundary - // values in this example, unlike the - // one before. This is a simple task, we - // only have to replace the - // ZeroFunction used there by an object - // of the class which describes the - // boundary values we would like to use - // (i.e. the BoundaryValues class - // declared above): + // values in this example, unlike the one + // before. This is a simple task, we only + // have to replace the + // ZeroFunction used there by + // an object of the class which describes + // the boundary values we would like to use + // (i.e. the BoundaryValues + // class declared above): std::map boundary_values; VectorTools::interpolate_boundary_values (dof_handler, 0, @@ -611,9 +623,9 @@ void LaplaceProblem::solve () // dimension in the filename to generate // distinct filenames for each run (in a // better program, one would check whether - // dim can have other values than 2 or 3, - // but we neglect this here for the sake of - // brevity). + // dim can have other values + // than 2 or 3, but we neglect this here for + // the sake of brevity). template void LaplaceProblem::output_results () const { @@ -657,11 +669,11 @@ void LaplaceProblem::run () // looks mostly like in step-3, but if you // look at the code below, note how we first // create a variable of type - // LaplaceProblem@<2@> (forcing the - // compiler to compile the class template - // with dim replaced by 2) and run a - // 2d simulation, and then we do the whole - // thing over in 3d. + // LaplaceProblem@<2@> (forcing + // the compiler to compile the class template + // with dim replaced by + // 2) and run a 2d simulation, + // and then we do the whole thing over in 3d. // // In practice, this is probably not what you // would do very frequently (you probably @@ -684,16 +696,16 @@ void LaplaceProblem::run () // // Each of the two blocks is enclosed in // braces to make sure that the - // laplace_problem_2d variable goes out - // of scope (and releases the memory it - // holds) before we move on to allocate + // laplace_problem_2d variable + // goes out of scope (and releases the memory + // it holds) before we move on to allocate // memory for the 3d case. Without the // additional braces, the - // laplace_problem_2d variable would only - // be destroyed at the end of the function, - // i.e. after running the 3d problem, and - // would needlessly hog memory while the 3d - // run could actually use it. + // laplace_problem_2d variable + // would only be destroyed at the end of the + // function, i.e. after running the 3d + // problem, and would needlessly hog memory + // while the 3d run could actually use it. // // Finally, the first line of the function is // used to suppress some output. Remember @@ -702,7 +714,8 @@ void LaplaceProblem::run () // starting residual and the number of the // iteration where convergence was // detected. This can be suppressed through - // the deallog.depth_console(0) call. + // the deallog.depth_console(0) + // call. // // The rationale here is the following: the // deallog (i.e. deal-log, not de-allog)