 |
ASPECT
|
|
ASPECT
|
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) |
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.
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:
Definition at line 124 of file visualization.h.
|
explicit |
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.
|
virtual |
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 >, aspect::Postprocess::VisualizationPostprocessors::SphericalVelocityComponents< dim >, and aspect::Postprocess::VisualizationPostprocessors::DarcyVelocity< dim >.
|
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.
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 >.
|
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.
| [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. |
|
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.
| [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. |
|
private |
The physical units encoded by this visualization postprocessor.
Definition at line 223 of file visualization.h.