Peano

Searching...

No Matches

An abstract class for any RKDG solver of any order. More...

Inheritance diagram for exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG:

[legend]

Collaboration diagram for exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG:

[legend]

Public Member Functions
	__init__ (self, name, rk_order, polynomial_basis, FaceProjections face_projections, unknowns, auxiliary_variables, min_cell_h, max_cell_h, plot_grid_properties, bool pde_terms_without_state, baseline_action_set_descend_invocation_order=0)
	Constructor of the Runge-Kutta Discontinuous Galerkin solver.

	__str__ (self)

	get_min_number_of_spacetree_levels (self, domain_size)

	get_max_number_of_spacetree_levels (self, domain_size)

	get_coarsest_number_of_cells (self, domain_size)

	get_finest_number_of_cells (self, domain_size)

	create_readme_descriptor (self, domain_offset, domain_size)

	user_action_set_includes (self)
	Add further includes to this property, if your action sets require some additional routines from other header files.

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

	add_user_action_set_includes (self, value)
	Add further includes to this property, if your action sets require some additional routines from other header files.

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

	create_data_structures (self)
	Recall in subclasses if you wanna change the number of unknowns or auxiliary variables.

	create_action_sets (self)
	Overwrite in subclasses if you wanna create different action sets.

	get_name_of_global_instance (self)

	add_to_Peano4_datamodel (self, datamodel, verbose)
	Add all required data to the Peano4 project's datamodel so it is properly built up.

	add_use_data_statements_to_Peano4_solver_step (self, step)
	Tell Peano what data to move around.

	add_actions_to_init_grid (self, step)
	Add the action sets to the grid initialisation.

	add_actions_to_create_grid (self, step, evaluate_refinement_criterion)

	set_plot_description (self, description)
	Use this one to set a description within the output patch file that tells the vis solver what the semantics of the entries are.

	add_actions_to_plot_solution (self, step, output_path)
	Dump snapshot of solution.

	add_actions_to_perform_time_step (self, step)
	The tricky part here is that we have to get the order right.

	add_entries_to_text_replacement_dictionary (self, d)

	add_implementation_files_to_project (self, namespace, output, dimensions, subdirectory="")
	The ExaHyPE project will call this operation when it sets up the overall environment.

	set_solver_constants (self, datastring)

	add_solver_constants (self, datastring)

	unknowns (self)

	auxiliary_variables (self)

	unknowns (self, value)

	auxiliary_variables (self, value)

	number_of_Runge_Kutta_steps (self)

	set_implementation (self, flux=None, ncp=None, eigenvalues=None, boundary_conditions=None, refinement_criterion=None, initial_conditions=None, source_term=None, point_source=None, additional_action_set_includes="", additional_user_includes="")
	If you pass in User_Defined, then the generator will create C++ stubs that you have to befill manually.

	postprocess_updated_cell_after_Runge_Kutta_step (self)

	postprocess_updated_cell_after_final_linear_combination (self)

	postprocess_updated_cell_after_Runge_Kutta_step (self, kernel)
	Define a postprocessing routine over the data.

	postprocess_updated_cell_after_final_linear_combination (self, kernel)
	Define a postprocessing routine over the data.

	switch_storage_scheme (self, Storage cell_data_storage, Storage face_data_storage)
	By default, we hold all data on the call stacks.

Data Fields
	plot_description

	select_dofs_to_print

Protected Member Functions
	_query_fine_grid_cell_in_action_set_if_it_holds_solution (self)

	_provide_cell_data_to_compute_kernels_default_guard (self)

	_provide_face_data_to_compute_kernels_default_guard (self)

	_store_cell_data_default_guard (self)
	Extend the guard via ands only.

	_load_cell_data_default_guard (self)
	Extend the guard via ands only.

	_store_face_data_default_guard (self)
	Extend the guard via ands only.

	_load_face_data_default_guard (self)
	Extend the guard via ands only.

	_unknown_identifier (self)

	_get_default_includes (self)

	_init_dictionary_with_default_parameters (self, d)
	This one is called by all algorithmic steps before I invoke add_entries_to_text_replacement_dictionary().

