From 268e9926bb23b80d2f8790c8d2d7224951756633 Mon Sep 17 00:00:00 2001 From: wolf Date: Wed, 24 Apr 2002 12:42:36 +0000 Subject: [PATCH] Even more text. git-svn-id: https://svn.dealii.org/trunk@5726 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-14/step-14.cc | 131 +++++++++++++++++++++++++--- 1 file changed, 117 insertions(+), 14 deletions(-) diff --git a/deal.II/examples/step-14/step-14.cc b/deal.II/examples/step-14/step-14.cc index 06a5e79e7d..084a5289d7 100644 --- a/deal.II/examples/step-14/step-14.cc +++ b/deal.II/examples/step-14/step-14.cc @@ -53,11 +53,24 @@ # include #endif - - + // @sect{Evaluating the solution} + + // As mentioned in the introduction, + // significant parts of the program + // have simply been taken over from + // the step-13 example program. We + // therefore only comment on those + // things that are new. + // + // First, the framework for + // evaluation of solutions is + // unchanged, i.e. the base class is + // the same, and the class to + // evaluate the solution at a grid + // point is unchanged: namespace Evaluation { - + // @sect4{The EvaluationBase class} template class EvaluationBase { @@ -87,7 +100,7 @@ namespace Evaluation }; - + // @sect4{The PointValueEvaluation class} template class PointValueEvaluation : public EvaluationBase { @@ -158,6 +171,31 @@ namespace Evaluation }; + // @sect4{The GridOutput class} + + // Since this program has a more + // difficult structure (it computed + // a dual solution in addition to a + // primal one), writing out the + // solution is no more done by an + // evaluation object since we want + // to write both solutions at once + // into one file, and that requires + // some more information than + // available to the evaluation + // classes. + // + // However, we also want to look at + // the grids generated. This again + // can be done with one such + // class. Its structure is analog + // to the ``SolutionOutput'' class + // of the previous example program, + // so we do not discuss it here in + // more detail. Furthermore, + // everything that is used here has + // already been used in previous + // example programs. template class GridOutput : public EvaluationBase { @@ -204,10 +242,32 @@ namespace Evaluation }; + // @sect3{The Laplace solver classes} + // Next are the actual solver + // classes. Again, we discuss only + // the differences to the previous + // program. namespace LaplaceSolver { + // @sect{The Laplace solver base class} + + // This class is almost unchanged, + // with the exception that it + // declares two more functions: + // ``output_solution'' will be used + // to generate output files from + // the actual solutions computed by + // derived classes, and the + // ``set_refinement_cycle'' + // function by which the testing + // framework sets the number of the + // refinement cycle to a local + // variable in this class; this + // number is later used to generate + // filenames for the solution + // output. template class Base { @@ -252,7 +312,11 @@ namespace LaplaceSolver }; + // @sect4{The Laplace Solver class} + // Likewise, the ``Solver'' class + // is entirely unchanged and will + // thus not be discussed. template class Solver : public virtual Base { @@ -511,7 +575,47 @@ namespace LaplaceSolver - + // @sect{The PrimalSolver class} + + // The ``PrimalSolver'' class is + // also mostly unchanged except for + // overloading the functions + // ``solve_problem'', ``n_dofs'', + // and ``postprocess'' of the base + // class. These overloaded + // functions do nothing particular + // besides calling the functions of + // the base class -- that seems + // superfluous, but works around a + // bug in a popular compiler which + // requires us to write such + // functions for the following + // scenario: Besides the + // ``PrimalSolver'' class, we will + // have a ``DualSolver'', both + // derived from ``Solver''. We will + // then have a final classes which + // derived from these two, which + // will then have two instances of + // the ``Solver'' class as its base + // classes. If we want, for + // example, the number of degrees + // of freedom of the primal solver, + // we would have to indicate this + // like so: + // ``PrimalSolver::n_dofs()''. + // However, the compiler does not + // accept this since the ``n_dofs'' + // function is actually from a base + // class of the ``PrimalSolver'' + // class, so we have to inject the + // name from the base to the + // derived class using these + // additional functions. + // + // Except for the reimplementation + // of these three functions, this + // class is also unchanged. template class PrimalSolver : public Solver { @@ -523,7 +627,6 @@ namespace LaplaceSolver const Function &rhs_function, const Function &boundary_values); - //TODO!! virtual void solve_problem (); @@ -633,7 +736,7 @@ namespace LaplaceSolver }; - + //TODO!! template class RefinementGlobal : public PrimalSolver { @@ -1244,7 +1347,7 @@ namespace Data // evaluation point (3/4,3/4) in // this example is a grid point, // we refine twice globally: - coarse_grid.refine_global (2); + coarse_grid.refine_global (4); }; }; @@ -2609,7 +2712,7 @@ run_simulation (LaplaceSolver::Base &solver, }; - if (solver.n_dofs() < 5000) + if (solver.n_dofs() < 500000) solver.refine_grid (); else break; @@ -2625,17 +2728,17 @@ template void solve_problem () { Triangulation triangulation (Triangulation::smoothing_on_refinement); - const FE_Q primal_fe(1); - const FE_Q dual_fe(2); + const FE_Q primal_fe(3); + const FE_Q dual_fe(4); const QGauss4 quadrature; const QGauss4 face_quadrature; const Data::SetUpBase *data = - new Data::SetUp,dim> (); + new Data::SetUp,dim> (); data->create_coarse_grid (triangulation); - const Point evaluation_point(0.5,0.5); + const Point evaluation_point(0.75,0.75); const DualFunctional::PointValueEvaluation dual_functional (evaluation_point); @@ -2651,7 +2754,7 @@ void solve_problem () TableHandler results_table; Evaluation::PointValueEvaluation - postprocessor1 (Point(0.5,0.5), results_table); + postprocessor1 (Point(0.75,0.75), results_table); Evaluation::GridOutput postprocessor2 ("grid"); -- 2.39.5