DataPostprocessorVector< dim > Class Template Reference

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

Inheritance diagram for DataPostprocessorVector< dim >:

Public Member Functions
	DataPostprocessorVector (const std::string &name, const UpdateFlags update_flags)
virtual std::vector< std::string >	get_names () const override
virtual std::vector< DataComponentInterpretation::DataComponentInterpretation >	get_data_component_interpretation () const override
virtual UpdateFlags	get_needed_update_flags () const override
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
template<class Archive >
void	serialize (Archive &ar, const unsigned int version)
Subscriptor functionality
Classes derived from Subscriptor provide a facility to subscribe to this object. This is mostly used by the SmartPointer class.
void	subscribe (std::atomic< bool > *const validity, const std::string &identifier="") const
void	unsubscribe (std::atomic< bool > *const validity, const std::string &identifier="") const
unsigned int	n_subscriptions () const
template<typename StreamType >
void	list_subscribers (StreamType &stream) const
void	list_subscribers () const

Static Public Member Functions
static ::ExceptionBase &	ExcInUse (int arg1, std::string arg2, std::string arg3)
static ::ExceptionBase &	ExcNoSubscriber (std::string arg1, std::string arg2)

Private Types
using	map_value_type = decltype(counter_map)::value_type
using	map_iterator = decltype(counter_map)::iterator

Private Member Functions
void	check_no_subscribers () const noexcept

Private Attributes
const std::string	name
const UpdateFlags	update_flags
std::atomic< unsigned int >	counter
std::map< std::string, unsigned int >	counter_map
std::vector< std::atomic< bool > * >	validity_pointers
const std::type_info *	object_info

Static Private Attributes
static std::mutex	mutex

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() as discussed in the DataPostprocessor class's documentation.

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. This is, in fact, precisely what step-19 needs, and it consequently uses the code below almost verbatim. 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",
                                  update_gradients)
  {}
 
  virtual
  void
  evaluate_scalar_field
  (const DataPostprocessorInputs::Scalar<dim> &input_data,
   std::vector<Vector<double> > &computed_quantities) const override
  {
    // 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):

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",
                                  update_gradients | update_quadrature_points)
  {}
 
  virtual
  void
  evaluate_scalar_field
  (const DataPostprocessorInputs::Scalar<dim> &input_data,
   std::vector<Vector<double> > &computed_quantities) const override
  {
    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:

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.

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.) In the example above, we need the location of these evaluation points because we need to evaluate the coefficients at these points.

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.

Definition at line 977 of file data_postprocessor.h.

Member Typedef Documentation

map_value_type

using Subscriptor::map_value_type = decltype(counter_map)::value_type

privateinherited

The data type used in counter_map.

Definition at line 229 of file subscriptor.h.

map_iterator

using Subscriptor::map_iterator = decltype(counter_map)::iterator

privateinherited

The iterator type used in counter_map.

Definition at line 234 of file subscriptor.h.

Constructor & Destructor Documentation

DataPostprocessorVector()

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

name

The name by which the vector variable computed by this class should be made available in graphical output files.

update_flags

This has to be a combination of update_values, update_gradients, update_hessians and update_quadrature_points. Note that the flag update_quadrature_points updates DataPostprocessorInputs::CommonInputs::evaluation_points. 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. The description of the flags can be found at UpdateFlags.

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 121 of file data_postprocessor.cc.

Member Function Documentation

get_names()

template<int dim>

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

overridevirtual

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 132 of file data_postprocessor.cc.

get_data_component_interpretation()

template<int dim>

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

overridevirtual

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 141 of file data_postprocessor.cc.

get_needed_update_flags()

template<int dim>

UpdateFlags DataPostprocessorVector< dim >::get_needed_update_flags ( ) const

overridevirtual

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 150 of file data_postprocessor.cc.

evaluate_scalar_field()

template<int dim>

void DataPostprocessor< dim >::evaluate_scalar_field ( const DataPostprocessorInputs::Scalar< dim > & input_data, std::vector< Vector< double > > & computed_quantities ) const

virtualinherited

This is the main function which actually performs the postprocessing. The second argument is a reference to the postprocessed data which already has correct size and must be filled by this function.

