From bb66c3566b862e0cb2668911fd32088a45006a9a Mon Sep 17 00:00:00 2001 From: bangerth Date: Tue, 16 Aug 2011 16:25:07 +0000 Subject: [PATCH] Rename main classes to Step5 and Step6. git-svn-id: https://svn.dealii.org/trunk@24100 0785d39b-7218-0410-832d-ea1e28bc413d --- deal.II/examples/step-5/doc/results.dox | 4 +-- deal.II/examples/step-5/step-5.cc | 34 +++++++++--------- deal.II/examples/step-6/doc/results.dox | 11 +++--- deal.II/examples/step-6/step-6.cc | 48 ++++++++++++------------- 4 files changed, 49 insertions(+), 48 deletions(-) diff --git a/deal.II/examples/step-5/doc/results.dox b/deal.II/examples/step-5/doc/results.dox index 7e0adf1d30..4a2e30bd5c 100644 --- a/deal.II/examples/step-5/doc/results.dox +++ b/deal.II/examples/step-5/doc/results.dox @@ -156,7 +156,7 @@ called from main() (stackframe 1). In realistic programs, there would be many more functions in between these two. For example, we might have made the mistake in the assemble_system function, in which case stack frame 1 would be -LaplaceProblem::assemble_system, stack frame 2 -would be LaplaceProblem::run, and stack frame 3 +Step5::assemble_system, stack frame 2 +would be Step5::run, and stack frame 3 would be main() — you get the idea. diff --git a/deal.II/examples/step-5/step-5.cc b/deal.II/examples/step-5/step-5.cc index f9594b1013..3394ad71bc 100644 --- a/deal.II/examples/step-5/step-5.cc +++ b/deal.II/examples/step-5/step-5.cc @@ -61,7 +61,7 @@ using namespace dealii; - // @sect3{The LaplaceProblem class template} + // @sect3{The Step5 class template} // The main class is mostly as in the // previous example. The most visible @@ -74,10 +74,10 @@ using namespace dealii; // setup_system. Apart from this, // everything is as before. template -class LaplaceProblem +class Step5 { public: - LaplaceProblem (); + Step5 (); void run (); private: @@ -354,20 +354,20 @@ void Coefficient::value_list (const std::vector > &points, } - // @sect3{The LaplaceProblem class implementation} + // @sect3{The Step5 class implementation} - // @sect4{LaplaceProblem::LaplaceProblem} + // @sect4{Step5::Step5} // This function is as before. template -LaplaceProblem::LaplaceProblem () : +Step5::Step5 () : fe (1), dof_handler (triangulation) {} - // @sect4{LaplaceProblem::setup_system} + // @sect4{Step5::setup_system} // This is the function // make_grid_and_dofs from the @@ -375,7 +375,7 @@ LaplaceProblem::LaplaceProblem () : // generation of the grid. Everything // else is unchanged: template -void LaplaceProblem::setup_system () +void Step5::setup_system () { dof_handler.distribute_dofs (fe); @@ -395,7 +395,7 @@ void LaplaceProblem::setup_system () - // @sect4{LaplaceProblem::assemble_system} + // @sect4{Step5::assemble_system} // As in the previous examples, this // function is not changed much with @@ -429,7 +429,7 @@ void LaplaceProblem::setup_system () // are completely unchanged from // before: template -void LaplaceProblem::assemble_system () +void Step5::assemble_system () { QGauss quadrature_formula(2); @@ -581,7 +581,7 @@ void LaplaceProblem::assemble_system () } - // @sect4{LaplaceProblem::solve} + // @sect4{Step5::solve} // The solution process again looks // mostly like in the previous @@ -633,7 +633,7 @@ void LaplaceProblem::assemble_system () // declared, and the CG solver will // do the rest for us: template -void LaplaceProblem::solve () +void Step5::solve () { SolverControl solver_control (1000, 1e-12); SolverCG<> solver (solver_control); @@ -650,7 +650,7 @@ void LaplaceProblem::solve () } - // @sect4{LaplaceProblem::output_results and setting output flags} + // @sect4{Step5::output_results and setting output flags} // Writing output to a file is mostly // the same as for the previous @@ -660,7 +660,7 @@ void LaplaceProblem::solve () // filename for each refinement // cycle. template -void LaplaceProblem::output_results (const unsigned int cycle) const +void Step5::output_results (const unsigned int cycle) const { DataOut data_out; @@ -796,7 +796,7 @@ void LaplaceProblem::output_results (const unsigned int cycle) const - // @sect4{LaplaceProblem::run} + // @sect4{Step5::run} // The second to last thing in this // program is the definition of the @@ -837,7 +837,7 @@ void LaplaceProblem::output_results (const unsigned int cycle) const // triangulation with the data in the // file: template -void LaplaceProblem::run () +void Step5::run () { GridIn grid_in; grid_in.attach_triangulation (triangulation); @@ -952,7 +952,7 @@ int main () { deallog.depth_console (0); - LaplaceProblem<2> laplace_problem_2d; + Step5<2> laplace_problem_2d; laplace_problem_2d.run (); // Finally, we have promised to diff --git a/deal.II/examples/step-6/doc/results.dox b/deal.II/examples/step-6/doc/results.dox index 64a04e2b40..2ed4ac63d4 100644 --- a/deal.II/examples/step-6/doc/results.dox +++ b/deal.II/examples/step-6/doc/results.dox @@ -111,7 +111,7 @@ from the optimal square. For completeness, we show what happens if the code we commented about -in the destructor of the LaplaceProblem class is omitted +in the destructor of the Step6 class is omitted from this example. @code @@ -132,7 +132,7 @@ Stacktrace: #1 /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so: FiniteElement<2>::~FiniteElement() #2 ./step-6: FE_Poly, 2>::~FE_Poly() #3 ./step-6: FE_Q<2>::~FE_Q() -#4 ./step-6: LaplaceProblem<2>::~LaplaceProblem() +#4 ./step-6: Step6<2>::~Step6() #5 ./step-6: main -------------------------------------------------------- make: *** [run] Aborted @@ -142,13 +142,14 @@ make: *** [run] Aborted From the above error message, we conclude that an object of type 10DoFHandlerILi2EE is still using the object of type -4FE_QILi2EE. These are of course "mangled" names for +4FE_QILi2EE. These are of course "mangled" names for DoFHandler and FE_Q. The mangling works as follows: the first number indicates the number of characters of the template class, i.e. 10 for DoFHandler and 4 forFE_Q; the rest of the text is then template arguments. From this we can already glean a little bit who's the -culprit here, and who the victim.: +culprit here, and who the victim: The one object that still uses the finite element is the dof_handler object. @@ -158,7 +159,7 @@ The stacktrace gives an indication of where the problem happened. We see that the exception was triggered in the destructor of the FiniteElement class that was called through a few more functions from the destructor of the -LaplaceProblem class, exactly where we have commented out +Step6 class, exactly where we have commented out the call to DoFHandler::clear(). diff --git a/deal.II/examples/step-6/step-6.cc b/deal.II/examples/step-6/step-6.cc index 9132e5ff77..657a12ade4 100644 --- a/deal.II/examples/step-6/step-6.cc +++ b/deal.II/examples/step-6/step-6.cc @@ -3,7 +3,7 @@ /* $Id$ */ /* */ -/* Copyright (C) 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2010 by the deal.II authors */ +/* Copyright (C) 2000, 2001, 2002, 2003, 2004, 2006, 2007, 2008, 2010, 2011 by the deal.II authors */ /* */ /* This file is subject to QPL and may not be distributed */ /* without copyright and license information. Please refer */ @@ -105,7 +105,7 @@ using namespace dealii; - // @sect3{The LaplaceProblem class template} + // @sect3{The Step6 class template} // The main class is again almost // unchanged. Two additions, however, @@ -122,11 +122,11 @@ using namespace dealii; // clear when we discuss its // implementation. template -class LaplaceProblem +class Step6 { public: - LaplaceProblem (); - ~LaplaceProblem (); + Step6 (); + ~Step6 (); void run (); @@ -214,9 +214,9 @@ void Coefficient::value_list (const std::vector > &points, } - // @sect3{The LaplaceProblem class implementation} + // @sect3{The Step6 class implementation} - // @sect4{LaplaceProblem::LaplaceProblem} + // @sect4{Step6::Step6} // The constructor of this class is // mostly the same as before, but @@ -228,14 +228,14 @@ void Coefficient::value_list (const std::vector > &points, // the desired polynomial degree // (here 2): template -LaplaceProblem::LaplaceProblem () +Step6::Step6 () : dof_handler (triangulation), fe (2) {} - // @sect4{LaplaceProblem::~LaplaceProblem} + // @sect4{Step6::~Step6} // Here comes the added destructor of // the class. The reason why we want @@ -325,7 +325,7 @@ LaplaceProblem::LaplaceProblem () // exactly the behavior sketched // above. The reason is that member // variables of the - // LaplaceProblem class are + // Step6 class are // destructed bottom-up (i.e. in // reverse order of their declaration // in the class), as always in @@ -361,13 +361,13 @@ LaplaceProblem::LaplaceProblem () // destructor, to the end of the // results section of this example. template -LaplaceProblem::~LaplaceProblem () +Step6::~Step6 () { dof_handler.clear (); } - // @sect4{LaplaceProblem::setup_system} + // @sect4{Step6::setup_system} // The next function is setting up // all the variables that describe @@ -406,7 +406,7 @@ LaplaceProblem::~LaplaceProblem () // call will take care of this, // however: template -void LaplaceProblem::setup_system () +void Step6::setup_system () { dof_handler.distribute_dofs (fe); @@ -507,7 +507,7 @@ void LaplaceProblem::setup_system () system_matrix.reinit (sparsity_pattern); } - // @sect4{LaplaceProblem::assemble_system} + // @sect4{Step6::assemble_system} // Next, we have to assemble the // matrix again. There are no code @@ -550,7 +550,7 @@ void LaplaceProblem::setup_system () // code and nothing that you have to // worry about. template -void LaplaceProblem::assemble_system () +void Step6::assemble_system () { const QGauss quadrature_formula(3); @@ -662,7 +662,7 @@ void LaplaceProblem::assemble_system () - // @sect4{LaplaceProblem::solve} + // @sect4{Step6::solve} // We continue with gradual // improvements. The function that @@ -693,7 +693,7 @@ void LaplaceProblem::assemble_system () // find at the end of this function: template -void LaplaceProblem::solve () +void Step6::solve () { SolverControl solver_control (1000, 1e-12); SolverCG<> solver (solver_control); @@ -708,7 +708,7 @@ void LaplaceProblem::solve () } - // @sect4{LaplaceProblem::refine_grid} + // @sect4{Step6::refine_grid} // Instead of global refinement, we // now use a slightly more elaborate @@ -824,7 +824,7 @@ void LaplaceProblem::solve () // doubles to represent error // indicators. template -void LaplaceProblem::refine_grid () +void Step6::refine_grid () { Vector estimated_error_per_cell (triangulation.n_active_cells()); @@ -912,7 +912,7 @@ void LaplaceProblem::refine_grid () } - // @sect4{LaplaceProblem::output_results} + // @sect4{Step6::output_results} // At the end of computations on each // grid, and just before we continue @@ -966,7 +966,7 @@ void LaplaceProblem::refine_grid () // generation of file names for that // case): template -void LaplaceProblem::output_results (const unsigned int cycle) const +void Step6::output_results (const unsigned int cycle) const { Assert (cycle < 10, ExcNotImplemented()); @@ -982,7 +982,7 @@ void LaplaceProblem::output_results (const unsigned int cycle) const - // @sect4{LaplaceProblem::run} + // @sect4{Step6::run} // The final function before // main() is again the main @@ -1034,7 +1034,7 @@ void LaplaceProblem::output_results (const unsigned int cycle) const // The rest of the loop looks as // before: template -void LaplaceProblem::run () +void Step6::run () { for (unsigned int cycle=0; cycle<8; ++cycle) { @@ -1147,7 +1147,7 @@ int main () { deallog.depth_console (0); - LaplaceProblem<2> laplace_problem_2d; + Step6<2> laplace_problem_2d; laplace_problem_2d.run (); } // ...and if this should fail, try -- 2.39.5