}
- // @sect4{MixedLaplaceProblem::assemble_system} Similarly, the function that
- // assembles the linear system has mostly been discussed already in the
- // introduction to this example. At its top, what happens are all the usual
- // steps, with the addition that we do not only allocate quadrature and
- // <code>FEValues</code> objects for the cell terms, but also for face
- // terms. After that, we define the usual abbreviations for variables, and
- // the allocate space for the local matrix and right hand side
- // contributions, and the array that holds the global numbers of the degrees
- // of freedom local to the present cell.
+ // @sect4{MixedLaplaceProblem::assemble_system}
+
+ // Similarly, the function that assembles the linear system has mostly been
+ // discussed already in the introduction to this example. At its top, what
+ // happens are all the usual steps, with the addition that we do not only
+ // allocate quadrature and <code>FEValues</code> objects for the cell terms,
+ // but also for face terms. After that, we define the usual abbreviations
+ // for variables, and the allocate space for the local matrix and right hand
+ // side contributions, and the array that holds the global numbers of the
+ // degrees of freedom local to the present cell.
template <int dim>
void MixedLaplaceProblem<dim>::assemble_system ()
{
// @sect3{Equation data}
- // @sect4{Pressure right hand side} At present, the right hand side of the
- // pressure equation is simply the zero function. However, the rest of the
- // program is fully equipped to deal with anything else, if this is desired:
+ // @sect4{Pressure right hand side}
+
+ // At present, the right hand side of the pressure equation is simply the
+ // zero function. However, the rest of the program is fully equipped to deal
+ // with anything else, if this is desired:
template <int dim>
class PressureRightHandSide : public Function<dim>
{
}
- // @sect4{Pressure boundary values} The next are pressure boundary
- // values. As mentioned in the introduction, we choose a linear pressure
- // field:
+ // @sect4{Pressure boundary values}
+
+ // The next are pressure boundary values. As mentioned in the introduction,
+ // we choose a linear pressure field:
template <int dim>
class PressureBoundaryValues : public Function<dim>
{
// try to get familiar with that program first, then most of what is
// happening here should be mostly clear.
- // @sect4{TwoPhaseFlowProblem::TwoPhaseFlowProblem} First for the
- // constructor. We use $RT_k \times DQ_k \times DQ_k$ spaces. The time step
- // is set to zero initially, but will be computed before it is needed first,
- // as described in a subsection of the introduction.
+ // @sect4{TwoPhaseFlowProblem::TwoPhaseFlowProblem}
+
+ // First for the constructor. We use $RT_k \times DQ_k \times DQ_k$
+ // spaces. The time step is set to zero initially, but will be computed
+ // before it is needed first, as described in a subsection of the
+ // introduction.
template <int dim>
TwoPhaseFlowProblem<dim>::TwoPhaseFlowProblem (const unsigned int degree)
:
// @sect4{The BoussinesqFlowProblem helper functions}
- // @sect5{BoussinesqFlowProblem::get_maximal_velocity} Except for two small
- // details, the function to compute the global maximum of the velocity is
- // the same as in step-31. The first detail is actually common to all
- // functions that implement loops over all cells in the triangulation: When
- // operating in %parallel, each processor can only work on a chunk of cells
- // since each processor only has a certain part of the entire
- // triangulation. This chunk of cells that we want to work on is identified
- // via a so-called <code>subdomain_id</code>, as we also did in step-18. All
- // we need to change is hence to perform the cell-related operations only on
- // cells that are owned by the current process (as opposed to ghost or
- // artificial cells), i.e. for which the subdomain id equals the number of
- // the process ID. Since this is a commonly used operation, there is a
- // shortcut for this operation: we can ask whether the cell is owned by the
- // current processor using <code>cell-@>is_locally_owned()</code>.
+ // @sect5{BoussinesqFlowProblem::get_maximal_velocity}
+
+ // Except for two small details, the function to compute the global maximum
+ // of the velocity is the same as in step-31. The first detail is actually
+ // common to all functions that implement loops over all cells in the
+ // triangulation: When operating in %parallel, each processor can only work
+ // on a chunk of cells since each processor only has a certain part of the
+ // entire triangulation. This chunk of cells that we want to work on is
+ // identified via a so-called <code>subdomain_id</code>, as we also did in
+ // step-18. All we need to change is hence to perform the cell-related
+ // operations only on cells that are owned by the current process (as
+ // opposed to ghost or artificial cells), i.e. for which the subdomain id
+ // equals the number of the process ID. Since this is a commonly used
+ // operation, there is a shortcut for this operation: we can ask whether the
+ // cell is owned by the current processor using
+ // <code>cell-@>is_locally_owned()</code>.
//
// The second difference is the way we calculate the maximum value. Before,
// we could simply have a <code>double</code> variable that we checked
}
- // @sect5{BoussinesqFlowProblem::get_cfl_number} The next function does
- // something similar, but we now compute the CFL number, i.e., maximal
- // velocity on a cell divided by the cell diameter. This number is necessary
- // to determine the time step size, as we use a semi-explicit time stepping
- // scheme for the temperature equation (see step-31 for a discussion). We
- // compute it in the same way as above: Compute the local maximum over all
- // locally owned cells, then exchange it via MPI to find the global maximum.
+ // @sect5{BoussinesqFlowProblem::get_cfl_number}
+
+ // The next function does something similar, but we now compute the CFL
+ // number, i.e., maximal velocity on a cell divided by the cell
+ // diameter. This number is necessary to determine the time step size, as we
+ // use a semi-explicit time stepping scheme for the temperature equation
+ // (see step-31 for a discussion). We compute it in the same way as above:
+ // Compute the local maximum over all locally owned cells, then exchange it
+ // via MPI to find the global maximum.
template <int dim>
double BoussinesqFlowProblem<dim>::get_cfl_number () const
{
}
- // @sect5{BoussinesqFlowProblem::get_entropy_variation} Next comes the
- // computation of the global entropy variation $\|E(T)-\bar{E}(T)\|_\infty$
- // where the entropy $E$ is defined as discussed in the introduction. This
- // is needed for the evaluation of the stabilization in the temperature
- // equation as explained in the introduction. The entropy variation is
- // actually only needed if we use $\alpha=2$ as a power in the residual
- // computation. The infinity norm is computed by the maxima over quadrature
- // points, as usual in discrete computations.
+ // @sect5{BoussinesqFlowProblem::get_entropy_variation}
+
+ // Next comes the computation of the global entropy variation
+ // $\|E(T)-\bar{E}(T)\|_\infty$ where the entropy $E$ is defined as
+ // discussed in the introduction. This is needed for the evaluation of the
+ // stabilization in the temperature equation as explained in the
+ // introduction. The entropy variation is actually only needed if we use
+ // $\alpha=2$ as a power in the residual computation. The infinity norm is
+ // computed by the maxima over quadrature points, as usual in discrete
+ // computations.
//
// In order to compute this quantity, we first have to find the
// space-average $\bar{E}(T)$ and then evaluate the maximum. However, that
- // @sect5{BoussinesqFlowProblem::get_extrapolated_temperature_range} The
- // next function computes the minimal and maximal value of the extrapolated
- // temperature over the entire domain. Again, this is only a slightly
- // modified version of the respective function in step-31. As in the
- // function above, we collect local minima and maxima and then compute the
- // global extrema using the same trick as above.
+ // @sect5{BoussinesqFlowProblem::get_extrapolated_temperature_range}
+
+ // The next function computes the minimal and maximal value of the
+ // extrapolated temperature over the entire domain. Again, this is only a
+ // slightly modified version of the respective function in step-31. As in
+ // the function above, we collect local minima and maxima and then compute
+ // the global extrema using the same trick as above.
//
// As already discussed in step-31, the function needs to distinguish
// between the first and all following time steps because it uses a higher
}
- // @sect5{BoussinesqFlowProblem::compute_viscosity} The function that
- // calculates the viscosity is purely local and so needs no communication at
- // all. It is mostly the same as in step-31 but with an updated formulation
- // of the viscosity if $\alpha=2$ is chosen:
+ // @sect5{BoussinesqFlowProblem::compute_viscosity}
+
+ // The function that calculates the viscosity is purely local and so needs
+ // no communication at all. It is mostly the same as in step-31 but with an
+ // updated formulation of the viscosity if $\alpha=2$ is chosen:
template <int dim>
double
BoussinesqFlowProblem<dim>::
projects / dealii-svn.git / commitdiff