Reference documentation for deal.II version Git f264146 2017-10-18 16:34:34 -0400
Public Member Functions | Private Attributes | List of all members
DataPostprocessorVector< dim > Class Template Reference

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

Inheritance diagram for DataPostprocessorVector< dim >:
[legend]

Public Member Functions

 DataPostprocessorVector (const std::string &name, const UpdateFlags update_flags)
 
virtual std::vector< std::string > get_names () const
 
virtual std::vector< DataComponentInterpretation::DataComponentInterpretationget_data_component_interpretation () const
 
virtual UpdateFlags get_needed_update_flags () const
 
- Public Member Functions inherited from DataPostprocessor< dim >
virtual ~DataPostprocessor ()=default
 
virtual void evaluate_scalar_field (const DataPostprocessorInputs::Scalar< dim > &input_data, std::vector< Vector< double > > &computed_quantities) const
 
virtual void evaluate_vector_field (const DataPostprocessorInputs::Vector< dim > &input_data, std::vector< Vector< double > > &computed_quantities) const
 
- Public Member Functions inherited from Subscriptor
 Subscriptor ()
 
 Subscriptor (const Subscriptor &)
 
 Subscriptor (Subscriptor &&)
 
virtual ~Subscriptor ()
 
Subscriptoroperator= (const Subscriptor &)
 
Subscriptoroperator= (Subscriptor &&)
 
void subscribe (const char *identifier=nullptr) const
 
void unsubscribe (const char *identifier=nullptr) const
 
unsigned int n_subscriptions () const
 
void list_subscribers () const
 
template<class Archive >
void serialize (Archive &ar, const unsigned int version)
 

Private Attributes

const std::string name
 

Additional Inherited Members

- Static Public Member Functions inherited from Subscriptor
static::ExceptionBase & ExcInUse (int arg1, char *arg2, std::string &arg3)
 
static::ExceptionBase & ExcNoSubscriber (char *arg1, char *arg2)
 

Detailed Description

template<int dim>
class DataPostprocessorVector< dim >

This class provides a simpler interface to the functionality offered by the DataPostprocessor class in case one wants to compute only a single vector quantity (defined as having exactly dim components) from the finite element field passed to the DataOut class. For this particular case, it is clear what the returned value of DataPostprocessor::get_data_component_interpretation() should be and we pass the values returned by get_names() and get_needed_update_flags() to the constructor so that derived classes do not have to implement these functions by hand.

All derived classes have to do is implement a constructor and overload either DataPostprocessor::evaluate_scalar_field() or DataPostprocessor::evaluate_vector_field().

An example of how the closely related class DataPostprocessorScalar is used can be found in step-29. An example of how the DataPostprocessorTensor class can be used is found in the documentation of that class.

An example

A common example of what one wants to do with postprocessors is to visualize not just the value of the solution, but the gradient. Let's, for simplicity, assume that you have only a scalar solution. In fact, because it's readily available, let us simply take the step-6 solver to produce such a scalar solution. The gradient is a vector (with exactly dim components), so the current class fits the bill to produce the gradient through postprocessing. Then, the following code snippet implements everything you need to have to visualize the gradient:

template <int dim>
class GradientPostprocessor : public DataPostprocessorVector<dim>
{
public:
GradientPostprocessor ()
:
// call the constructor of the base class. call the variable to
// be output "grad_u" and make sure that DataOut provides us
// with the gradients:
DataPostprocessorVector<dim> ("grad_u",
{}
virtual
void
std::vector<Vector<double> > &computed_quantities) const
{
// ensure that there really are as many output slots
// as there are points at which DataOut provides the
// gradients:
AssertDimension (input_data.solution_gradients.size(),
computed_quantities.size());
// then loop over all of these inputs:
for (unsigned int p=0; p<input_data.solution_gradients.size(); ++p)
{
// ensure that each output slot has exactly 'dim'
// components (as should be expected, given that we
// want to create vector-valued outputs), and copy the
// gradients of the solution at the evaluation points
// into the output slots:
AssertDimension (computed_quantities[p].size(), dim);
for (unsigned int d=0; d<dim; ++d)
computed_quantities[p][d]
= input_data.solution_gradients[p][d];
}
}
};

The only thing that is necessary is to add another output to the call of DataOut::add_vector() in the run() function of the Step6 class of that example program. The corresponding code snippet would then look like this (where we also use VTU as the file format to output the data):

GradientPostprocessor<dim> gradient_postprocessor;
DataOut<dim> data_out;
data_out.attach_dof_handler (dof_handler);
data_out.add_data_vector (solution, "solution");
data_out.add_data_vector (solution, gradient_postprocessor);
data_out.build_patches ();
std::ofstream output ("solution.vtu");
data_out.write_vtu (output);

This leads to the following output for the solution and the gradients (you may want to compare with the solution shown in the results section of step-6; the current data is generated on a coarser mesh for simplicity):

data_postprocessor_vector_0.png
data_postprocessor_vector_1.png

