Abstract base class for all ExaHyPE 2 solvers. More...

Inheritance diagram for exahype2.api.Solver.Solver:

[legend]

Collaboration diagram for exahype2.api.Solver.Solver:

Data Structures
class	GridConstruction
	How a Solver drives the construction of the mesh it runs on. More...

class	MeshAdaptation
	How a Solver adapts its mesh and rebalances its load between two time steps. More...

class	NumericalScheme
	The concrete discretisation (Finite Volumes, ADER-DG, ...) realised by a Solver. More...

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

class	SolverGenerator
	Turns a Solver into actual classes. More...

Public Member Functions
	__init__ (self, str name, VariableSpecification unknowns, VariableSpecification auxiliary_variables)
	Create solver.

str	__str__ (self)

str	name (self)
	Unique solver name.

"Solver.NumericalScheme"	numerical_scheme (self)

	numerical_scheme (self, "Solver.NumericalScheme" value)

List["Solver.Plotter"]	plotters (self)
	All plotters of the solver, in the order they have been added.

	add_plotter (self, "Solver.Plotter" plotter)
	Add a plotter to the solver.

"Solver.Plotter"	plotter (self)
	Shorthand for solvers with at most one plotter.

	plotter (self, "Solver.Plotter" value)

int	unknowns (self)

int	auxiliary_variables (self)

str	user_solver_includes (self)
	Add further includes to this property, if your solver requires some additional routines from other header files.

	add_user_solver_includes (self, str value)
	Add further includes to this property, if your solver requires some additional routines from other header files.

	set_solver_constants (self, str datastring)

	add_solver_constants (self, str datastring)

List[str]	variable_names_per_entry (self)
	One name per entry of Q, i.e.

str	get_name_of_global_instance (self)

List[PDETerm]	pde_terms (self)
	All PDE terms (flux, eigenvalues, ...) registered with this solver, in registration order.

bool	requires_user_class (self)
	True iff at least one PDE term has no implementation.

str	get_name_of_solver_class (self)
	Name of the C++ class the solver repository instantiates: <SolverName> if requires_user_class, Abstract<SolverName> otherwise.

	add_pde_term (self, PDETerm term)
	Register a PDE term with this solver, or replace the one already registered under the same name and statelessness.

	remove_pde_term (self, str name, bool stateless=False)
	Remove a previously registered PDE term by name and statelessness.

