* </td></tr>
*
* <tr valign="top">
- * <td>step-19</td>
- * <td> Input parameter file handling. Merging
- * output of a parallel program.
- * </td></tr>
- *
- * <tr valign="top">
* <td>step-20</td>
* <td> Mixed finite elements. Using block
* matrices and block vectors to define more complicated solvers and
* <td>
* step-17,
* step-18,
- * step-19,
* step-40,
* step-55
* </td>
* <td> Input parameter handling
* </td>
* <td>
- * step-19,
* step-28,
* step-29,
* step-32,
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
// occurred. In addition, we have a constructor of this class that sets all
// these values to their default values, a function
// <code>declare_parameters</code> 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 <code>get_parameters</code> that can extract the
// values of these parameters from a ParameterHandler object.
template <int dim>
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 <code>FE_system</code> 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.
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:
// 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
// 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)
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".</li>
+"step-29" and step-33.</li>
<li>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
* 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
* 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.
*
* <h3>Declaring entries</h3>
*
// 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
projects / dealii.git / commitdiff