DataPostprocessorInputs::CommonInputs< spacedim > Struct Template Reference

#include <deal.II/numerics/data_postprocessor.h>

Inheritance diagram for DataPostprocessorInputs::CommonInputs< spacedim >:

Public Member Functions
	CommonInputs ()
template<int dim>
void	set_cell (const typename DoFHandler< dim, spacedim >::cell_iterator &cell)
template<int dim>
void	set_cell_and_face (const typename DoFHandler< dim, spacedim >::cell_iterator &cell, const unsigned int face_number)
template<int dim>
DoFHandler< dim, spacedim >::cell_iterator	get_cell () const
unsigned int	get_face_number () const

Public Attributes
std::vector< Tensor< 1, spacedim > >	normals
std::vector< Point< spacedim > >	evaluation_points

Private Attributes
boost::any	cell
unsigned int	face_number

Detailed Description

template<int spacedim>
struct DataPostprocessorInputs::CommonInputs< spacedim >

A base class containing common elements for the Scalar and Vector classes that are passed as arguments to DataPostprocessor::evaluate_scalar_field() and DataPostprocessor::evaluate_vector_field(). This common base class provides access to the points at which the solution is being evaluated, and a few other fields, as described in the following.

Normal vector access

If appropriate, i.e., if the object that is currently being processed is a face of a cell and the DataPostprocessor object is called from DataOutFaces or a similar class, then the current object also stores the normal vectors to the geometry on which output is generated, at these evaluation points.

On the other hand, if the solution is being evaluated on a cell, then the normal_vectors member variable does not contain anything useful.

Cell access

DataPostprocessor is typically called from classes such as DataOut or DataOutFaces that evaluate solution fields on a cell-by-cell basis. As a consequence, classes derived from DataPostprocessor (or DataPostprocessorScalar, DataPostprocessorVector, or DataPostprocessorTensor) sometimes need to use which cell is currently under investigation. Consequently, DataOut and similar classes pass the cell they are currently working on to DataPostprocessor via the classes in this namespace (and specifically the current base class).

However, the situation is not so simple. This is because the current class (and those derived from it) only knows the space dimension in which the output lives. But this can come from many sources. For example, if we are in 3d, this may be because we are working on a DoFHandler<3> or a DoFHandler<2,3> (i.e., either a 3d mesh, or a 2d meshes of a 2d surface embedded in 3d space). Another case is classes like DataOutRotation or DataOutStack, then spacedim being equal to 3 might mean that we are actually working on a DoFHandler<2>.

In other words, just because we know the value of the spacedim template argument of the current class does not mean that the data type of the cell iterator that is currently being worked on is obvious.

To make the cell iterator accessible nevertheless, this class uses an object of type boost::any to store the cell iterator. You can think of this as being a void pointer that can point to anything. To use what is being used therefore requires the user to know the data type of the thing being pointed to.

To make this work, the DataOut and related classes store in objects of the current type a representation of the cell. To get it back out, you would use the get_cell() function that requires you to say, as a template parameter, the dimension of the cell that is currently being processed. This is knowledge you typically have in an application: for example, if your application runs in dim space dimensions and you are currently using the DataOut class, then the cells that are worked on have data type DataOut<dim>::cell_iterator. Consequently, in a postprocessor, you can call inputs.get_cell<dim> . For technical reasons, however, C++ will typically require you to write this as inputs.template get_cell<dim> because the member function we call here requires that we explicitly provide the template argument.

Let us consider a complete example of a postprocessor that computes the fluid norm of the stress \(\|\sigma\| = \|\eta \nabla u\|\) from the viscosity \(\eta\) and the gradient of the fluid velocity, \(\nabla u\), assuming that the viscosity is something that depends on the cell's material id. This can be done using a class we derive from DataPostprocessorScalar where we overload the DataPostprocessor::evaluate_vector_field() function that receives the values and gradients of the velocity (plus of other solution variables such as the pressure, but let's ignore those for the moment). Then we could use code such as this:

template <int dim>
class ComputeStress : public DataPostprocessorScalar<dim>
{
  public:
    ... // overload other necessary member variables
    virtual
    void
    evaluate_vector_field
    (const DataPostprocessorInputs::Vector<dim> &input_data,
     std::vector<Vector<double> > &computed_quantities) const override
    {
      const typename DoFHandler<dim>::cell_iterator current_cell =
        input_data.template get_cell<dim>();
      const viscosity = look_up_viscosity (current_cell->material_id());
 
      for (unsigned int q=0; q<input_data.solution_gradients.size(); ++q)
        computed_quantities[q][0] =
          (viscosity * input_data.solution_gradients[q]).norm();
    }
};

Face access

When a DataPostprocessor object is used for output via the DataOutFaces class, it is sometimes necessary to also know which face is currently being worked on. Like accessing the cell as shown above, postprocessors can then query the face number via the CommonInputs::get_face_number() function. An example postprocessor that ignores its input and only puts the Boundary indicator into the output file would then look as follows:

