Public Member Functions | Private Attributes | List of all members
aspect::Postprocess::VisualizationPostprocessors::Interface< dim > Class Template Reference
Inheritance diagram for aspect::Postprocess::VisualizationPostprocessors::Interface< dim >:
Inheritance graph

Public Member Functions

 Interface (const std::string &physical_units="")
virtual std::string get_physical_units () const
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)
- Public Member Functions inherited from aspect::Plugins::InterfaceBase
virtual ~InterfaceBase ()=default
virtual void initialize ()
virtual void update ()
virtual void parse_parameters (ParameterHandler &prm)

Private Attributes

const std::string physical_units

Additional Inherited Members

- Static Public Member Functions inherited from aspect::Plugins::InterfaceBase
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 :

Definition at line 124 of file visualization.h.

Constructor & Destructor Documentation

§ Interface()

template<int dim>
aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::Interface ( const std::string &  physical_units = "")

Constructor. The constructor takes as argument the physical units of the quantity (scalar or vector-valued) computed by derived classes. The empty string, "", refers to an unknown or nonexistent unit.

If a visualization postprocessor generates more than one output component, and if the different components have different physical units, then they should be separated by commas. If the different components have the same physical units, these units need to be specified only once and will apply to all components.

There are cases where the physical units can only be determined at a time later than when this constructor is called. An example is when a velocity is output as either m/s or m/year, depending on some run-time parameter. In those cases, derived classes should simply pass in an empty string to this constructor and instead overload the get_physical_units() function.

Member Function Documentation

§ get_physical_units()

template<int dim>
virtual std::string aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::get_physical_units ( ) const

Return the string representation of the physical units that a derived class has provided to the constructor of this class.

As mentioned in the documentation of the constructor, there are cases where a derived class doesn't know the physical units yet that correspond to what is being output at the time the constructor is called. In that case, the derived class can overload this function and return the correct units when the visualization postprocessor is executed.

Reimplemented in aspect::Postprocess::VisualizationPostprocessors::BoundaryStrainRateResidual< dim >, aspect::Postprocess::VisualizationPostprocessors::BoundaryVelocityResidual< dim >, and aspect::Postprocess::VisualizationPostprocessors::SphericalVelocityComponents< dim >.

§ required_other_postprocessors()

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

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.

Reimplemented in aspect::Postprocess::VisualizationPostprocessors::BoundaryStrainRateResidual< dim >, aspect::Postprocess::VisualizationPostprocessors::BoundaryVelocityResidual< dim >, aspect::Postprocess::VisualizationPostprocessors::Geoid< dim >, aspect::Postprocess::VisualizationPostprocessors::DynamicTopography< dim >, aspect::Postprocess::VisualizationPostprocessors::SurfaceDynamicTopography< dim >, and aspect::Postprocess::VisualizationPostprocessors::ParticleCount< dim >.

§ save()

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

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.

[in,out]status_stringsThe 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)

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.

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

Member Data Documentation

§ physical_units

template<int dim>
const std::string aspect::Postprocess::VisualizationPostprocessors::Interface< dim >::physical_units

The physical units encoded by this visualization postprocessor.

Definition at line 223 of file visualization.h.

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