Protected Attributes
	_name

	_rk_order

	_basis

	_face_projections

	_volumetric_compute_kernel_call

	_volumetric_compute_kernel_call_stateless

	_Riemann_compute_kernel_call

	_Riemann_compute_kernel_call_stateless

	_pde_terms_without_state

	_add_solver_contributions_call

	_multiply_with_inverted_mass_matrix_call

	_kernel_namespace

	_use_var_shortcut

	_variable_names

	_variable_pos

	_unknowns

	_auxiliary_variables

	_min_cell_h

	_max_cell_h

	_plot_grid_properties

	_solver_constants

	_user_action_set_includes

	_user_solver_includes

	_solver_template_file_class_name

	_action_set_postprocess_solution

	_action_set_preprocess_solution

	_compute_eigenvalue

	_compute_time_step_size

	_compute_new_time_step_size

	_preprocess_cell

	_postprocess_updated_cell_after_Runge_Kutta_step

	_postprocess_updated_cell_after_final_linear_combination

	_flux_implementation

	_ncp_implementation

	_eigenvalues_implementation

	_source_term_implementation

	_point_sources_implementation

	_boundary_conditions_implementation

	_refinement_criterion_implementation

	_initial_conditions_implementation

	_abstract_solver_user_declarations

	_abstract_solver_user_definitions

	_solver_user_declarations

	_solver_user_definitions

	_start_time_step_implementation

	_finish_time_step_implementation

	_constructor_implementation

	_cell_data_storage

	_face_data_storage

	_baseline_action_set_descend_invocation_order

	_current_time_step

	_rhs_estimates

	_linear_combination_of_estimates

	_estimate_projection

	_old_solution_projection

	_Riemann_solution

	_cell_label

	_face_label

	_action_set_initial_conditions

	_action_set_initial_conditions_for_grid_construction

	_action_set_AMR

	_action_set_AMR_commit_without_further_analysis

	_action_set_AMR_throughout_grid_construction

	_action_set_linear_combination_of_estimates

	_action_set_project_linear_combination_onto_faces

	_action_set_solve_volume_integral

	_action_set_handle_boundary

	_action_set_solve_Riemann_problem

	_action_set_add_volume_and_face_solution

	_action_set_compute_final_linear_combination_and_project_solution_onto_faces

	_action_set_couple_resolution_transitions_and_handle_dynamic_mesh_refinement

	_action_set_update_face_label

	_action_set_update_cell_label

Static Private Attributes
	__repr__ = __str__

Detailed Description

An abstract class for any RKDG solver of any order.

This is the base class of all Runge-Kutta DG solvers. It defines what kind of action sets do exist, i.e., what in principle can be done while we run through the grid. It also provides some kind of very basic infrastructure, i.e. what the name of a solver is, what data is to be held per face or cell, or where in the multiscale mesh we actually have to hold data.

The RungeKuttaDG class cannot/should not be instantiated. Its children actually decide which steps are required or invoked in which order.

They do so by setting the guards: Each data structure has a guard which controls if it is to be stored. Each action set has a guard that says if it should be called in this particular mesh traversal. If you want to redefine/reset these guards, you have to redefine create_data_structures() and reset the guards after you have called the superclass' operation. I recommend that you refrain from defining completely new guards. Use the predefined guards instead and refine them by adding more and and or clauses.

If you want to study the mathematics routines used by all the Python-generated code, read the Discontinous Galerkin page in dg.h.

Data structures

Each cell hosts a DG polynomial of order _dg_order. Technically, we store this polynomial in a regular array (blockstructured data) with (_dg_order+1)^d entries. On top of this current time step, we need the shots into the future. for RK(_rk_order), we need _rk_order of these snapshots. They are called estimates.

On the boundary, I store both the left and right solution projections. Per RK step, we project the linear combination onto the face. This is in line with the action set ComputeFinalLinearCombination which simply copies over the old time step into the linear combination field in the very first Runge-Kutta step.

Our DG implementation is not tied to one particular Riemann solver, even though most users will likely use Rusanov. Therefore, it is not clear which data is to be projected onto the faces. For plain Rusanov with only a flux function, the solutions are sufficient. Other Riemann solvers or Rusanov's ncp terms however require the derivatives. So I give the code the opportunity to work with different data cardinalities.

More details are provided in create_data_structures().

Control flow between this class and subclasses

There are three key routines: the constructor, create_data_structures() and create_action_sets(). The constructor sets/memorises some solver variables (such as the name) and then invokes the other two routines.

create_data_structures() establishes all the data structures tied to the grid entities. If you want to alter the configuration of data tied to grid entities, you should redefine create_data_structures(). However, any subclass still should call Runge Kutta's create_data_structures() before that. This will ensure that the baseline configuration of all data is in place. After that, you can modify the properties.

create_action_sets() establishes the action sets, i.e., activities that are to be triggered whenever you run a time step, you plot, you initialise the grid. Same here: If you want to alter the configuration of the code, call create_action_sets() of the superclass first, before you do fancy stuff. This way, all the important action sets are in place.

General control flow and realisation of solver steps

A proper numerical time step is mapped onto a cascade of time step sweeps. Per sweep, we realise the following steps (so step in a computational sense), though their exact orchestration depends on the realisation chosen, i.e. some might merge some subcalculations into one grid sweep while others distribute a calculation over multiple sweeps.