template <int dim>
class BoundaryIds : public DataPostprocessorScalar<dim>
{
public:
  BoundaryIds()
    : DataPostprocessorScalar<dim>("boundary_id", update_default)
  {}
 
 
  virtual void
  evaluate_scalar_field(
    const DataPostprocessorInputs::Scalar<dim> &inputs,
    std::vector<Vector<double>> &computed_quantities) const override
  {
    AssertDimension(computed_quantities.size(),
                    inputs.solution_values.size());
 
    // Get the cell and face we are currently dealing with:
    const typename DoFHandler<dim>::active_cell_iterator cell =
      inputs.template get_cell<dim>();
    const unsigned int face = inputs.get_face_number();
 
    // Then fill the output fields with the boundary_id of the face
    for (auto &output : computed_quantities)
      {
        AssertDimension(output.size(), 1);
        output(0) = cell->face(face)->boundary_id();
      }
  }
};

Definition at line 193 of file data_postprocessor.h.

Constructor & Destructor Documentation

CommonInputs()

template<int spacedim>

DataPostprocessorInputs::CommonInputs< spacedim >::CommonInputs

Constructor.

Definition at line 25 of file data_postprocessor.cc.

Member Function Documentation

set_cell()

template<int spacedim>

template<int dim>

void DataPostprocessorInputs::CommonInputs< spacedim >::set_cell

(

const typename DoFHandler< dim, spacedim >::cell_iterator &

cell

)

Set the cell that is currently being used in evaluating the data for which the DataPostprocessor object is being called.

This function is not usually called from user space, but is instead called by DataOut and similar classes when creating the object that is then passed to DataPostprocessor.

set_cell_and_face()

template<int spacedim>

template<int dim>

void DataPostprocessorInputs::CommonInputs< spacedim >::set_cell_and_face	(	const typename DoFHandler< dim, spacedim >::cell_iterator &	cell,
		const unsigned int	face_number
	)

Set the cell and face number that is currently being used in evaluating the data for which the DataPostprocessor object is being called. Given that a face is required, this function is meant to be called by a class such as DataOutFaces.

This function is not usually called from user space, but is instead called by DataOutFaces and similar classes when creating the object that is then passed to DataPostprocessor.

get_cell()

template<int spacedim>

template<int dim>

DoFHandler< dim, spacedim >::cell_iterator DataPostprocessorInputs::CommonInputs< spacedim >::get_cell

(

)

const

Query the cell on which we currently produce graphical output. See the documentation of the current class for an example on how to use this function.

get_face_number()

template<int spacedim>

unsigned int DataPostprocessorInputs::CommonInputs< spacedim >::get_face_number

Query the face number on which we currently produce graphical output. See the documentation of the current class for an example on how to use the related get_cell() function that is meant to query the cell currently being worked on.

This function is intended for use when producing graphical output on faces, for example through the DataOutFaces class.

Definition at line 33 of file data_postprocessor.cc.

Member Data Documentation

normals

template<int spacedim>

std::vector<Tensor<1, spacedim> > DataPostprocessorInputs::CommonInputs< spacedim >::normals

An array of vectors normal to the faces of cells, evaluated at the points at which we are generating graphical output. This array is only used by the DataOutFaces class, and is left empty by all other classes for which the DataPostprocessor framework can be used. In the case of DataOutFaces, the array contains the outward normal vectors to the face, seen from the interior of the cell.

This array is only filled if a user-derived class overloads the DataPostprocessor::get_needed_update_flags(), and the function returns (possibly among other flags) UpdateFlags::update_normal_vectors. Alternatively, a class derived from DataPostprocessorScalar, DataPostprocessorVector, or DataPostprocessorTensor may pass this flag to the constructor of these three classes.

Definition at line 216 of file data_postprocessor.h.

evaluation_points

template<int spacedim>

std::vector<Point<spacedim> > DataPostprocessorInputs::CommonInputs< spacedim >::evaluation_points

An array of coordinates corresponding to the locations at which we are generating graphical output on one cell.

This array is only filled if a user-derived class overloads the DataPostprocessor::get_needed_update_flags(), and the function returns (possibly among other flags) UpdateFlags::update_quadrature_points. Alternatively, a class derived from DataPostprocessorScalar, DataPostprocessorVector, or DataPostprocessorTensor may pass this flag to the constructor of these three classes.

Note

In the current context, the flag UpdateFlags::update_quadrature_points is misnamed because we are not actually performing any quadrature. Rather, we are evaluating the solution at specific evaluation points, but these points are unrelated to quadrature (i.e., to computing integrals) and will, in general, not be located at Gauss points or the quadrature points of any of the typical quadrature rules.)

Definition at line 238 of file data_postprocessor.h.

cell

template<int spacedim>

boost::any DataPostprocessorInputs::CommonInputs< spacedim >::cell

private

The place where set_cell() stores the cell. Since the actual data type of the cell iterator can be many different things, the interface uses boost::any here. This makes assignment in set_cell() simple, but requires knowing the data type of the stored object in get_cell().

Definition at line 297 of file data_postprocessor.h.

face_number

template<int spacedim>

unsigned int DataPostprocessorInputs::CommonInputs< spacedim >::face_number

private

The place where set_cell_and_face() stores the number of the face being worked on.

Definition at line 303 of file data_postprocessor.h.

---

The documentation for this struct was generated from the following files:

• include/deal.II/numerics/data_postprocessor.h
• source/numerics/data_postprocessor.cc