How a Solver writes out its solution. More...

Inheritance diagram for exahype2.api.Solver.Solver.Plotter:

[legend]

Collaboration diagram for exahype2.api.Solver.Solver.Plotter:

Public Member Functions
	__init__ (self, "Solver" solver, str name=None)

	construct_output (self, exahype2_project, peano_project, plot)
	Has to be implemented by subclass.

str	output_file_prefix (self)
	Prefix of the files the plotter writes, including the path.

str	create_is_active_predicate (self)
	C++ predicate which holds if the plotter is active.

str	create_finish_call (self)
	C++ statement which moves the plotter on to its next output.

Data Fields
	name

Protected Member Functions
	_add_time_interval_bookkeeping_to_solver (self, float first_time_stamp, float time_in_between)
	Make the plotter active in regular time intervals.

Protected Attributes
	_solver

Detailed Description

How a Solver writes out its solution.

Abstract - concrete solvers have to provide a subclass that implements construct_output().

A solver can have an arbitrary number of plotters (exahype2.api.Solver.Solver.add_plotter()), e.g. one which writes VTK files for visualisation and one which writes checkpoints. Each plotter has a name which is unique per solver, and it decides itself when it is active. For this, it gives its solver's C++ class a method

bool is<Name>Active() const;

The solver's

bool wantsToPlot() const;

holds if any of its plotters is active. The generated main asks all solvers with a plotter (repositories::wantsToPlot()) and runs the plot phase if any of them wants to plot. The task graphs of all plotters of all solvers are added to the one plot graph, which the graph compiler then maps onto grid sweeps. Within the plot phase, every action set of a plotter is guarded by its plotter's is<Name>Active(), so only the active plotters do any work.

is<Name>Active() must not change throughout the plot phase. Each plotter therefore calls its

void finish<Name>();

which moves it on to its next output, in the unprepareTraversal() of its last task, i.e. after all of its tasks have run.

The class provides this bookkeeping for plotters which write output in regular time intervals (_add_time_interval_bookkeeping_to_solver()).

Definition at line 124 of file Solver.py.

Constructor & Destructor Documentation

◆ init()

exahype2.api.Solver.Solver.Plotter.__init__	(		self,
		"Solver"	solver,
		str	name = `None`
	)

Parameters

solver	exahype2.api.Solver The solver whose solution is written.
name	str or None Name of the plotter, which is unique per solver. It becomes part of the generated C++ method names, i.e. it has to be a valid C++ identifier. If None, the solver derives a name from the plotter's class name once the plotter is added (exahype2.api.Solver.Solver.add_plotter()).

Reimplemented in exahype2.api.fv.WriteCheckpoint.WriteCheckpoint, exahype2.api.rkfd4.WriteCheckpoint.WriteCheckpoint, exahype2.api.fv.PlotAsVTKFile.PlotAsVTKFile, and exahype2.api.rkfd4.PlotAsVTKFile.PlotAsVTKFile.

Definition at line 170 of file Solver.py.

Member Function Documentation

◆ _add_time_interval_bookkeeping_to_solver()

exahype2.api.Solver.Solver.Plotter._add_time_interval_bookkeeping_to_solver	(		self,
		float	first_time_stamp,
		float	time_in_between
	)

protected

Make the plotter active in regular time intervals.

Add the attribute _next<Name>TimeStamp plus the methods is<Name>Active() and finish<Name>() to the solver's C++ class. The plotter is active as soon as the solver's min time stamp has reached _next<Name>TimeStamp. finish<Name>() then increments _next<Name>TimeStamp by time_in_between.

The solver keeps these members once added, so we add them only once, even if the Peano 4 project is generated multiple times.

Parameters

first_time_stamp	float Time stamp of the first output.
time_in_between	float Time in between two outputs. Has to be positive.

Definition at line 243 of file Solver.py.

Here is the call graph for this function:

◆ construct_output()

exahype2.api.Solver.Solver.Plotter.construct_output	(	self,
		exahype2_project,
		peano_project,
		plot
	)

Has to be implemented by subclass.

plot: peano4.api.taskgraph.Graph The task graph of the surrounding exahype2_project's plotting phase, so the plotter can add its own tasks into it.

