ASPECT
aspect::Postprocess::VisualizationPostprocessors::Interface< dim > Class Template Reference
Inheritance diagram for aspect::Postprocess::VisualizationPostprocessors::Interface< dim >:
[legend]

## Public Member Functions

virtual ~Interface ()

virtual void initialize ()

virtual void update ()

virtual void parse_parameters (ParameterHandler &prm)

virtual std::list< std::string > required_other_postprocessors () const

virtual void save (std::map< std::string, std::string > &status_strings) const

virtual void load (const std::map< std::string, std::string > &status_strings)

## Static Public Member Functions

static void declare_parameters (ParameterHandler &prm)

## Detailed Description

### template<int dim> class aspect::Postprocess::VisualizationPostprocessors::Interface< dim >

This class declares the public interface of visualization postprocessors. Visualization postprocessors are used to compute derived data, e.g. wave speeds, friction heating terms, etc, to be put into graphical output files. They are plugins for the aspect::Postprocess::Visualization class.

Classes derived from this type must implement the functions that save the state of the object and restore it (for checkpoint/restart capabilities) as well as functions that declare and read parameters. However, this class also already provides default implementations of these functions that simply do nothing. This is appropriate for objects that are stateless, as is commonly the case for visualization postprocessors.

Access to the data of the simulator is granted by the protected member functions of the SimulatorAccess class, i.e., classes implementing this interface will in general want to derive from both this Interface class as well as from the SimulatorAccess class.

### How visualization plugins work

There are two ways in which visualization plugins can work to get data from a simulation into an output file :

• Classes derived from this class can also derive from the deal.II class DataPostprocessor or any of the classes like DataPostprocessorScalar or DataPostprocessorVector. These classes can be thought of as filters: DataOut will call a function in them for every cell and this function will transform the values or gradients of the solution and other information such as the location of quadrature points into the desired quantity to output. A typical case would be if the quantity $$g(x)$$ you want to output can be written as a function $$g(x) = G(u(x),\nabla u(x), x, ...)$$ in a point-wise sense where $$u(x)$$ is the value of the solution vector (i.e., the velocities, pressure, temperature, etc) at an evaluation point. In the context of this program an example would be to output the density of the medium as a spatially variable function since this is a quantity that for realistic media depends point-wise on the values of the solution.

Using this way of describing a visualization postprocessor will yield a class that would then have the following base classes: - aspect::Postprocess::VisualizationPostprocessors::Interface - aspect::SimulatorAccess - DataPostprocessor or any of the other ones listed above

• The second possibility is for a class to not derive from DataPostprocessor but instead from the CellDataVectorCreator class. In this case, a visualization postprocessor would generate and return a vector that consists of one element per cell. The intent of this option is to output quantities that are not point-wise functions of the solution but instead can only be computed as integrals or other functionals on a per-cell basis. A typical case would be error estimators that do depend on the solution but not in a point-wise sense; rather, they yield one value per cell of the mesh. See the documentation of the CellDataVectorCreator class for more information.

Definition at line 124 of file visualization.h.

## § ~Interface()

template<int dim>
 virtual aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::~Interface ( )
virtual

Destructor. Does nothing but is virtual so that derived classes destructors are also virtual.

## § initialize()

template<int dim>
 virtual void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::initialize ( )
virtual

Initialize function.

## § update()

template<int dim>
 virtual void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::update ( )
virtual

Update any temporary information needed by the visualization postprocessor.

## § declare_parameters()

template<int dim>
 static void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::declare_parameters ( ParameterHandler & prm )
static

Declare the parameters this class takes through input files. Derived classes should overload this function if they actually do take parameters; this class declares a fall-back function that does nothing, so that postprocessor classes that do not take any parameters do not have to do anything at all.

This function is static (and needs to be static in derived classes) so that it can be called without creating actual objects (because declaring parameters happens before we read the input file and thus at a time when we don't even know yet which postprocessor objects we need).

## § parse_parameters()

template<int dim>
 virtual void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::parse_parameters ( ParameterHandler & prm )
virtual

Read the parameters this class declares from the parameter file. The default implementation in this class does nothing, so that derived classes that do not need any parameters do not need to implement it.

## § required_other_postprocessors()

template<int dim>
 virtual std::list aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::required_other_postprocessors ( ) const
virtual

A function that is used to indicate to the postprocessor manager which other postprocessor(s) the current one depends upon. The returned list contains the names (as strings, as you would write them in the input file) of the postprocessors it requires. The manager will ensure that these postprocessors are indeed used, even if they were not explicitly listed in the input file, and are indeed run before this postprocessor every time they are executed.

The postprocessors you can nominate here are of the general postprocessor class, not visualization postprocessors.

The default implementation of this function returns an empty list.

## § save()

template<int dim>
 virtual void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::save ( std::map< std::string, std::string > & status_strings ) const
virtual

Save the state of this object to the argument given to this function. This function is in support of checkpoint/restart functionality.

Derived classes can implement this function and should store their state in a string that is deposited under a key in the map through which the respective class can later find the status again when the program is restarted. A legitimate key to store data under is typeid(*this).name(). It is up to derived classes to decide how they want to encode their state.

The default implementation of this function does nothing, i.e., it represents a stateless object for which nothing needs to be stored at checkpoint time and nothing needs to be restored at restart time.

Parameters
 [in,out] status_strings The object into which implementations in derived classes can place their status under a key that they can use to retrieve the data.

## § load()

template<int dim>
 virtual void aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::load ( const std::map< std::string, std::string > & status_strings )
virtual

Restore the state of the object by looking up a description of the state in the passed argument under the same key under which it was previously stored.

The default implementation does nothing.

Parameters
 [in] status_strings The object from which the status will be restored by looking up the value for a key specific to this derived class.

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