Simply copy what we already in step-4 and nearly everywhere else.
SolverControl solver_control(1000, 1e-12);
SolverCG<Vector<double>> solver(solver_control);
solver.solve(system_matrix, solution, system_rhs, PreconditionIdentity());
+
+ std::cout << solver_control.last_step()
+ << " CG iterations needed to obtain convergence." << std::endl;
}
// Nothing has changed here.
int main()
{
- deallog.depth_console(2);
-
Step3 laplace_problem;
laplace_problem.run();
SolverControl solver_control(1000, 1e-12);
SolverCG<Vector<double>> solver(solver_control);
solver.solve(system_matrix, solution, system_rhs, PreconditionIdentity());
+
+ std::cout << solver_control.last_step()
+ << " CG iterations needed to obtain convergence." << std::endl;
}
// Nothing has changed here.
int main()
{
- deallog.depth_console(2);
-
Step3 laplace_problem;
laplace_problem.run();
@code
Number of active cells: 1024
Number of degrees of freedom: 1089
-DEAL:cg::Starting value 0.121094
-DEAL:cg::Convergence step 36 value 7.07761e-08
+36 CG iterations needed to obtain convergence.
Output written to solution.vtk
@endcode
-The first two lines is what we wrote to <code>std::cout</code>. The next
-two lines were generated by the CG solver because we called
-`deallog.depth_console(2);` in the `main()` function -- see
-the lengthy discussion there. These two lines prefixed by `DEAL:cg:` state
-the residual at the start of the
-iteration and that the solver needed 36
-iterations to bring the norm of the residual to $7.08\cdot 10^{-8}$, i.e. below
-the threshold $\tau$ which we have set in the `solve()` function.
-Note that we have asked the residual to be less than $10^{-6}$ times the
-norm of the right hand side vector; the starting value is (here) this
-norm of the right hand side vector, and there is indeed more than a
-factor of $10^{-6}$ between the two values shown.
-
The last line is the output we generated at the bottom of the
-`output_results()` function. The program also generated the file
+`output_results()` function: The program generated the file
<code>solution.vtk</code>, which is in the VTK format that is widely
used by many visualization programs today -- including the two
heavy-weights <a href="https://www.llnl.gov/visit">VisIt</a> and
// constructing better preconditioners.
//
// At the end of this process, the `solution` variable contains the
-// nodal values of the solution function.
+// nodal values of the solution function. At the end of the function, we
+// output how many Conjugate Gradients iterations it took to solve the
+// linear system.
void Step3::solve()
{
SolverControl solver_control(1000, 1e-6 * system_rhs.l2_norm());
SolverCG<Vector<double>> solver(solver_control);
solver.solve(system_matrix, solution, system_rhs, PreconditionIdentity());
+
+ std::cout << solver_control.last_step()
+ << " CG iterations needed to obtain convergence." << std::endl;
}
// before C++ programming, it often does not do much more than
// creating an object of the top-level class and calling its principle
// function.
-//
-// Finally, the first line of the function is used to enable output of
-// some diagnostics that deal.II can generate. The @p deallog
-// variable (which stands for deal-log, not de-allog) represents a
-// stream to which some parts of the library write output. For
-// example, iterative solvers will generate diagnostics (starting
-// residual, number of solver steps, final residual) as can be seen
-// when running this tutorial program.
-//
-// The output of @p deallog can be written to the console, to a file,
-// or both. Both are disabled by default since over the years we have
-// learned that a program should only generate output when a user
-// explicitly asks for it. But this can be changed, and to explain how
-// this can be done, we need to explain how @p deallog works: When
-// individual parts of the library want to log output, they open a
-// "context" or "section" into which this output will be placed. At
-// the end of the part that wants to write output, one exits this
-// section again. Since a function may call another one from within
-// the scope where this output section is open, output may in fact be
-// nested hierarchically into these sections. The LogStream class of
-// which @p deallog is a variable calls each of these sections a
-// "prefix" because all output is printed with this prefix at the left
-// end of the line, with prefixes separated by colons. There is always
-// a default prefix called "DEAL" (a hint at deal.II's history as the
-// successor of a previous library called "DEAL" and from which the
-// LogStream class is one of the few pieces of code that were taken
-// into deal.II).
-//
-// By default, @p logstream only outputs lines with zero prefixes --
-// i.e., all output is disabled because the default "DEAL" prefix is
-// always there. But one can set a different maximal number of
-// prefixes for lines that should be output to something larger, and
-// indeed here we set it to two by calling
-// LogStream::depth_console(). This means that for all screen output,
-// a context that has pushed one additional prefix beyond the default
-// "DEAL" is allowed to print its output to the screen ("console"),
-// whereas all further nested sections that would have three or more
-// prefixes active would write to @p deallog, but @p deallog does not
-// forward this output to the screen. Thus, running this example (or
-// looking at the "Results" section), you will see the solver
-// statistics prefixed with "DEAL:CG", which is two prefixes. This is
-// sufficient for the context of the current program, but you will see
-// examples later on (e.g., in step-22) where solvers are nested more
-// deeply and where you may get useful information by setting the
-// depth even higher.
int main()
{
- deallog.depth_console(2);
-
Step3 laplace_problem;
laplace_problem.run();
SolverCG<Vector<double>> solver(solver_control);
solver.solve(system_matrix, solution, system_rhs, PreconditionIdentity());
- // We have made one addition, though: since we suppress output from the
- // linear solvers, we have to print the number of iterations by hand.
std::cout << " " << solver_control.last_step()
<< " CG iterations needed to obtain convergence." << std::endl;
}
/**
- * The standard log object of deal.II:
+ * The standard log object of deal.II. Take a look at the documentation of
+ * the LogStream class for more information, as well as below.
+ *
+ * The @p deallog
+ * variable (which stands for deal-log, not de-allog) represents a
+ * stream to which some parts of the library write output. For
+ * example, iterative solvers will generate diagnostics (starting
+ * residual, number of solver steps, final residual).
+ *
+ * The output of @p deallog can be written to the console, to a file,
+ * or both. Both are disabled by default since over the years we have
+ * learned that a program should only generate output when a user
+ * explicitly asks for it. But this can be changed, and to explain how
+ * this can be done, we need to explain how @p deallog works: When
+ * individual parts of the library want to log output, they open a
+ * "context" or "section" into which this output will be placed. At
+ * the end of the part that wants to write output, one exits this
+ * section again. Since a function may call another one from within
+ * the scope where this output section is open, output may in fact be
+ * nested hierarchically into these sections. The LogStream class of
+ * which @p deallog is a variable calls each of these sections a
+ * "prefix" because all output is printed with this prefix at the left
+ * end of the line, with prefixes separated by colons. There is always
+ * a default prefix called "DEAL" (a hint at deal.II's history as the
+ * successor of a previous library called "DEAL" and from which the
+ * LogStream class is one of the few pieces of code that were taken
+ * into deal.II).
+ *
+ * By default, @p logstream only outputs lines with zero prefixes --
+ * i.e., all output is disabled because the default "DEAL" prefix is
+ * always there. But one can set a different maximal number of
+ * prefixes for lines that should be output to something larger,
+ * by calling LogStream::depth_console() with an integer argument. Let's
+ * assume you call it with `2` as argument. This means that for all screen
+ * output a context that has pushed one additional prefix beyond the default
+ * "DEAL" is allowed to print its output to the screen ("console"),
+ * whereas all further nested sections that would have three or more
+ * prefixes active would write to @p deallog, but @p deallog does not
+ * forward this output to the screen.
*/
extern LogStream deallog;
-675c675
-< deallog.depth_console(2);
----
-> //deallog.depth_console(2);
Number of active cells: 1024
Number of degrees of freedom: 1089
+36 CG iterations needed to obtain convergence.
Output written to solution.vtk
projects / dealii.git / commitdiff