Reimplemented in exahype2.api.fv.PlotAsVTKFile.PlotAsVTKFile, exahype2.api.fv.WriteCheckpoint.WriteCheckpoint, exahype2.api.rkfd4.PlotAsVTKFile.PlotAsVTKFile, and exahype2.api.rkfd4.WriteCheckpoint.WriteCheckpoint.

Definition at line 190 of file Solver.py.

◆ create_finish_call()

str exahype2.api.Solver.Solver.Plotter.create_finish_call ( self )

C++ statement which moves the plotter on to its next output.

Insert it into the unprepareTraversal() of the plotter's last task.

Definition at line 226 of file Solver.py.

Here is the call graph for this function:

◆ create_is_active_predicate()

str exahype2.api.Solver.Solver.Plotter.create_is_active_predicate ( self )

C++ predicate which holds if the plotter is active.

Combine the guards of all of the plotter's action sets with it.

Definition at line 210 of file Solver.py.

Here is the call graph for this function:

◆ output_file_prefix()

str exahype2.api.Solver.Solver.Plotter.output_file_prefix ( self )

Prefix of the files the plotter writes, including the path.

The solver uses it to ensure that no two plotters write into the same files. Plotters which write no files return None.

Reimplemented in exahype2.api.fv.PlotAsVTKFile.PlotAsVTKFile, exahype2.api.fv.WriteCheckpoint.WriteCheckpoint, exahype2.api.rkfd4.PlotAsVTKFile.PlotAsVTKFile, and exahype2.api.rkfd4.WriteCheckpoint.WriteCheckpoint.

Definition at line 199 of file Solver.py.

Field Documentation

◆ _solver

exahype2.api.Solver.Solver.Plotter._solver

protected

Definition at line 184 of file Solver.py.

◆ name

exahype2.api.Solver.Solver.Plotter.name

Definition at line 187 of file Solver.py.

Referenced by solvers.aderdg.kernels.Gemms.Gemms.__repr__(), test_derive_load_store_compute_flag._FakeSubmodel.__repr__(), test_propagate_use_statements._FakeSubmodel.__repr__(), exaparty.api.particle.ExplicitEulerFixedSearchRadius.ExplicitEulerFixedSearchRadius.__setup_algorithm_steps(), exaparty.api.particle.AlgorithmStep.AlgorithmStep.__str__(), exahype2.api.Solver.Solver.Plotter._add_time_interval_bookkeeping_to_solver(), exaparty.api.particle.LeapfrogFixedSearchRadius.LeapfrogFixedSearchRadius._setup_algorithm_steps_dict(), exagrype.api.CCZ4Solver.CCZ4Solver._tasks_of_this_solver(), peano4.api.datamodel.DoF.DoF.additional_load_and_store_arguments_for_other_dof(), exaparty.api.particle.ExplicitEulerDynamicSearchRadius.ExplicitEulerDynamicSearchRadius.algorithm_steps(), exaparty.api.particle.tests.DastgenTestDummyParticle.DastgenTestDummyParticle.algorithm_steps(), exahype2.api.Solver.Solver.Plotter.create_finish_call(), exahype2.api.Solver.Solver.Plotter.create_is_active_predicate(), peano4.api.solversteps.UserActionSet.UserActionSet.get_action_set_name(), peano4.api.taskgraph.compiler.fuse-steps-illustrations._IllustrationActionSet.get_action_set_name(), test_fuse_steps._FakeActionSet.get_action_set_name(), peano4.api.datamodel.DoF.DoF.get_full_qualified_type(), peano4.api.datamodel.DoF.DoF.get_logical_type_name(), peano4.api.solversteps.Step.Step.get_observer_class_name(), dastgen2.attributes.Enumeration.Enumeration.get_to_string(), and exaparty.api.particle.Particle.Particle.readme_descriptor().

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

src/exahype2/api/Solver.py

Public Member Functions

Data Fields

Protected Member Functions

Protected Attributes

Detailed Description

Constructor & Destructor Documentation

◆ __init__()

Member Function Documentation

◆ _add_time_interval_bookkeeping_to_solver()

◆ construct_output()

◆ create_finish_call()

◆ create_is_active_predicate()

◆ output_file_prefix()

Field Documentation

◆ _solver

◆ name

◆ init()