We combine the data of the current time step with all the shots into the future. These shots are held in one large array. This is not super efficient, as we could build up these arrays one by one, but I just use one large scratchpad even for the first line in the Butcher tableau. See create_data_structures() for details. So all the estimates and the current solution are combined according to the Butcher tableau.

It is up to the particular subclass to configure the guard of the linear combination such that it is only computed when it is actually needed.
Next, we project this linear combination onto the faces. At the same time, we compute a new estimate for the volume integral. The time step size for this new estimate again depends on the time step size from the Butcher tableau. The two action sets both are volumetric, i.e. run per cell, but we can run them in parallel. The face projection has to complete immediately (we need the data on the faces), while the volumetric computation, in principle, doesn't have to finish prior to the next grid sweep, as long as the linear combination remains persistent. It is only a temporary thing, so will be destroyed immediately once we leave a cell.

Mandatory step of subclasses

There are different nuances of subclasses/algorithmic realisations, i.e., few solvers inherit directly from RungeKuttaDG. However, even those subclasses still require you do provide some additional information.

These are the fields you have to set:

_compute_time_step_size A simple string which defines a double timeStepSize. This snippet will be used by both the Riemann solver and the volumetric integration. You don't have to care about the Runge-Kutta scaling of time step sizes (or shifts), as this is all done by the source code, but you have to feed an instruction into the solver how to determine a time step size for a cell.

self._compute_new_time_step_size = "const double newTimeStepSize = timeStepSize;"

Semantics of FaceLabel

The update time stamp is the one we update in each and every Runge-Kutta step.
The new time stamp is the valid one, i.e., the one that corresponds to the face's EstimateProjection after a time step.
The old time stamp is the one that corresponds to the (old) face projection.
We set the updated flag if and only if we have finished the last Runge-Kutta step.

Definition at line 38 of file RungeKuttaDG.py.

Constructor & Destructor Documentation

◆ init()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.__init__	(		self,
			name,
			rk_order,
			polynomial_basis,
		FaceProjections	face_projections,
			unknowns,
			auxiliary_variables,
			min_cell_h,
			max_cell_h,
			plot_grid_properties,
		bool	pde_terms_without_state,
			baseline_action_set_descend_invocation_order = 0 )

Constructor of the Runge-Kutta Discontinuous Galerkin solver.

:: Arguments

name: string A unique name for the solver. This one will be used for all generated classes. Also the C++ object instance later on will incorporate this name.

dg_order: int Order of the Discontinuous Galerkin approximation.

rk_order: int Runge-Kutta order, i.e., time stepping order.

polynomials: Polynomials Picks which kind of polynomial to use.

face_projections: Integer How many projections do we need per face. If you are only interested in the left and right solution along a face, pass in 1. If you want to have the fluxes or derivatives as well, pass in 2. The latter version is the type of data structure you need for Rusanov, e.g.

There are a couple of pre-defined values for this guy.

unknowns: int Number of unknowns per Finite Volume voxel.

auxiliary_variables: int Number of auxiliary variables per Finite Volume voxel. Eventually, both unknowns and auxiliary_variables are merged into one big vector if we work with AoS. But the solver has to be able to distinguish them, as only the unknowns are subject to a hyperbolic formulation.

min_cell_h: double This size refers to the individual discretisation cell.

max_cell_h: double This size refers to the individual discretisation cell.

plot_grid_properties: Boolean Clarifies whether a dump of the data should be enriched with grid info (such as enclave status flags), too.

:: Attributes

All the constructor parameters are stored in object attributes. There's a few more which are of interest for subclasses:

_solver_template_file_class_name: String This can be used by subclasses to pick which template is to be used to create the abstract solver and the actual solver blueprint.

_number_of_derivatives_projected_onto_face: Int

_solver_states: [String] Returns a list of strings of the individual solver states. The code will automatically supplement this list with the following states:

GridConstruction, GridInitialisation, Plotting, PlottingAfterGridInitialisation

So you may implicitly assume that these guys do exist always.

Reimplemented in create-dg-benchmark-executable-with-limiter.MyDGSolver, exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps, exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking, CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStepWithEnclaveTasking, CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStep, exahype2.solvers.rkdg.rusanov.GlobalAdaptiveTimeStep.GlobalAdaptiveTimeStep, exahype2.solvers.rkdg.rusanov.GlobalAdaptiveTimeStepWithEnclaveTasking.GlobalAdaptiveTimeStepWithEnclaveTasking, and exahype2.solvers.rkdg.rusanov.GlobalFixedTimeStep.GlobalFixedTimeStep.

Definition at line 163 of file RungeKuttaDG.py.

Member Function Documentation

◆ str()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.__str__ ( self )

Definition at line 378 of file RungeKuttaDG.py.

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

Here is the caller graph for this function:

◆ _get_default_includes()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._get_default_includes ( self )

protected

Definition at line 1151 of file RungeKuttaDG.py.

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

