![]() |
Reference documentation for deal.II version 9.6.0
|
#include <deal.II/numerics/data_postprocessor.h>
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 | |
std::any | cell |
unsigned int | face_number |
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.
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.
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 std::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:
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:
Definition at line 191 of file data_postprocessor.h.
DataPostprocessorInputs::CommonInputs< spacedim >::CommonInputs | ( | ) |
Constructor.
Definition at line 24 of file data_postprocessor.cc.
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.
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.
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.
unsigned int DataPostprocessorInputs::CommonInputs< spacedim >::get_face_number | ( | ) | const |
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 32 of file data_postprocessor.cc.
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 214 of file data_postprocessor.h.
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.
Definition at line 236 of file data_postprocessor.h.
|
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 std::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 295 of file data_postprocessor.h.
|
private |
The place where set_cell_and_face() stores the number of the face being worked on.
Definition at line 301 of file data_postprocessor.h.