PDETerm	get_pde_term (self, str name, bool stateless=False)
	Look up a previously registered PDE term by name and statelessness.

	add_abstract_solver_attribute (self, str declaration)
	Add a raw C++ member attribute declaration to the generated Abstract<SolverName> class (.

	add_abstract_solver_method (self, str declaration, Callable[[str], str] definition_generator)
	Add a raw C++ method to the generated Abstract<SolverName> class: declaration goes into the class body (public section), verbatim.

str	create_readme_descriptor (self, domain_offset, domain_size)
	Return a human-readable description of this solver instance, to be embedded into the generated project's README.

	generate_solver_realisation (self, exahype2_project, peano_project, setup_simulation, time_step, plot, mesh_adaptation)
	Turn this solver specification into a task graph and create the required C++ kernels/stubs.

Data Fields
	solver_generator

	pde_terms
	True iff at least one PDE term has no implementation.

	mesh_adaptation
	Turn this solver specification into a task graph and create the required C++ kernels/stubs.

Static Public Attributes
str	SolutionUpdateTaskTag = "exahype2.api.Solver.SolutionUpdateTaskTag"
	Tag of all tasks which write a new solution.

str	IntermediateSolutionUpdateTag = "exahype2.api.Solver.IntermediateSolutionUpdateTag"
	Tag of all tasks which write an intermediate solution.

Protected Member Functions
int	_register_variables (self, VariableSpecification variables, int offset)
	Translate a plain int or a name-to-multiplicity dict into a total variable count, and - for the dict case - add each name's position within Q to _variable_positions.

str	_get_default_includes (self)
	Includes every generated action set can rely on being available, regardless of which action sets a concrete discretisation (e.g.

str	_unknown_identifier (self)

	_add_wants_to_plot_to_solver (self)
	Add wantsToPlot() to the solver's C++ class: It holds if any of the solver's plotters is active (exahype2.api.Solver.Solver.Plotter).

	_add_checkpoint_meta_data_to_solver (self)
	Override exahype2::Solver::toCheckpointMetaData() in the solver's C++ class such that it also writes the attributes added through add_abstract_solver_attribute(), e.g.

Protected Attributes
	_name
	Create solver.

	_unknowns

	_auxiliary_variables

	_user_solver_includes

	_solver_constants

	_numerical_scheme

	_plotters
	All plotters of the solver, in the order they have been added.

Detailed Description

Abstract base class for all ExaHyPE 2 solvers.

Every discretisation ExaHyPE 2 ships (Finite Volumes, ADER-DG, Runge-Kutta Discontinuous Galerkin, Runge-Kutta Finite Differences, ...) is, from the project's point of view, a black box that has to answer a small set of questions: what data does it need on the mesh, which action sets realise its algorithmic steps, and how does it plug into the code generation. This class holds exactly that common contract plus the bits of bookkeeping (name, includes, solver constants, the unknowns/auxiliary_variables variable-shortcut logic) that every concrete solver has historically reimplemented identically. It does not know anything about a concrete discretisation - it neither creates the actual mesh data structures nor the actual action sets, as this remains solver-specific and thus has to be added by all subclasses.

A concrete solver typically extends the constructor with its own discretisation-specific parameters (patch size, polynomial order, time stepping scheme, ...), calls Solver.__init__() for the shared part, and then implements the abstract methods below.

See also: exahype2.api.Project

Definition at line 17 of file Solver.py.

Constructor & Destructor Documentation

◆ init()

exahype2.api.Solver.Solver.__init__	(		self,
		str	name,
		VariableSpecification	unknowns,
		VariableSpecification	auxiliary_variables
	)

Create solver.

name: str A unique name for the solver. This one is used for all generated classes. The generated C++ object instance also incorporates this name.

unknowns: int or dict Number of unknowns per mesh entry (Finite Volume voxel, DG degree of freedom, ...). Eventually, unknowns and auxiliary_variables are merged into one big vector, but the solver still has to be able to distinguish them, as only the unknowns are subject to the actual PDE formulation. Can be specified either as a plain int, or as a dict mapping variable name onto multiplicity (e.g. {"rho": 1, "j": 3} for a scalar density plus a 3d momentum). If dicts are used, the generated Abstract<SolverName> class hosts a nested struct Variables with one constant per name, so user code can write Q[Variables::j+1] instead of having to remember the offset into the unknowns array by hand.

auxiliary_variables: int or dict Same semantics as unknowns, but for variables that may be space-dependent yet do not change over time. Their names follow the unknowns' names, as the auxiliary variables follow the unknowns in Q.

If names are used at all, they have to cover all unknowns and all auxiliary variables, i.e. you cannot pass a dict for one and a non-zero int for the other.

The variables cannot be changed after construction: the numerical scheme sizes its data structures from them as soon as it is assigned to the solver.

Reimplemented in exagrype.api.CCZ4Solver.CCZ4Solver.

Definition at line 375 of file Solver.py.

Member Function Documentation

◆ str()

str exahype2.api.Solver.Solver.__str__ ( self )

Definition at line 531 of file Solver.py.

Referenced by peano4.api.toolbox.particles.postprocessing.ParticleVTUReader.VTUParticleSet.__repr__().

Here is the caller graph for this function:

◆ _add_checkpoint_meta_data_to_solver()

exahype2.api.Solver.Solver._add_checkpoint_meta_data_to_solver ( self )

protected

Override exahype2::Solver::toCheckpointMetaData() in the solver's C++ class such that it also writes the attributes added through add_abstract_solver_attribute(), e.g.

the time stamps of the next outputs of the plotters. Only attributes of type double, float or int are written, with their name without leading underscore as key.

The counterpart override of exahype2::Solver::fromCheckpointMetaData() restores these attributes. Afterwards, it calls finish<Name>() of all plotters: A plotter which has written output at the time of the checkpoint has done so before it has moved on to its next output, as it only moves on at the end of the plot phase (exahype2.api.Solver.Solver.Plotter). The checkpoint hence holds the time stamp of an output which has already been written. finish<Name>() moves such a plotter on, exactly as the original run has done after the checkpoint, so the restarted simulation does not write this output again.

The overrides evaluate the attributes and plotters the solver has when the C++ code is written, and they are added only once, even if several checkpoints use them or the Peano 4 project is generated multiple times.

Definition at line 867 of file Solver.py.

References exahype2.api.Solver.Solver._plotters, exahype2.api.Solver.Solver.add_abstract_solver_method(), and ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ _add_wants_to_plot_to_solver()

exahype2.api.Solver.Solver._add_wants_to_plot_to_solver ( self )

protected

Add wantsToPlot() to the solver's C++ class: It holds if any of the solver's plotters is active (exahype2.api.Solver.Solver.Plotter).

Solvers without plotters do not get the method, as nobody asks them. The method is added only once, even if the Peano 4 project is generated multiple times, and it evaluates the plotters the solver has when the C++ code is written.

Definition at line 840 of file Solver.py.

References exahype2.api.Solver.Solver._plotters, exahype2.api.Solver.Solver.add_abstract_solver_method(), and ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ _get_default_includes()

str exahype2.api.Solver.Solver._get_default_includes ( self )

protected

Includes every generated action set can rely on being available, regardless of which action sets a concrete discretisation (e.g.

exahype2.api.fv) actually attaches -

See also: exahype2.api.fv.actionsets.AbstractFVActionSet.get_includes().

Definition at line 659 of file Solver.py.

Referenced by solvers.fv.FV.FV.create_action_sets().

Here is the caller graph for this function:

◆ _register_variables()

int exahype2.api.Solver.Solver._register_variables	(		self,
		VariableSpecification	variables,
		int	offset
	)

protected

Translate a plain int or a name-to-multiplicity dict into a total variable count, and - for the dict case - add each name's position within Q to _variable_positions.

Called once for unknowns (offset 0) and once for auxiliary_variables (offset = number of unknowns), so the two end up in one contiguous name/offset table.

Definition at line 503 of file Solver.py.

References ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ _unknown_identifier()

str exahype2.api.Solver.Solver._unknown_identifier ( self )

protected

Definition at line 681 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._name, solvers.elliptic.AMRMarker.AMRMarker._name, solvers.elliptic.ConstrainedPoissonEquationForMarkerOnCells.ConstrainedPoissonEquationForMarkerOnCells._name, solvers.fv.EnclaveTasking.EnclaveTasking._name, solvers.fv.FV.FV._name, solvers.limiting.PosterioriLimiting.PosterioriLimiting._name, solvers.limiting.StaticLimiting.StaticLimiting._name, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._name, solvers.rkdg.SeparateSweeps.SeparateSweeps._name, solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking._name, dastgen2.attributes.Attribute.Attribute._name, dastgen2.attributes.BooleanArray.BooleanArray._name, dastgen2.attributes.Enumeration.Enumeration._name, exahype2.api.dslhype.SyntaxTree.MemoryAllocation._name, exahype2.api.dslhype.SyntaxTree.MemoryDeallocation._name, exahype2.api.dslhype.SyntaxTree.Construction._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromExisting._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromOperation._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromMatrixVectorProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromDotProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromFunction._name, exahype2.api.Solver.Solver._name, solvers.api.Solver.Solver._name, mghype::matrixfree::solvers::Solver._name, api.solvers.Solver.Solver._name, peano4.api.dastgen2.Peano4DoubleArray.Peano4DoubleArray._name, peano4.api.dastgen2.Peano4IntegerArray.Peano4IntegerArray._name, peano4.api.dastgen2.Peano4SmartPointerDoubleArray.Peano4SmartPointerDoubleArray._name, peano4::RunMultipleSteps._name, tarch::services::ServiceRepository::ServiceEntry._name, and api.Tree.Tree._name.

Referenced by solvers.aderdg.ADERDG.ADERDG._init_dictionary_with_default_parameters(), solvers.fv.FV.FV._init_dictionary_with_default_parameters(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG._init_dictionary_with_default_parameters(), solvers.fv.FV.FV.add_actions_to_checkpoint_solution(), solvers.aderdg.ADERDG.ADERDG.add_actions_to_plot_solution(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_plot_solution(), solvers.fv.FV.FV.add_actions_to_plot_solution(), and solvers.elliptic.AMRMarker.AMRMarker.couple_with_FV_solver().

Here is the caller graph for this function:

◆ add_abstract_solver_attribute()

exahype2.api.Solver.Solver.add_abstract_solver_attribute	(		self,
		str	declaration
	)

Add a raw C++ member attribute declaration to the generated Abstract<SolverName> class (.

See also: exahype2.api.SolverToCPPFiles), e.g. "double _timeStamp = 0.0;" - use an in-class initialiser if the attribute needs one, since there is no hook into the generated constructor for this.

Nothing calls this unconditionally: a plain Solver carries no attributes beyond what PDE terms need. It is up to whichever NumericalScheme/GridConstruction/Plotter a solver uses to call this, if it needs solver-level state of its own that genuinely has no home on exahype2::Solver already - e.g. exahype2.api.fv.RusanovWithExplicitEuler deliberately does not use this for time stamp/time step size bookkeeping, since exahype2::Solver (which every generated Abstract<SolverName> already inherits from) already carries _minTimeStamp/_maxTimeStamp/_minTimeStepSize/_maxTimeStepSize and the updateCell()/startTimeStep()/finishTimeStep() lifecycle to maintain them -

See also: exahype2.api.fv.actionsets. ComputeGlobalCFLCondition, which drives that lifecycle instead of introducing parallel state via this method.

Definition at line 775 of file Solver.py.

References ScenarioFactory.createScenario().

Referenced by exahype2.api.Solver.Solver.Plotter._add_time_interval_bookkeeping_to_solver().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ add_abstract_solver_method()

exahype2.api.Solver.Solver.add_abstract_solver_method	(		self,
		str	declaration,
		Callable[[str], str]	definition_generator
	)

Add a raw C++ method to the generated Abstract<SolverName> class: declaration goes into the class body (public section), verbatim.

definition_generator is called with the class' fully qualified name once it is known (

See also: exahype2.api.SolverToCPPFiles, exactly the way PDETerm.Generator.generate_out_of_class_definitions() already is) and has to return the out-of-class definition - a plain string with a "{qualified_class_name}" placeholder is deliberately not supported here, since a C++ method body is full of literal braces of its own; build the string with concatenation instead, e.g.:

solver.add_abstract_solver_method(
  "void increaseTimestamp(double dt);",
  lambda qualified_class_name:
    "void " + qualified_class_name + "::increaseTimestamp(double dt) {\\n"
    "  _timeStamp += dt;\\n"
    "}\\n"
)

See also: add_abstract_solver_attribute() for the attribute counterpart, and exahype2.api.PDETerm.Generator for the more structured alternative this deliberately is not (that one is for PDE terms a user implements; this one is for solver-level bookkeeping a NumericalScheme/etc. needs that has no equivalent on exahype2::Solver already -; add_abstract_solver_attribute()'s own note on why RusanovWithExplicitEuler does not actually use either method for time stamp/time step size bookkeeping).

Definition at line 802 of file Solver.py.

References ScenarioFactory.createScenario().

Referenced by exahype2.api.Solver.Solver._add_checkpoint_meta_data_to_solver(), exahype2.api.Solver.Solver.Plotter._add_time_interval_bookkeeping_to_solver(), and exahype2.api.Solver.Solver._add_wants_to_plot_to_solver().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ add_pde_term()

exahype2.api.Solver.Solver.add_pde_term	(		self,
		PDETerm	term
	)

Register a PDE term with this solver, or replace the one already registered under the same name and statelessness.

A solver aggregates an arbitrary number of terms - the well-known ones (Flux(), MaxEigenvalue(), ...) as well as new, solver-specific ones users construct themselves via PDETerm(name=..., implementation=...).

Each term generates exactly one C++ method: the static, GPU-offloadable overload if term.stateless, otherwise the virtual instance method (

See also: PDETerm.Generator.generate_declaration()), never both. To get both variants of the same conceptual operation (e.g. a stateless flux for GPU kernels and a stateful one for everything else), add the term twice - once with stateless=True, once without - which is why terms are keyed by (name, stateless) rather than by name alone.

Definition at line 744 of file Solver.py.

References ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ add_plotter()

exahype2.api.Solver.Solver.add_plotter	(		self,
		"Solver.Plotter"	plotter
	)

Add a plotter to the solver.

A solver can have an arbitrary number of plotters, which are independent of each other (exahype2.api.Solver.Solver.Plotter). If the plotter has no name yet, it gets the name of its class, followed by a number if the solver has another plotter of that name already.

Parameters

plotter exahype2.api.Solver.Plotter The plotter. Its solver has to be this solver.

Definition at line 566 of file Solver.py.

References exahype2.api.Solver.Solver._plotters.

Referenced by exahype2.api.Solver.Solver.plotter().

Here is the caller graph for this function:

◆ add_solver_constants()

exahype2.api.Solver.Solver.add_solver_constants	(		self,
		str	datastring
	)

Definition at line 678 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._solver_constants, solvers.fv.FV.FV._solver_constants, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._solver_constants, and exahype2.api.Solver.Solver._solver_constants.

Referenced by CCZ4Solver.AbstractCCZ4Solver.add_all_solver_constants().

Here is the caller graph for this function:

◆ add_user_solver_includes()

exahype2.api.Solver.Solver.add_user_solver_includes	(		self,
		str	value
	)

Add further includes to this property, if your solver requires some additional routines from other header files.

Definition at line 652 of file Solver.py.

References solvers.fv.FV.FV._user_solver_includes, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._user_solver_includes, and exahype2.api.Solver.Solver._user_solver_includes.

Referenced by CCZ4Solver.AbstractCCZ4Solver._add_standard_includes(), and solvers.rkdg.RungeKuttaDG.RungeKuttaDG.set_implementation().

Here is the caller graph for this function:

◆ auxiliary_variables()

int exahype2.api.Solver.Solver.auxiliary_variables ( self )

Definition at line 641 of file Solver.py.

◆ create_readme_descriptor()

str exahype2.api.Solver.Solver.create_readme_descriptor	(	self,
		domain_offset,
		domain_size
	)

Return a human-readable description of this solver instance, to be embedded into the generated project's README.

Definition at line 951 of file Solver.py.

◆ generate_solver_realisation()

exahype2.api.Solver.Solver.generate_solver_realisation	(	self,
		exahype2_project,
		peano_project,
		setup_simulation,
		time_step,
		plot,
		mesh_adaptation
	)

Turn this solver specification into a task graph and create the required C++ kernels/stubs.

peano_project: peano4.api.Project The Peano 4 project that exahype2_project.generate_Peano4_project() is currently assembling. It is a local variable there, not an attribute - merely passed through here, so this solver can add its own artefacts to it.

setup_simulation, time_step, plot, mesh_adaptation: peano4.api.taskgraph.Graph The task graphs of the four algorithmic phases of the surrounding exahype2_project. They are owned by exahype2_project.generate_Peano4_project() and merely passed through here, so this solver can add its own tasks into them.

Returns: peano4.api.taskgraph.Graph

Reimplemented in exagrype.api.CCZ4Solver.CCZ4Solver.

Definition at line 958 of file Solver.py.

◆ get_name_of_global_instance()

str exahype2.api.Solver.Solver.get_name_of_global_instance ( self )

Definition at line 710 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._name, solvers.elliptic.AMRMarker.AMRMarker._name, solvers.elliptic.ConstrainedPoissonEquationForMarkerOnCells.ConstrainedPoissonEquationForMarkerOnCells._name, solvers.fv.EnclaveTasking.EnclaveTasking._name, solvers.fv.FV.FV._name, solvers.limiting.PosterioriLimiting.PosterioriLimiting._name, solvers.limiting.StaticLimiting.StaticLimiting._name, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._name, solvers.rkdg.SeparateSweeps.SeparateSweeps._name, solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking._name, dastgen2.attributes.Attribute.Attribute._name, dastgen2.attributes.BooleanArray.BooleanArray._name, dastgen2.attributes.Enumeration.Enumeration._name, exahype2.api.dslhype.SyntaxTree.MemoryAllocation._name, exahype2.api.dslhype.SyntaxTree.MemoryDeallocation._name, exahype2.api.dslhype.SyntaxTree.Construction._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromExisting._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromOperation._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromMatrixVectorProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromDotProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromFunction._name, exahype2.api.Solver.Solver._name, solvers.api.Solver.Solver._name, mghype::matrixfree::solvers::Solver._name, api.solvers.Solver.Solver._name, peano4.api.dastgen2.Peano4DoubleArray.Peano4DoubleArray._name, peano4.api.dastgen2.Peano4IntegerArray.Peano4IntegerArray._name, peano4.api.dastgen2.Peano4SmartPointerDoubleArray.Peano4SmartPointerDoubleArray._name, peano4::RunMultipleSteps._name, tarch::services::ServiceRepository::ServiceEntry._name, and api.Tree.Tree._name.

Here is the caller graph for this function:

◆ get_name_of_solver_class()

str exahype2.api.Solver.Solver.get_name_of_solver_class ( self )

Name of the C++ class the solver repository instantiates: <SolverName> if requires_user_class, Abstract<SolverName> otherwise.

Definition at line 737 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._name, solvers.elliptic.AMRMarker.AMRMarker._name, solvers.elliptic.ConstrainedPoissonEquationForMarkerOnCells.ConstrainedPoissonEquationForMarkerOnCells._name, solvers.fv.EnclaveTasking.EnclaveTasking._name, solvers.fv.FV.FV._name, solvers.limiting.PosterioriLimiting.PosterioriLimiting._name, solvers.limiting.StaticLimiting.StaticLimiting._name, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._name, solvers.rkdg.SeparateSweeps.SeparateSweeps._name, solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking._name, dastgen2.attributes.Attribute.Attribute._name, dastgen2.attributes.BooleanArray.BooleanArray._name, dastgen2.attributes.Enumeration.Enumeration._name, exahype2.api.dslhype.SyntaxTree.MemoryAllocation._name, exahype2.api.dslhype.SyntaxTree.MemoryDeallocation._name, exahype2.api.dslhype.SyntaxTree.Construction._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromExisting._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromOperation._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromMatrixVectorProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromDotProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromFunction._name, exahype2.api.Solver.Solver._name, solvers.api.Solver.Solver._name, mghype::matrixfree::solvers::Solver._name, api.solvers.Solver.Solver._name, peano4.api.dastgen2.Peano4DoubleArray.Peano4DoubleArray._name, peano4.api.dastgen2.Peano4IntegerArray.Peano4IntegerArray._name, peano4.api.dastgen2.Peano4SmartPointerDoubleArray.Peano4SmartPointerDoubleArray._name, peano4::RunMultipleSteps._name, tarch::services::ServiceRepository::ServiceEntry._name, api.Tree.Tree._name, and exahype2.api.Solver.Solver.requires_user_class().

Here is the call graph for this function:

◆ get_pde_term()

PDETerm exahype2.api.Solver.Solver.get_pde_term	(		self,
		str	name,
		bool	stateless = `False`
	)

Look up a previously registered PDE term by name and statelessness.

Definition at line 771 of file Solver.py.

References ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ name()

str exahype2.api.Solver.Solver.name ( self )

Unique solver name.

Feeds into all generated class and instance names.

Definition at line 540 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._name, solvers.elliptic.AMRMarker.AMRMarker._name, solvers.elliptic.ConstrainedPoissonEquationForMarkerOnCells.ConstrainedPoissonEquationForMarkerOnCells._name, solvers.fv.EnclaveTasking.EnclaveTasking._name, solvers.fv.FV.FV._name, solvers.limiting.PosterioriLimiting.PosterioriLimiting._name, solvers.limiting.StaticLimiting.StaticLimiting._name, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._name, solvers.rkdg.SeparateSweeps.SeparateSweeps._name, solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking._name, dastgen2.attributes.Attribute.Attribute._name, dastgen2.attributes.BooleanArray.BooleanArray._name, dastgen2.attributes.Enumeration.Enumeration._name, exahype2.api.dslhype.SyntaxTree.MemoryAllocation._name, exahype2.api.dslhype.SyntaxTree.MemoryDeallocation._name, exahype2.api.dslhype.SyntaxTree.Construction._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromExisting._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromOperation._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromMatrixVectorProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromDotProduct._name, exahype2.api.dslhype.SyntaxTree.DataBlockConstructionFromFunction._name, exahype2.api.Solver.Solver._name, solvers.api.Solver.Solver._name, mghype::matrixfree::solvers::Solver._name, api.solvers.Solver.Solver._name, peano4.api.dastgen2.Peano4DoubleArray.Peano4DoubleArray._name, peano4.api.dastgen2.Peano4IntegerArray.Peano4IntegerArray._name, peano4.api.dastgen2.Peano4SmartPointerDoubleArray.Peano4SmartPointerDoubleArray._name, peano4::RunMultipleSteps._name, tarch::services::ServiceRepository::ServiceEntry._name, and api.Tree.Tree._name.

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().

Here is the caller graph for this function:

◆ numerical_scheme() [1/2]

"Solver.NumericalScheme" exahype2.api.Solver.Solver.numerical_scheme ( self )

Definition at line 547 of file Solver.py.

References exahype2.api.Solver.Solver._numerical_scheme.

Referenced by exagrype.api.CCZ4Solver.CCZ4Solver.generate_solver_realisation().

Here is the caller graph for this function:

◆ numerical_scheme() [2/2]

exahype2.api.Solver.Solver.numerical_scheme	(		self,
		"Solver.NumericalScheme"	value
	)

Definition at line 551 of file Solver.py.

Referenced by exagrype.api.CCZ4Solver.CCZ4Solver.generate_solver_realisation().

Here is the caller graph for this function:

◆ pde_terms()

List[PDETerm] exahype2.api.Solver.Solver.pde_terms ( self )

All PDE terms (flux, eigenvalues, ...) registered with this solver, in registration order.

A given name can appear at most twice - once stateless, once not,

See also: add_pde_term() - since each generates a different C++ method. Read-only - use add_pde_term() to add one and remove_pde_term() to take one away again.

Definition at line 714 of file Solver.py.

References ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ plotter() [1/2]

"Solver.Plotter" exahype2.api.Solver.Solver.plotter ( self )

Shorthand for solvers with at most one plotter.

Reading it yields the solver's only plotter, or None if it has none. Assigning a plotter replaces all plotters of the solver by this one, assigning None removes all plotters. Use add_plotter() to give a solver more than one plotter.

Definition at line 613 of file Solver.py.

References exahype2.api.Solver.Solver._plotters.

◆ plotter() [2/2]

exahype2.api.Solver.Solver.plotter	(		self,
		"Solver.Plotter"	value
	)

Definition at line 631 of file Solver.py.

References exahype2.api.Solver.Solver._plotters, and exahype2.api.Solver.Solver.add_plotter().

Here is the call graph for this function:

◆ plotters()

List["Solver.Plotter"] exahype2.api.Solver.Solver.plotters ( self )

All plotters of the solver, in the order they have been added.

Definition at line 560 of file Solver.py.

◆ remove_pde_term()

exahype2.api.Solver.Solver.remove_pde_term	(		self,
		str	name,
		bool	stateless = `False`
	)

Remove a previously registered PDE term by name and statelessness.

Definition at line 767 of file Solver.py.

References ScenarioFactory.createScenario().

Here is the call graph for this function:

◆ requires_user_class()

bool exahype2.api.Solver.Solver.requires_user_class ( self )

True iff at least one PDE term has no implementation.

Only then does the user have to provide one, i.e. only then is a <SolverName> class derived from Abstract<SolverName> generated and added to the Makefile (

See also: exahype2.api.SolverToCPPFiles). Otherwise, Abstract<SolverName> is complete and the solver repository instantiates it directly. Stateless terms always carry an implementation (; PDETerm), so they never require one.

Definition at line 725 of file Solver.py.

Referenced by exahype2.api.Solver.Solver.get_name_of_solver_class().

Here is the caller graph for this function:

◆ set_solver_constants()

exahype2.api.Solver.Solver.set_solver_constants	(		self,
		str	datastring
	)

Definition at line 675 of file Solver.py.

References solvers.aderdg.ADERDG.ADERDG._solver_constants, solvers.fv.FV.FV._solver_constants, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._solver_constants, and exahype2.api.Solver.Solver._solver_constants.

◆ unknowns()

int exahype2.api.Solver.Solver.unknowns ( self )

Definition at line 637 of file Solver.py.

Referenced by tarch.plotter.api.input.PatchFileParser.UnknownAttributes.set_unknowns(), and tarch.plotter.api.input.PatchFileParser.UnknownAttributes.unknown_names().

Here is the caller graph for this function:

◆ user_solver_includes()

str exahype2.api.Solver.Solver.user_solver_includes ( self )

Add further includes to this property, if your solver requires some additional routines from other header files.

Definition at line 645 of file Solver.py.

References solvers.fv.FV.FV._user_solver_includes, solvers.rkdg.RungeKuttaDG.RungeKuttaDG._user_solver_includes, and exahype2.api.Solver.Solver._user_solver_includes.

Referenced by solvers.fv.FV.FV._init_dictionary_with_default_parameters(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG._init_dictionary_with_default_parameters(), solvers.fv.EnclaveTasking.EnclaveTasking.add_implementation_files_to_project(), solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.add_implementation_files_to_project(), solvers.aderdg.ADERDG.ADERDG.add_user_solver_includes(), solvers.aderdg.ADERDG.ADERDG.get_user_solver_includes(), and solvers.aderdg.ADERDG.ADERDG.set_implementation().

Here is the caller graph for this function:

◆ variable_names_per_entry()

List[str] exahype2.api.Solver.Solver.variable_names_per_entry ( self )

One name per entry of Q, i.e.

for the unknowns followed by the auxiliary variables, or the empty list if the variables carry no names. A variable with multiplicity one keeps its name, whereas a variable v with multiplicity k yields the names v[0], ..., v[k-1], i.e. the entries Q[Variables::v+0], ..., Q[Variables::v+k-1]. Plotters use these names to label the entries in their output.

Definition at line 684 of file Solver.py.

Here is the call graph for this function:

Field Documentation

◆ _auxiliary_variables

exahype2.api.Solver.Solver._auxiliary_variables

protected

Definition at line 424 of file Solver.py.

Referenced by solvers.rkdg.RungeKuttaDG.RungeKuttaDG.__str__(), exahype2.api.Solver.Solver.__str__(), solvers.aderdg.ADERDG.ADERDG._init_dictionary_with_default_parameters(), solvers.fv.FV.FV._init_dictionary_with_default_parameters(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG._init_dictionary_with_default_parameters(), SSInfall.SSInfallSolver.add_mass_cal_rhointer(), ccz4.CCZ4Solver.add_Psi4W(), solvers.aderdg.ADERDG.ADERDG.auxiliary_variables(), solvers.fv.FV.FV.auxiliary_variables(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG.auxiliary_variables(), exahype2.api.Solver.Solver.auxiliary_variables(), solvers.fv.FV.FV.auxiliary_variables(), solvers.rkdg.RungeKuttaDG.RungeKuttaDG.auxiliary_variables(), and exahype2.api.Solver.Solver.variable_names_per_entry().

◆ _name

exahype2.api.Solver.Solver._name