In the second image, the background color corresponds to the magnitude of the gradient vector and the vector glyphs to the gradient itself. It may be surprising at first to see that from each vertex, multiple vectors originate, going in different directions. But that is because the solution is only continuous: in general, the gradient is discontinuous across edges, and so the multiple vectors originating from each vertex simply represent the differing gradients of the solution at each adjacent cell.

The output above – namely, the gradient \(\nabla u\) of the solution – corresponds to the temperature gradient if one interpreted step-6 as solving a steady-state heat transfer problem. It is very small in the central part of the domain because in step-6 we are solving an equation that has a coefficient \(a(\mathbf x)\) that is large in the central part and small on the outside. This can be thought as a material that conducts heat well, and consequently the temperature gradient is small. On the other hand, the "heat flux" corresponds to the quantity \(a(\mathbf x) \nabla u(\mathbf x)\). For the solution of that equation, the flux should be continuous across the interface. This is easily verified by the following modification of the postprocessor:

template <int dim>
class HeatFluxPostprocessor : public DataPostprocessorVector<dim>
{
public:
HeatFluxPostprocessor ()
:
// like above, but now also make sure that DataOut provides
// us with coordinates of the evaluation points:
DataPostprocessorVector<dim> ("heat_flux",
{}
virtual
void
std::vector<Vector<double> > &computed_quantities) const
{
AssertDimension (input_data.solution_gradients.size(),
computed_quantities.size());
for (unsigned int p=0; p<input_data.solution_gradients.size(); ++p)
{
AssertDimension (computed_quantities[p].size(), dim);
for (unsigned int d=0; d<dim; ++d)
// like above, but also multiply the gradients with
// the coefficient evaluated at the current point:
computed_quantities[p][d]
= coefficient (input_data.evaluation_points[p]) *
input_data.solution_gradients[p][d];
}
}
};

With this postprocessor, we get the following picture of the heat flux:

data_postprocessor_vector_2.png

As the background color shows, the gradient times the coefficient is now a continuous function. There are (large) vectors around the interface where the coefficient jumps (at half the distance between the center of the disk to the perimeter) that seem to point in the wrong direction; this is an artifact of the fact that the solution has a discontinuous gradient at these points and that the numerical solution on the current grid does not adequately resolve this interface. This, however, is not important to the current discussion.

Extension to the gradients of vector-valued problems

The example above uses a scalar solution and its gradient as an example. On the other hand, one may want to do something similar for the gradient of a vector-valued displacement field (such as the strain or stress of a displacement field, like those computed in step-8, step-17, step-18, or step-44). In that case, the solution is already vector valued and the stress is a (symmetric) tensor.

deal.II does not currently support outputting tensor-valued quantities, but they can of course be output as a collection of scalar-valued components of the tensor. This can be facilitated using the DataPostprocessorTensor class. The documentation of that class contains an example.

Author
Wolfgang Bangerth, 2011, 2017

Definition at line 770 of file data_postprocessor.h.

Constructor & Destructor Documentation

template<int dim>
DataPostprocessorVector< dim >::DataPostprocessorVector ( const std::string &  name,
const UpdateFlags  update_flags 
)

Constructor. Take the name of the single vector variable computed by classes derived from the current one, as well as the update flags necessary to compute this quantity.

Parameters
nameThe name by which the vector variable computed by this class should be made available in graphical output files.
update_flagsThis has to be a combination of update_values, update_gradients and update_hessians. If the DataPostprocessor is to be used in combination with DataOutFaces, you may also ask for a update of normals via the update_normal_vectors flag.

Definition at line 107 of file data_postprocessor.cc.

Member Function Documentation

template<int dim>
std::vector< std::string > DataPostprocessorVector< dim >::get_names ( ) const
virtual

Return the vector of strings describing the names of the computed quantities. Given the purpose of this class, this is a vector with dim entries all equal to the name given to the constructor.

Implements DataPostprocessor< dim >.

Definition at line 119 of file data_postprocessor.cc.

template<int dim>
std::vector< DataComponentInterpretation::DataComponentInterpretation > DataPostprocessorVector< dim >::get_data_component_interpretation ( ) const
virtual

This function returns information about how the individual components of output files that consist of more than one data set are to be interpreted. Since the current class is meant to be used for a single vector result variable, the returned value is obviously DataComponentInterpretation::component_is_part repeated dim times.

Reimplemented from DataPostprocessor< dim >.

Definition at line 129 of file data_postprocessor.cc.

template<int dim>
UpdateFlags DataPostprocessorVector< dim >::get_needed_update_flags ( ) const
virtual

Return which data has to be provided to compute the derived quantities. The flags returned here are the ones passed to the constructor of this class.

Implements DataPostprocessor< dim >.

Definition at line 140 of file data_postprocessor.cc.

Member Data Documentation

template<int dim>
const std::string DataPostprocessorVector< dim >::name
private

Copies of the two arguments given to the constructor of this class.

Definition at line 817 of file data_postprocessor.h.


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