there would be many more functions in between these two. For example,
we might have made the mistake in the <code>assemble_system</code>
function, in which case stack frame 1 would be
-<code>LaplaceProblem::assemble_system</code>, stack frame 2
-would be <code>LaplaceProblem::run</code>, and stack frame 3
+<code>Step5::assemble_system</code>, stack frame 2
+would be <code>Step5::run</code>, and stack frame 3
would be <code>main()</code> — you get the idea.
using namespace dealii;
- // @sect3{The <code>LaplaceProblem</code> class template}
+ // @sect3{The <code>Step5</code> class template}
// The main class is mostly as in the
// previous example. The most visible
// <code>setup_system</code>. Apart from this,
// everything is as before.
template <int dim>
-class LaplaceProblem
+class Step5
{
public:
- LaplaceProblem ();
+ Step5 ();
void run ();
private:
}
- // @sect3{The <code>LaplaceProblem</code> class implementation}
+ // @sect3{The <code>Step5</code> class implementation}
- // @sect4{LaplaceProblem::LaplaceProblem}
+ // @sect4{Step5::Step5}
// This function is as before.
template <int dim>
-LaplaceProblem<dim>::LaplaceProblem () :
+Step5<dim>::Step5 () :
fe (1),
dof_handler (triangulation)
{}
- // @sect4{LaplaceProblem::setup_system}
+ // @sect4{Step5::setup_system}
// This is the function
// <code>make_grid_and_dofs</code> from the
// generation of the grid. Everything
// else is unchanged:
template <int dim>
-void LaplaceProblem<dim>::setup_system ()
+void Step5<dim>::setup_system ()
{
dof_handler.distribute_dofs (fe);
- // @sect4{LaplaceProblem::assemble_system}
+ // @sect4{Step5::assemble_system}
// As in the previous examples, this
// function is not changed much with
// are completely unchanged from
// before:
template <int dim>
-void LaplaceProblem<dim>::assemble_system ()
+void Step5<dim>::assemble_system ()
{
QGauss<dim> quadrature_formula(2);
}
- // @sect4{LaplaceProblem::solve}
+ // @sect4{Step5::solve}
// The solution process again looks
// mostly like in the previous
// declared, and the CG solver will
// do the rest for us:
template <int dim>
-void LaplaceProblem<dim>::solve ()
+void Step5<dim>::solve ()
{
SolverControl solver_control (1000, 1e-12);
SolverCG<> solver (solver_control);
}
- // @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
// filename for each refinement
// cycle.
template <int dim>
-void LaplaceProblem<dim>::output_results (const unsigned int cycle) const
+void Step5<dim>::output_results (const unsigned int cycle) const
{
DataOut<dim> data_out;
- // @sect4{LaplaceProblem::run}
+ // @sect4{Step5::run}
// The second to last thing in this
// program is the definition of the
// triangulation with the data in the
// file:
template <int dim>
-void LaplaceProblem<dim>::run ()
+void Step5<dim>::run ()
{
GridIn<dim> grid_in;
grid_in.attach_triangulation (triangulation);
{
deallog.depth_console (0);
- LaplaceProblem<2> laplace_problem_2d;
+ Step5<2> laplace_problem_2d;
laplace_problem_2d.run ();
// Finally, we have promised to
For completeness, we show what happens if the code we commented about
-in the destructor of the <code>LaplaceProblem</code> class is omitted
+in the destructor of the <code>Step6</code> class is omitted
from this example.
@code
#1 /u/bangerth/p/deal.II/1/deal.II/lib/libdeal_II_2d.g.so: FiniteElement<2>::~FiniteElement()
#2 ./step-6: FE_Poly<TensorProductPolynomials<2>, 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
From the above error message, we conclude that an object of type
<code>10DoFHandlerILi2EE</code> is still using the object of type
-<code>4FE_QILi2EE</code>. These are of course "mangled" names for
+<code>4FE_QILi2EE</code>. These are of course <a
+href="http://en.wikipedia.org/wiki/Name_mangling">"mangled" names</a> for
<code>DoFHandler</code> and <code>FE_Q</code>. The mangling works as
follows: the first number indicates the number of characters of the
template class, i.e. 10 for <code>DoFHandler</code> and 4
for<code>FE_Q</code>; 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
<code>dof_handler</code> object.
see that the exception was triggered in the
destructor of the <code>FiniteElement</code> class that was called
through a few more functions from the destructor of the
-<code>LaplaceProblem</code> class, exactly where we have commented out
+<code>Step6</code> class, exactly where we have commented out
the call to <code>DoFHandler::clear()</code>.
/* $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 */
using namespace dealii;
- // @sect3{The <code>LaplaceProblem</code> class template}
+ // @sect3{The <code>Step6</code> class template}
// The main class is again almost
// unchanged. Two additions, however,
// clear when we discuss its
// implementation.
template <int dim>
-class LaplaceProblem
+class Step6
{
public:
- LaplaceProblem ();
- ~LaplaceProblem ();
+ Step6 ();
+ ~Step6 ();
void run ();
}
- // @sect3{The <code>LaplaceProblem</code> class implementation}
+ // @sect3{The <code>Step6</code> class implementation}
- // @sect4{LaplaceProblem::LaplaceProblem}
+ // @sect4{Step6::Step6}
// The constructor of this class is
// mostly the same as before, but
// the desired polynomial degree
// (here <code>2</code>):
template <int dim>
-LaplaceProblem<dim>::LaplaceProblem ()
+Step6<dim>::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
// exactly the behavior sketched
// above. The reason is that member
// variables of the
- // <code>LaplaceProblem</code> class are
+ // <code>Step6</code> class are
// destructed bottom-up (i.e. in
// reverse order of their declaration
// in the class), as always in
// destructor, to the end of the
// results section of this example.
template <int dim>
-LaplaceProblem<dim>::~LaplaceProblem ()
+Step6<dim>::~Step6 ()
{
dof_handler.clear ();
}
- // @sect4{LaplaceProblem::setup_system}
+ // @sect4{Step6::setup_system}
// The next function is setting up
// all the variables that describe
// call will take care of this,
// however:
template <int dim>
-void LaplaceProblem<dim>::setup_system ()
+void Step6<dim>::setup_system ()
{
dof_handler.distribute_dofs (fe);
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
// code and nothing that you have to
// worry about.
template <int dim>
-void LaplaceProblem<dim>::assemble_system ()
+void Step6<dim>::assemble_system ()
{
const QGauss<dim> quadrature_formula(3);
- // @sect4{LaplaceProblem::solve}
+ // @sect4{Step6::solve}
// We continue with gradual
// improvements. The function that
// find at the end of this function:
template <int dim>
-void LaplaceProblem<dim>::solve ()
+void Step6<dim>::solve ()
{
SolverControl solver_control (1000, 1e-12);
SolverCG<> solver (solver_control);
}
- // @sect4{LaplaceProblem::refine_grid}
+ // @sect4{Step6::refine_grid}
// Instead of global refinement, we
// now use a slightly more elaborate
// doubles to represent error
// indicators.
template <int dim>
-void LaplaceProblem<dim>::refine_grid ()
+void Step6<dim>::refine_grid ()
{
Vector<float> estimated_error_per_cell (triangulation.n_active_cells());
}
- // @sect4{LaplaceProblem::output_results}
+ // @sect4{Step6::output_results}
// At the end of computations on each
// grid, and just before we continue
// generation of file names for that
// case):
template <int dim>
-void LaplaceProblem<dim>::output_results (const unsigned int cycle) const
+void Step6<dim>::output_results (const unsigned int cycle) const
{
Assert (cycle < 10, ExcNotImplemented());
- // @sect4{LaplaceProblem::run}
+ // @sect4{Step6::run}
// The final function before
// <code>main()</code> is again the main
// The rest of the loop looks as
// before:
template <int dim>
-void LaplaceProblem<dim>::run ()
+void Step6<dim>::run ()
{
for (unsigned int cycle=0; cycle<8; ++cycle)
{
{
deallog.depth_console (0);
- LaplaceProblem<2> laplace_problem_2d;
+ Step6<2> laplace_problem_2d;
laplace_problem_2d.run ();
}
// ...and if this should fail, try