Here is the caller graph for this function:

◆ _init_dictionary_with_default_parameters()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._init_dictionary_with_default_parameters	(		self,
			d )

protected

This one is called by all algorithmic steps before I invoke add_entries_to_text_replacement_dictionary().

See the remarks on set_postprocess_updated_cell_kernel to understand why we have to apply the (partially befilled) dictionary to create a new entry for this very dictionary.

Definition at line 1426 of file RungeKuttaDG.py.

Here is the call graph for this function:

Here is the caller graph for this function:

◆ _load_cell_data_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._load_cell_data_default_guard ( self )

protected

Extend the guard via ands only.

Never use an or, as subclasses might extend it as well, and they will append further ends.

Definition at line 1048 of file RungeKuttaDG.py.

Referenced by exahype2.solvers.aderdg.ADERDG.ADERDG.add_actions_to_plot_solution(), exahype2.solvers.fv.FV.FV.add_actions_to_plot_solution(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_plot_solution(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.add_actions_to_plot_solution(), and exahype2.solvers.rkfd.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.create_data_structures().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ _load_face_data_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._load_face_data_default_guard ( self )

protected

Extend the guard via ands only.

Never use an or, as subclasses might extend it as well, and they will append further ends.

Definition at line 1083 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ _provide_cell_data_to_compute_kernels_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._provide_cell_data_to_compute_kernels_default_guard ( self )

protected

Definition at line 1011 of file RungeKuttaDG.py.

Referenced by create-dg-benchmark-executable-with-limiter.MyDGSolver.__init__(), exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps.create_data_structures(), and exahype2.solvers.rkfd.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.create_data_structures().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ _provide_face_data_to_compute_kernels_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._provide_face_data_to_compute_kernels_default_guard ( self )

protected

Definition at line 1022 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ _query_fine_grid_cell_in_action_set_if_it_holds_solution()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._query_fine_grid_cell_in_action_set_if_it_holds_solution ( self )

protected

Definition at line 849 of file RungeKuttaDG.py.

References SBH.Limiter._store_cell_data_default_guard(), exahype2.solvers.aderdg.ADERDG.ADERDG._store_cell_data_default_guard(), exahype2.solvers.fv.FV.FV._store_cell_data_default_guard(), exahype2.solvers.limiting.PosterioriLimiting.PosterioriLimiting._store_cell_data_default_guard(), exahype2.solvers.limiting.StaticLimiting.StaticLimiting._store_cell_data_default_guard(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._store_cell_data_default_guard(), and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences._store_cell_data_default_guard().

Here is the call graph for this function:

◆ _store_cell_data_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._store_cell_data_default_guard ( self )

protected

Extend the guard via ands only.

Never use an or, as subclasses might extend it as well, and they will append further ends.

Definition at line 1033 of file RungeKuttaDG.py.

Referenced by exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._query_fine_grid_cell_in_action_set_if_it_holds_solution(), exahype2.solvers.aderdg.SingleSweep.SingleSweep.create_action_sets(), exahype2.solvers.fv.FV.FV.create_action_sets(), exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps.create_action_sets(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.create_action_sets(), and exahype2.solvers.rkfd.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.create_data_structures().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ _store_face_data_default_guard()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._store_face_data_default_guard ( self )

protected

Extend the guard via ands only.

Never use an or, as subclasses might extend it as well, and they will append further ends.

Definition at line 1068 of file RungeKuttaDG.py.

Referenced by exahype2.solvers.aderdg.ADERDG.ADERDG._store_boundary_data_default_guard(), and exahype2.solvers.fv.FV.FV.create_action_sets().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ _unknown_identifier()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._unknown_identifier ( self )

protected

Definition at line 1103 of file RungeKuttaDG.py.

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

Here is the caller graph for this function:

◆ add_actions_to_create_grid()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_create_grid	(	self,
		step,
		evaluate_refinement_criterion )

Todo: : The boundary information is set only once. It is therefore important that we ues the face label and initialise it properly.

Definition at line 1189 of file RungeKuttaDG.py.

◆ add_actions_to_init_grid()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_init_grid	(		self,
			step )

Add the action sets to the grid initialisation.

The AMR stuff has to be the very first thing. Actually, the AMR routines' interpolation doesn't play any role here. But the restriction indeed is very important, as we have to get the face data for BCs et al. The action set order is inverted while we ascend within the tree again. Therefore, we add the AMR action set first which means it will be called last when we go from fine to coarse levels within the tree.

Ordering

The order of the action sets is preserved throughout the steps down within the tree hierarchy. It is inverted throughout the backrolling.

This is what we want to achieve:

Restrict the data to the coarser level if we are on a hanging face.

Definition at line 1161 of file RungeKuttaDG.py.

◆ add_actions_to_perform_time_step()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_perform_time_step	(		self,
			step )

The tricky part here is that we have to get the order right.

Update of the labels: This can be done as very first step, as it might feed into follow-up steps.
Linear combination: This has to be the first step of a Runge-Kutta scheme. Without this first step, there's absolutely nothing we can do properly.
Couple resolutions and AMR: Once we have the linear combination, we can couple different resolutions.
Project linear combination onto faces: This should be done as soon as possible but after we've determined the linear combination. After all, we need the solution representation on the faces asap.
Solve volume integral: can run in parallel to the projection onto the faces.
Handle boundary: doesn't really matter when we insert it, as it plugs into the first face load, while all the other stuff so far are volumetric operations. It is important that we do the inter-grid transfer operators before we apply the boundary conditions.
Solve Riemann problem: the constraint here is that it has to come after the boundary handling.
Add volume and face solution: last

If we use enclave tasking, we have to be careful when we insert the merger. See SeparateSweepsWithEnclaveTasking.add_actions_to_perform_time_step() for a discussion of the details.

Reimplemented in exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.

Definition at line 1287 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ add_actions_to_plot_solution()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_plot_solution	(	self,
		step,
		output_path )

Dump snapshot of solution.

Consult the discussion in add_actions_to_init_grid() around the order of the individual action sets.

It is important that we have the coupling/dynamic AMR part in here, as there might be pending AMR refinement requests that now are realised. For the same reason, we need the update of the face label and the update of the cell label in here: The AMR might just propagate over into the plotting, i.e. we might create new grid entities throughout the plot. These entities (faces and cells) have to be initialised properly. Otherwise, their un-initialised data will propagate through to the next time step.

To make the restriction work, we have to project the solutions onto the faces.

Definition at line 1213 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ add_entries_to_text_replacement_dictionary()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_entries_to_text_replacement_dictionary	(		self,
			d )

Reimplemented in exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.

Definition at line 1340 of file RungeKuttaDG.py.

Referenced by exahype2.solvers.aderdg.ADERDG.ADERDG._generate_kernels(), exahype2.solvers.fv.FV.FV.add_actions_to_perform_time_step(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_perform_time_step(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.add_actions_to_perform_time_step(), exahype2.solvers.aderdg.ADERDG.ADERDG.add_actions_to_plot_solution(), exahype2.solvers.fv.FV.FV.add_actions_to_plot_solution(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_actions_to_plot_solution(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.add_actions_to_plot_solution(), exahype2.solvers.aderdg.ADERDG.ADERDG.add_implementation_files_to_project(), exahype2.solvers.fv.EnclaveTasking.EnclaveTasking.add_implementation_files_to_project(), exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.add_implementation_files_to_project(), and exahype2.solvers.rkfd.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.add_implementation_files_to_project().

Here is the caller graph for this function:

◆ add_implementation_files_to_project()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_implementation_files_to_project	(	self,
		namespace,
		output,
		dimensions,
		subdirectory = "" )

The ExaHyPE project will call this operation when it sets up the overall environment.

This routine is typically not invoked by a user.

output: peano4.output.Output

Reimplemented in exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.

Definition at line 1344 of file RungeKuttaDG.py.

◆ add_solver_constants()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_solver_constants	(		self,
			datastring )

Definition at line 1422 of file RungeKuttaDG.py.

References exahype2.solvers.aderdg.ADERDG.ADERDG._solver_constants, exahype2.solvers.fv.FV.FV._solver_constants, exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._solver_constants, and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences._solver_constants.

Referenced by CCZ4Solver.AbstractCCZ4Solver.add_all_solver_constants().

Here is the caller graph for this function:

◆ add_to_Peano4_datamodel()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_to_Peano4_datamodel	(	self,
		datamodel,
		verbose )

Add all required data to the Peano4 project's datamodel so it is properly built up.

Definition at line 1111 of file RungeKuttaDG.py.

◆ add_use_data_statements_to_Peano4_solver_step()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_use_data_statements_to_Peano4_solver_step	(		self,
			step )

Tell Peano what data to move around.

Inform Peano4 step which data are to be moved around via the use_cell and use_face commands. This operation is generic from ExaHyPE's point of view, i.e. I use it for all grid sweep types.

Definition at line 1133 of file RungeKuttaDG.py.

◆ add_user_action_set_includes()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_user_action_set_includes	(		self,
			value )

Add further includes to this property, if your action sets require some additional routines from other header files.

Definition at line 517 of file RungeKuttaDG.py.

References exahype2.solvers.fv.FV.FV._user_action_set_includes, exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._user_action_set_includes, and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences._user_action_set_includes.

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

Here is the caller graph for this function:

◆ add_user_solver_includes()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.add_user_solver_includes	(		self,
			value )

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

Definition at line 525 of file RungeKuttaDG.py.

References exahype2.solvers.fv.FV.FV._user_solver_includes, exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._user_solver_includes, and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences._user_solver_includes.

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

Here is the caller graph for this function:

◆ auxiliary_variables() [1/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.auxiliary_variables ( self )

Definition at line 1567 of file RungeKuttaDG.py.

Referenced by exahype2.symhype.PDE.PDE._implementation_of_mapping_onto_named_quantities(), exahype2.symhype.PDE.PDE.implementation_of_boundary_conditions(), exahype2.symhype.PDE.PDE.implementation_of_homogeneous_Neumann_BC(), exahype2.symhype.PDE.PDE.implementation_of_initial_conditions(), and exahype2.symhype.PDE.PDE.unknown_identifier_for_plotter().

Here is the caller graph for this function:

◆ auxiliary_variables() [2/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.auxiliary_variables	(		self,
			value )

Definition at line 1579 of file RungeKuttaDG.py.

Here is the call graph for this function:

Here is the caller graph for this function:

◆ create_action_sets()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_action_sets ( self )

Overwrite in subclasses if you wanna create different action sets.

:: Call order and ownership

This operation can be called multiple times over the construction of a solver. However, only the very last call matters. All previous calls are wiped out.

If you have a hierarchy of solvers, every create_data_structure() should first(!) call its parent version. This way, you always ensure that all data are in place before you continue to alter the more specialised versions. So it is (logically) a top-down (general to specialised) run through all create_data_structure() variants within the inheritance tree.

Reimplemented in exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps, and exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.

Definition at line 854 of file RungeKuttaDG.py.

Here is the caller graph for this function:

◆ create_data_structures()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_data_structures ( self )

Recall in subclasses if you wanna change the number of unknowns or auxiliary variables.

See class description's subsection on data flow.

:: Call order and ownership

This operation can be called multiple times. However, only the very last call matters. All previous calls are wiped out.

:: Solver fields built up

_time_step: Patch ( (_dg_order+1)x(_dg_order+1)x(_dg_order+1) ) Actual polynomial data of the DG patch in the current time step.

_rhs_estimates: Patch ( (_dg_order+1)x(_dg_order+1)x(_dg_order+1)xno of RK steps ) These are the Runge-Kutta extrapolations. It is important that the rk_order is mixed into the first argument, as the triple is automatically truncated to a tuple if the code is translated with 2d. Please note that the term rhs refers to the right-hand side of an ODE

\( \partial Q = F(Q) \)

and thus does not include auxiliary variables.

_linear_combination_of_estimates: Patch ( (_dg_order+1)x(_dg_order+1)x(_dg_order+1) ) Non-persistent helper data structure.

_current_time_step_projection: Patch ( 2xface_projectionsx(_dg_order+1)x(_dg_order+1) ) This is the projection of the polynomial data of the current guess onto the faces. It is important that the first dimension is only a 2. This way, we can (logically) handle the projected data again as an overlap of two patches with the width 1.

_estimate_projection: Patch ( Nxface_projectionsx(_dg_order+1)x(_dg_order+1) ) The N is usually 2. Usually this estimate projection holds the data from the latest Runge-Kutta step. This implies that it never ever holds the projection of the solution unless after the very first Runge-Kutta step. After that, it is always a linear combination of estimates.

To avoid this plain behaviour, I make the last and final linear combination project the solution again onto the faces, i.e. after the very last step of the Runge-Kutta scheme, there will be a valid representation of the solution _estimate_projection. Consult the documentation of exahype2.solvers.rkdg.actionsets.ComputeFinalLinearCombination for some further information. Also consult the semantics of the FaceLabel in this context.

_old_solution_projection: Same as _estimate_projection This is a backup of the final solution stored in _estimate_projection. It correlates to

_face_label: FaceLabel See class description. General information such as "is boundary".

_cell_label: CellLabel See class description. General information such as "is enclave".

Per default, I do always store the projections onto faces, and I always keep the actual time step data and the cell projections. It is up to the subclasses to alter this storage behaviour.

By default, I do not exchange any face data in-between two grid sweeps. You will have to overwrite the behaviour in subclasses. Please note that a face is communicated between two tree/domain partitions if and only if it is stored persistently and the exchange flag is set, too.

Reimplemented in exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps, and exahype2.solvers.rkdg.SeparateSweepsWithEnclaveTasking.SeparateSweepsWithEnclaveTasking.

Definition at line 534 of file RungeKuttaDG.py.

Here is the caller graph for this function:

◆ create_readme_descriptor()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_readme_descriptor	(	self,
		domain_offset,
		domain_size )

Definition at line 460 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ get_coarsest_number_of_cells()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_coarsest_number_of_cells	(		self,
			domain_size )

Definition at line 452 of file RungeKuttaDG.py.

References exahype2.solvers.fv.FV.FV.get_min_number_of_spacetree_levels(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_min_number_of_spacetree_levels(), and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.get_min_number_of_spacetree_levels().

Referenced by exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_readme_descriptor().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ get_finest_number_of_cells()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_finest_number_of_cells	(		self,
			domain_size )

Definition at line 456 of file RungeKuttaDG.py.

References exahype2.solvers.fv.FV.FV.get_max_number_of_spacetree_levels(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_max_number_of_spacetree_levels(), and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.get_max_number_of_spacetree_levels().

Referenced by exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_readme_descriptor().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ get_max_number_of_spacetree_levels()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_max_number_of_spacetree_levels	(		self,
			domain_size )

Definition at line 445 of file RungeKuttaDG.py.

References exahype2.solvers.aderdg.ADERDG.ADERDG._min_cell_h, and exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._min_cell_h.

Referenced by exahype2.solvers.fv.FV.FV.create_readme_descriptor(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_readme_descriptor(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.create_readme_descriptor(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_finest_number_of_cells(), exahype2.solvers.fv.FV.FV.get_finest_number_of_patches(), and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.get_finest_number_of_patches().

Here is the caller graph for this function:

◆ get_min_number_of_spacetree_levels()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_min_number_of_spacetree_levels	(		self,
			domain_size )

Definition at line 438 of file RungeKuttaDG.py.

References exahype2.solvers.aderdg.ADERDG.ADERDG._max_cell_h, and exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._max_cell_h.

Referenced by exahype2.solvers.fv.FV.FV.create_readme_descriptor(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.create_readme_descriptor(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.create_readme_descriptor(), exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_coarsest_number_of_cells(), exahype2.solvers.fv.FV.FV.get_coarsest_number_of_patches(), and exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences.get_coarsest_number_of_patches().

Here is the caller graph for this function:

◆ get_name_of_global_instance()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.get_name_of_global_instance ( self )

Definition at line 1107 of file RungeKuttaDG.py.

Here is the caller graph for this function:

◆ number_of_Runge_Kutta_steps()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.number_of_Runge_Kutta_steps ( self )

Definition at line 1585 of file RungeKuttaDG.py.

Referenced by exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._init_dictionary_with_default_parameters(), exahype2.solvers.rkfd.CellCenteredFiniteDifferences.CellCenteredFiniteDifferences._init_dictionary_with_default_parameters(), and exahype2.solvers.rkdg.SeparateSweeps.SeparateSweeps.create_action_sets().

Here is the caller graph for this function:

◆ postprocess_updated_cell_after_final_linear_combination() [1/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.postprocess_updated_cell_after_final_linear_combination ( self )

Definition at line 1645 of file RungeKuttaDG.py.

References exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._postprocess_updated_cell_after_final_linear_combination.

Referenced by CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStepWithEnclaveTasking.__init__(), and CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStep.__init__().

Here is the caller graph for this function:

◆ postprocess_updated_cell_after_final_linear_combination() [2/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.postprocess_updated_cell_after_final_linear_combination	(		self,
			kernel )

Define a postprocessing routine over the data.

This routine allows you to update the patch data immediately after the patch update. The routine provides the whole patch, and therefore you can write stuff similar to

 my_solver.postprocess_updated_cell = " ""
 {
   constexpr int itmax = ({{DG_ORDER}} +1 ) * ({{DG_ORDER}} + 1) * ({{DG_ORDER}} + 1);
   int index = 0;
   for (int i = 0; i < itmax; i++) {

applications::exahype2::ccz4::enforceCCZ4constraints(dQdt + index); index += {{NUMBER_OF_UNKNOWNS}}; } }

Difference to Finite Volume solvers

Different to the Finite Volume solvers, you don't have the auxiliary variables in this routine. You also don't have the new solution, but the time derivative instead.

Available constants

This list is not complete. You might want to consult the generated code to spot more variables that are on offer. Whenever I use the brackets below, these are symbolic constants which will be befilled with the proper constants when the postprocessing code snippet is inserted into the generated code. The other variables are directly available, i.e., no text replacement is done here.

{{DG_ORDER}} Spatial discretisation order.

Runge-Kutta steps

This postprocessing is called after each and every Runge-Kutta step.

Definition at line 1700 of file RungeKuttaDG.py.

Referenced by CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStepWithEnclaveTasking.__init__(), and CCZ4Solver.CCZ4Solver_RKDG_GlobalAdaptiveTimeStep.__init__().

Here is the call graph for this function:

Here is the caller graph for this function:

◆ postprocess_updated_cell_after_Runge_Kutta_step() [1/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.postprocess_updated_cell_after_Runge_Kutta_step ( self )

Definition at line 1640 of file RungeKuttaDG.py.

References exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG._postprocess_updated_cell_after_Runge_Kutta_step.

◆ postprocess_updated_cell_after_Runge_Kutta_step() [2/2]

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.postprocess_updated_cell_after_Runge_Kutta_step	(		self,
			kernel )

Define a postprocessing routine over the data.

This routine allows you to update the patch data immediately after the patch update. The routine provides the whole patch, and therefore you can write stuff similar to

 my_solver.postprocess_updated_cell = " ""
 {
   constexpr int itmax = ({{DG_ORDER}} + 1) * ({{DG_ORDER}} + 1) * ({{DG_ORDER}} + 1);
   int index = 0;
   for (int i = 0; i < itmax; i++) {

applications::exahype2::ccz4::enforceCCZ4constraints(dQdt + index); index += {{NUMBER_OF_UNKNOWNS}}; } }

Difference to Finite Volume solvers

Different to the Finite Volume solvers, you don't have the auxiliary variables in this routine. You also don't have the new solution, but the time derivative instead.

Available constants

{{DG_ORDER}} Spatial discretisation order.
timeStamp
timeStepSize
dQdt

Runge-Kutta steps

This postprocessing is called after each and every Runge-Kutta step.

Definition at line 1650 of file RungeKuttaDG.py.

Here is the call graph for this function:

◆ set_implementation()

exahype2.solvers.rkdg.RungeKuttaDG.RungeKuttaDG.set_implementation	(	self,
		flux = None,
		ncp = None,
		eigenvalues = None,
		boundary_conditions = None,
		refinement_criterion = None,
		initial_conditions = None,
		source_term = None,
		point_source = None,
		additional_action_set_includes = "",
		additional_user_includes = "" )

If you pass in User_Defined, then the generator will create C++ stubs that you have to befill manually.

If you pass in None_Implementation, it will create nop, i.e., no implementation or defaults. Any other string is copied 1:1 into the implementation. If you pass in None, then the set value so far won't be overwritten.

Reimplemented in exahype2.solvers.rkdg.rusanov.GlobalFixedTimeStep.GlobalFixedTimeStep, exahype2.solvers.rkdg.rusanov.GlobalAdaptiveTimeStep.GlobalAdaptiveTimeStep, and exahype2.solvers.rkdg.rusanov.GlobalAdaptiveTimeStepWithEnclaveTasking.GlobalAdaptiveTimeStepWithEnclaveTasking.

Definition at line 1589 of file RungeKuttaDG.py.

Public Member Functions

Data Fields

Protected Member Functions

Protected Attributes

Static Private Attributes

Detailed Description

Data structures

Control flow between this class and subclasses

General control flow and realisation of solver steps

Mandatory step of subclasses

Semantics of FaceLabel

Constructor & Destructor Documentation

◆ __init__()

Member Function Documentation

◆ __str__()

◆ _get_default_includes()

◆ _init_dictionary_with_default_parameters()

◆ _load_cell_data_default_guard()

◆ _load_face_data_default_guard()

◆ _provide_cell_data_to_compute_kernels_default_guard()

◆ _provide_face_data_to_compute_kernels_default_guard()

◆ _query_fine_grid_cell_in_action_set_if_it_holds_solution()

◆ _store_cell_data_default_guard()

◆ _store_face_data_default_guard()

◆ _unknown_identifier()

◆ add_actions_to_create_grid()

◆ add_actions_to_init_grid()

Ordering

◆ add_actions_to_perform_time_step()

◆ add_actions_to_plot_solution()

◆ add_entries_to_text_replacement_dictionary()

◆ add_implementation_files_to_project()

◆ add_solver_constants()

◆ add_to_Peano4_datamodel()

◆ add_use_data_statements_to_Peano4_solver_step()

◆ add_user_action_set_includes()

◆ add_user_solver_includes()

◆ auxiliary_variables() [1/2]

◆ auxiliary_variables() [2/2]

◆ create_action_sets()

◆ create_data_structures()

◆ create_readme_descriptor()

◆ get_coarsest_number_of_cells()

◆ get_finest_number_of_cells()

◆ get_max_number_of_spacetree_levels()

◆ get_min_number_of_spacetree_levels()

◆ get_name_of_global_instance()

◆ number_of_Runge_Kutta_steps()

◆ postprocess_updated_cell_after_final_linear_combination() [1/2]

◆ postprocess_updated_cell_after_final_linear_combination() [2/2]

Difference to Finite Volume solvers

Available constants

Runge-Kutta steps

◆ postprocess_updated_cell_after_Runge_Kutta_step() [1/2]

◆ postprocess_updated_cell_after_Runge_Kutta_step() [2/2]

Difference to Finite Volume solvers

Available constants

Runge-Kutta steps

◆ set_implementation()

◆ init()

◆ str()