The function takes the values, gradients, and higher derivatives of the solution at all evaluation points, as well as other data such as the cell, via the first argument. Not all of the member vectors of this argument will be filled with data – in fact, derivatives and other quantities will only be contain valid data if the corresponding flags are returned by an overridden version of the get_needed_update_flags() function (implemented in a user's derived class). Otherwise those vectors will be in an unspecified state.

This function is called when the finite element field that is being converted into graphical data by DataOut or similar classes represents scalar data, i.e., if the finite element in use has only a single real-valued vector component.

Reimplemented in DataPostprocessors::BoundaryIds< dim >.

Definition at line 48 of file data_postprocessor.cc.

evaluate_vector_field()

template<int dim>

void DataPostprocessor< dim >::evaluate_vector_field ( const DataPostprocessorInputs::Vector< dim > & input_data, std::vector< Vector< double > > & computed_quantities ) const

virtualinherited

Same as the evaluate_scalar_field() function, but this function is called when the original data vector represents vector data, i.e., the finite element in use has multiple vector components. This function is also called if the finite element is scalar but the solution vector is complex-valued. If the solution vector to be visualized is complex-valued (whether scalar or not), then the input data contains first all real parts of the solution vector at each evaluation point, and then all imaginary parts.

Definition at line 59 of file data_postprocessor.cc.

subscribe()

void Subscriptor::subscribe ( std::atomic< bool > *const validity, const std::string & identifier = "" ) const

inherited

Subscribes a user of the object by storing the pointer validity. The subscriber may be identified by text supplied as identifier.

Definition at line 135 of file subscriptor.cc.

unsubscribe()

void Subscriptor::unsubscribe ( std::atomic< bool > *const validity, const std::string & identifier = "" ) const

inherited

Unsubscribes a user from the object.

Note

The identifier and the validity pointer must be the same as the one supplied to subscribe().

Definition at line 155 of file subscriptor.cc.

n_subscriptions()

unsigned int Subscriptor::n_subscriptions ( ) const

inlineinherited

Return the present number of subscriptions to this object. This allows to use this class for reference counted lifetime determination where the last one to unsubscribe also deletes the object.

Definition at line 300 of file subscriptor.h.

list_subscribers() [1/2]

template<typename StreamType >

void Subscriptor::list_subscribers ( StreamType & stream ) const

inlineinherited

List the subscribers to the input stream.

Definition at line 317 of file subscriptor.h.

list_subscribers() [2/2]

void Subscriptor::list_subscribers ( ) const

inherited

List the subscribers to deallog.

Definition at line 203 of file subscriptor.cc.

serialize()

template<class Archive >

void Subscriptor::serialize ( Archive & ar, const unsigned int version )

inlineinherited

Read or write the data of this object to or from a stream for the purpose of serialization using the BOOST serialization library.

This function does not actually serialize any of the member variables of this class. The reason is that what this class stores is only who subscribes to this object, but who does so at the time of storing the contents of this object does not necessarily have anything to do with who subscribes to the object when it is restored. Consequently, we do not want to overwrite the subscribers at the time of restoring, and then there is no reason to write the subscribers out in the first place.

Definition at line 309 of file subscriptor.h.

check_no_subscribers()

void Subscriptor::check_no_subscribers ( ) const

privatenoexceptinherited

Check that there are no objects subscribing to this object. If this check passes then it is safe to destroy the current object. It this check fails then this function will either abort or print an error message to deallog (by using the AssertNothrow mechanism), but will not throw an exception.

Note

Since this function is just a consistency check it does nothing in release mode.

If this function is called when there is an uncaught exception then, rather than aborting, this function prints an error message to the standard error stream and returns.

Definition at line 52 of file subscriptor.cc.

Member Data Documentation

name

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 1036 of file data_postprocessor.h.

update_flags

template<int dim>

const UpdateFlags DataPostprocessorVector< dim >::update_flags

private

Definition at line 1037 of file data_postprocessor.h.

counter

std::atomic<unsigned int> Subscriptor::counter

mutableprivateinherited

Store the number of objects which subscribed to this object. Initially, this number is zero, and upon destruction it shall be zero again (i.e. all objects which subscribed should have unsubscribed again).

The creator (and owner) of an object is counted in the map below if HE manages to supply identification.

We use the mutable keyword in order to allow subscription to constant objects also.

This counter may be read from and written to concurrently in multithreaded code: hence we use the std::atomic class template.

Definition at line 218 of file subscriptor.h.

counter_map

std::map<std::string, unsigned int> Subscriptor::counter_map

mutableprivateinherited

In this map, we count subscriptions for each different identification string supplied to subscribe().

Definition at line 224 of file subscriptor.h.

validity_pointers

std::vector<std::atomic<bool> *> Subscriptor::validity_pointers

mutableprivateinherited

In this vector, we store pointers to the validity bool in the SmartPointer objects that subscribe to this class.

Definition at line 240 of file subscriptor.h.

object_info

const std::type_info* Subscriptor::object_info

mutableprivateinherited

Pointer to the typeinfo object of this object, from which we can later deduce the class name. Since this information on the derived class is neither available in the destructor, nor in the constructor, we obtain it in between and store it here.

Definition at line 248 of file subscriptor.h.

mutex

std::mutex Subscriptor::mutex

staticprivateinherited

A mutex used to ensure data consistency when accessing the mutable members of this class. This lock is used in the subscribe() and unsubscribe() functions, as well as in list_subscribers().

Definition at line 271 of file subscriptor.h.

---

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

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