 |
Reference documentation for deal.II version 9.2.0
|
|
Reference documentation for deal.II version 9.2.0
|
#include <deal.II/numerics/data_postprocessor.h>
Public Member Functions | |
| template<typename DoFHandlerType > | |
| void | set_cell (const typename DoFHandlerType::cell_iterator &cell) |
| template<typename DoFHandlerType > | |
| DoFHandlerType::cell_iterator | get_cell () const |
Public Attributes | |
| std::vector< Tensor< 1, spacedim > > | normals |
| std::vector< Point< spacedim > > | evaluation_points |
Private Attributes | |
| boost::any | cell |
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. First, the cell may be a cell in a DoFHandler or hp::DoFHandler object. Second, 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). Finally, if one considers classes such as DataOutRotation or DataOutStack, then spacedim being equal to 3 might mean that we are actually working on a DoFHandler<2> or hp::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 DoFHandler type to which the cell that is currently being processed belongs. This is knowledge you typically have in an application: for example, if your application runs in dim space dimensions, uses a hp::DoFHandler, 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<hp::DoFHandler<dim> > . For technical reasons, however, C++ will typically require you to write this as inputs.template get_cell<DoFHandler<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, assuming that we use a hp::DoFHandler:
Definition at line 153 of file data_postprocessor.h.
| void DataPostprocessorInputs::CommonInputs< spacedim >::set_cell | ( | const typename DoFHandlerType::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.
| DoFHandlerType::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.
| 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 171 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 185 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 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 216 of file data_postprocessor.h.
1.8.17