From 58c97708c4c75db75020d4c39a275ef93604c02f Mon Sep 17 00:00:00 2001 From: Timo Heister Date: Mon, 16 Mar 2020 13:39:23 -0400 Subject: [PATCH] remove references to step-19 part of #2046 --- doc/doxygen/tutorial/tutorial.h.in | 8 -------- examples/step-28/doc/intro.dox | 2 +- examples/step-28/step-28.cc | 2 +- examples/step-29/doc/intro.dox | 8 ++++---- examples/step-29/doc/results.dox | 6 +++--- examples/step-33/step-33.cc | 2 +- examples/step-35/step-35.cc | 2 +- examples/step-36/doc/intro.dox | 3 +-- include/deal.II/base/data_out_base.h | 16 +++++++--------- include/deal.II/base/parameter_handler.h | 6 ++---- source/base/data_out_base.cc | 2 +- 11 files changed, 22 insertions(+), 35 deletions(-) diff --git a/doc/doxygen/tutorial/tutorial.h.in b/doc/doxygen/tutorial/tutorial.h.in index 04c4ce7579..4a7d7c7966 100644 --- a/doc/doxygen/tutorial/tutorial.h.in +++ b/doc/doxygen/tutorial/tutorial.h.in @@ -241,12 +241,6 @@ * * * - * step-19 - * Input parameter file handling. Merging - * output of a parallel program. - * - * - * * step-20 * Mixed finite elements. Using block * matrices and block vectors to define more complicated solvers and @@ -630,7 +624,6 @@ * * step-17, * step-18, - * step-19, * step-40, * step-55 * @@ -679,7 +672,6 @@ * Input parameter handling * * - * step-19, * step-28, * step-29, * step-32, diff --git a/examples/step-28/doc/intro.dox b/examples/step-28/doc/intro.dox index 2949fa03a4..b2370b688b 100644 --- a/examples/step-28/doc/intro.dox +++ b/examples/step-28/doc/intro.dox @@ -633,7 +633,7 @@ cheaper than if we omitted this step. After doing so, we resume our eigenvalue iterations on the next set of meshes. The program is controlled by a parameter file, using the ParameterHandler -class already mentioned in the step-19 example program. We will show a +class. We will show a parameter file in the results section of this tutorial. For the moment suffice it to say that it controls the polynomial degree of the finite elements used, the number of energy groups (even though all that is presently implemented are diff --git a/examples/step-28/step-28.cc b/examples/step-28/step-28.cc index 7845afe2c4..ffb92c00f7 100644 --- a/examples/step-28/step-28.cc +++ b/examples/step-28/step-28.cc @@ -1142,7 +1142,7 @@ namespace Step28 // occurred. In addition, we have a constructor of this class that sets all // these values to their default values, a function // declare_parameters that described to the ParameterHandler - // class already used in step-19 what parameters are accepted in the input + // class already used in step-29 what parameters are accepted in the input // file, and a function get_parameters that can extract the // values of these parameters from a ParameterHandler object. template diff --git a/examples/step-29/doc/intro.dox b/examples/step-29/doc/intro.dox index 7dcadffaba..09ae8fd037 100644 --- a/examples/step-29/doc/intro.dox +++ b/examples/step-29/doc/intro.dox @@ -24,10 +24,10 @@ element fields for discretizing each one of them. Basically this amounts to viewing a single complex valued equation as a system of two real valued equations. This short example demonstrates how this can be implemented in deal.II by using an FE_system object to stack two finite element -fields representing real and imaginary parts. We also revisit the -ParameterHandler class first used in step-19, which provides a -convenient way for reading parameters from a configuration file at runtime -without the need to recompile the program code. +fields representing real and imaginary parts. We also discuss the +ParameterHandler class, which provides a convenient way for reading parameters +from a configuration file at runtime without the need to recompile the +program code. The equations covered here fall into the class of vector-valued problems. A top level overview of this topic can be found in the @ref vector_valued module. diff --git a/examples/step-29/doc/results.dox b/examples/step-29/doc/results.dox index a7bf550135..3f54ebf19e 100644 --- a/examples/step-29/doc/results.dox +++ b/examples/step-29/doc/results.dox @@ -36,9 +36,9 @@ $d=0.3$, which amounts to a focus of the transducer lens at $x=0.5$, $y=0.3$. The coarse mesh is refined 5 times, resulting in 160x160 cells, and the output is written in vtu format. The parameter reader understands many more parameters -pertaining in particular to the generation of output, see the -explanation in step-19, but we need none of these -parameters here and therefore stick with their default values. +pertaining in particular to the generation of output, but we +need none of these parameters here and therefore stick with +their default values. Here's the console output of the program in debug mode: diff --git a/examples/step-33/step-33.cc b/examples/step-33/step-33.cc index 1f5d3bf6c6..b0539f4151 100644 --- a/examples/step-33/step-33.cc +++ b/examples/step-33/step-33.cc @@ -1359,7 +1359,7 @@ namespace Step33 // only prints something if verbose output has been requested) deals with // the interface we have in this program to the Trilinos library that // provides us with linear solvers. Similarly to including PETSc matrices - // in step-17, step-18, and step-19, all we need to do is to create a + // in step-17 and step-18, all we need to do is to create a // Trilinos sparse matrix instead of the standard deal.II class. The // system matrix is used for the Jacobian in each Newton step. Since we do // not intend to run this program in parallel (which wouldn't be too hard diff --git a/examples/step-35/step-35.cc b/examples/step-35/step-35.cc index 91c4508559..78ddf40a5a 100644 --- a/examples/step-35/step-35.cc +++ b/examples/step-35/step-35.cc @@ -126,7 +126,7 @@ namespace Step35 // In the constructor of this class we declare all the parameters. The // details of how this works have been discussed elsewhere, for example in - // step-19 and step-29. + // step-29. Data_Storage::Data_Storage() : form(Method::rotational) , dt(5e-4) diff --git a/examples/step-36/doc/intro.dox b/examples/step-36/doc/intro.dox index d6d97f6008..a54a36aa7c 100644 --- a/examples/step-36/doc/intro.dox +++ b/examples/step-36/doc/intro.dox @@ -256,8 +256,7 @@ or the number of eigenvalues we want to solve for. We could go much further with this but stop at making only a few of the things that one could select at run time actual input file parameters. In order to see what could be done in this regard, take a look at @ref step_29 -"step-29", step-33, and in particular @ref step_19 -"step-19". +"step-29" and step-33.
  • We use the FunctionParser class to make the potential $V(\mathbf x)$ a run-time parameter that can be specified in the input file as a diff --git a/include/deal.II/base/data_out_base.h b/include/deal.II/base/data_out_base.h index a00822a6f2..bdd9088e27 100644 --- a/include/deal.II/base/data_out_base.h +++ b/include/deal.II/base/data_out_base.h @@ -3167,15 +3167,13 @@ private: * This second use scenario is explained in some detail in the step-18 example * program. * - * Both these applications are implemented in the step-19 example program. - * There, a slight complication is also explained: in order to read data back - * into this object, you have to know the template parameters for the space - * dimension which were used when writing the data. If this knowledge is - * available at compile time, then this is no problem. However, if it is not - * (such as in a simple format converter), then it needs to be figured out at - * run time, even though the compiler already needs it at compile time. A way - * around using the DataOutBase::determine_intermediate_format_dimensions() - * function is explained in step-19. + * In order to read data back into this object, you have to know the template + * parameters for the space dimension which were used when writing the + * data. If this knowledge is available at compile time, then this is no + * problem. However, if it is not (such as in a simple format converter), then + * it needs to be figured out at run time, even though the compiler already + * needs it at compile time. A way around using the + * DataOutBase::determine_intermediate_format_dimensions() function. * * Note that the intermediate format is what its name suggests: a direct * representation of internal data. It isn't standardized and will change diff --git a/include/deal.II/base/parameter_handler.h b/include/deal.II/base/parameter_handler.h index 0968eb7509..483e79a5f5 100644 --- a/include/deal.II/base/parameter_handler.h +++ b/include/deal.II/base/parameter_handler.h @@ -53,10 +53,8 @@ class MultipleParameterLoop; * Input may be sorted into subsection trees in order to give the input a * logical structure, and input files may include other files. * - * The ParameterHandler class is discussed in detail in the - * @ref step_19 "step-19" - * example program, and is used in more realistic situations in step-29, - * step-33 and step-34. + * The ParameterHandler class is discussed in in step-29, + * step-33, and step-34. * *

    Declaring entries

    * diff --git a/source/base/data_out_base.cc b/source/base/data_out_base.cc index cb2873f3dd..57c38a64a2 100644 --- a/source/base/data_out_base.cc +++ b/source/base/data_out_base.cc @@ -6835,7 +6835,7 @@ namespace DataOutBase // first write tokens indicating the template parameters. we need this in // here because we may want to read in data again even if we don't know in - // advance the template parameters, see step-19 + // advance the template parameters: out << dim << ' ' << spacedim << '\n'; // then write a header -- 2.39.5