Peano

Searching...

No Matches

Project patch data onto faces, so the faces hold valid data which can feed into the subsequent Runge-Kutta step. More...

Inheritance diagram for exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces:

[legend]

Collaboration diagram for exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces:

[legend]

Public Member Functions
	__init__ (self, solver)
	solver: ADERDG Reference to creating class

	guards (self)

	guards (self, new_guards)

	get_action_set_name (self)
	You should replicate this function in each subclass, so you get meaningful action set names (otherwise, it will be AbstractRKFDActionSet0,1,2,...).

	get_body_of_operation (self, operation_name)
	Return actual C++ code snippets to be inserted into C++ code.

	get_includes (self)
	Return include statements that you need.

Public Member Functions inherited from exahype2.solvers.rkfd.actionsets.AbstractRKFDActionSet.AbstractRKFDActionSet
	user_should_modify_template (self)
	Is the user allowed to modify the output.

Public Member Functions inherited from peano4.solversteps.ActionSet.ActionSet
	get_constructor_body (self)
	Define a tailored constructor body.

	get_static_initialisations (self, full_qualified_classname)

	get_destructor_body (self)

	get_body_of_getGridControlEvents (self)

	get_body_of_prepareTraversal (self)

	get_body_of_unprepareTraversal (self)

	get_attributes (self)
	Return attributes as copied and pasted into the generated class.

Protected Attributes
	_guards

	_butcher_tableau

Protected Attributes inherited from exahype2.solvers.rkfd.actionsets.AbstractRKFDActionSet.AbstractRKFDActionSet
	_solver

Static Private Attributes
str	__Template_TouchCellLastTime

Additional Inherited Members
Data Fields inherited from peano4.solversteps.ActionSet.ActionSet
	descend_invocation_order

	parallel

Static Public Attributes inherited from peano4.solversteps.ActionSet.ActionSet
str	OPERATION_BEGIN_TRAVERSAL = "beginTraversal"

str	OPERATION_END_TRAVERSAL = "endTraversal"

str	OPERATION_CREATE_PERSISTENT_VERTEX = "createPersistentVertex"

str	OPERATION_DESTROY_PERSISTENT_VERTEX = "destroyPersistentVertex"

str	OPERATION_CREATE_HANGING_VERTEX = "createHangingVertex"

str	OPERATION_DESTROY_HANGING_VERTEX = "destroyHangingVertex"

str	OPERATION_CREATE_PERSISTENT_FACE = "createPersistentFace"

str	OPERATION_DESTROY_PERSISTENT_FACE = "destroyPersistentFace"

str	OPERATION_CREATE_HANGING_FACE = "createHangingFace"

str	OPERATION_DESTROY_HANGING_FACE = "destroyHangingFace"

str	OPERATION_CREATE_CELL = "createCell"

str	OPERATION_DESTROY_CELL = "destroyCell"

str	OPERATION_TOUCH_VERTEX_FIRST_TIME = "touchVertexFirstTime"

str	OPERATION_TOUCH_VERTEX_LAST_TIME = "touchVertexLastTime"

str	OPERATION_TOUCH_FACE_FIRST_TIME = "touchFaceFirstTime"

str	OPERATION_TOUCH_FACE_LAST_TIME = "touchFaceLastTime"

str	OPERATION_TOUCH_CELL_FIRST_TIME = "touchCellFirstTime"

str	OPERATION_TOUCH_CELL_LAST_TIME = "touchCellLastTime"

Detailed Description

Project patch data onto faces, so the faces hold valid data which can feed into the subsequent Runge-Kutta step.

This class is based upon peano4.toolbox.blockstructured.ProjectPatchOntoFaces. Yet, it differs fundamentally in the way the inner-most loop is realised: The standard projection from the toolbox takes a solution from a patch and copies parts of this solution onto the faces. This is not what we want to have here: we have the solution plus a number of estimates, and we want to write exactly the type of Runge-Kutta linear combination onto the face that we need to set the proper halo data on the adjacent cells in the next grid sweep. Therefore, this class expects the Butcher tableau and first computes the Runge-Kutta linear combination. The outcome of this is then projected onto the faces.

The routine is always called as one of the last things, i.e. we have a valid estimate in. To some degree, we anticipate what will happening next in the Runge-Kutta scheme.

Once more: Each cell hosts the p predictions created by Runge-Kutta of the pth order. These are stored in the field rhs estimates. The projection combines these predictions using the Butcher tableau and projects the linear combination onto the face. The action set never ever uses what's stored in the value array. It always computes this linear combination.

Auxiliary parameters

Auxiliary parameters are not subject to the PDE in ExaHyPE's jargon. They typically carry material parameters or similar. We project them onto the faces, but here we don't do linear combinations due to the Butcher tableau, as the rhs estimates do not hold any auxiliary parameters at all.

Last Runge-Kutta step

The last Runge-Kutta step is slightly different. After the last Runge-Kutta estimate, the solver combines all the estimates into a new solution. Consult the action set ComputeFinalLinearCombination for details. After this has happened, we could take the plain solution stored within the cell and write this guy onto the faces.

Instead, we ignore the face that the action set ComputeFinalLinearCombination would do all of this. Instead, we compute the final linear combination from the rhs guesses (redundantly) and project the outcome onto the faces.

Invocation order

To be able to recompute the linear combination of rhs guesses from the Runge-Kutta scheme, this projection has to be invoked before we determine the final linear combination per cell and overwrite the solution in the patch. This means its descend_invocation_order has to be higher than the one from the linear combination computation, as touchCellLastTime() inverts this order.

Write data

The data is written onto the faces' QUpdate data field. Faces in the Runge-Kutta scheme hold three different Q representations:

The old solution from the previous time step.
The current solution.
The update solution, i.e. the one we have just projected.

It is the your job to ensure that the updated solution is later on copied over into the new solution, so it is taken into account by the halo/patch reconstruction.

Realisation

I did not find a convenient, simple way how to tweak the projection from the toolbox according to this scheme. So I ended up with copying the whole thing over and change the critical things myself.

Boundary flags

Another difference compared to the toolbox projection is that the projection also sets the isUpdated() flag and the UpdatedTimeStamp(). As the projection writes to these two updated records, it is important that you roll it over afterwards. This is done via the mapping RollOverUpdatedFace.

It is important to study this action set in combination with DynamicAMR. In the documentation of the latter I explain why we need the guard

not marker.hasBeenRefined()

if we want to support dynamic coarsening.

Use action set in additional helper sweeps

The action set expects users to specify one predicate per Runge-Kutta step. This means there is one if that checks which Runge-Kutta step is active. This one is typically combined with two other checks: Is the solver currently handling an unrefined cell (we only solve on the finest level) and are we in the right phase of an enclave solve. The latter is relevant if and only if we work with enclave tasking.

If the action set is used by an additional grid sweep outside of the actual time stepping, the checks become simpler:

project_patch_onto_faces = exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces(my_solver)

project_patch_onto_faces.guards = [ my_solver._store_cell_data_default_guard() for x in range(0,my_solver.number_of_Runge_Kutta_steps()+1) ]

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces

Project patch data onto faces, so the faces hold valid data which can feed into the subsequent Runge-...

Definition ProjectPatchOntoFaces.py:13

Here, we basically say "for each unrefined cell always for each Runge-Kutta step as well as for the final linear combination". The latter one is reflected by the +1.

Besides this, you also have to roll over the data:

roll_over_projected_faces = exahype2.solvers.rkfd.actionsets.RollOverUpdatedFace(my_solver, 
                                                                                 my_solver._store_face_data_default_guard(),
                                                                                 )

All solvers at the moment send out their face data in the suspended mode, so you should be fine here.

Definition at line 13 of file ProjectPatchOntoFaces.py.

Constructor & Destructor Documentation

◆ init()

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.__init__	(		self,
			solver )

solver: ADERDG Reference to creating class

Reimplemented from exahype2.solvers.rkfd.actionsets.AbstractRKFDActionSet.AbstractRKFDActionSet.

Definition at line 393 of file ProjectPatchOntoFaces.py.

Member Function Documentation

◆ get_action_set_name()

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_action_set_name ( self )

You should replicate this function in each subclass, so you get meaningful action set names (otherwise, it will be AbstractRKFDActionSet0,1,2,...).

Reimplemented from exahype2.solvers.rkfd.actionsets.AbstractRKFDActionSet.AbstractRKFDActionSet.

Definition at line 417 of file ProjectPatchOntoFaces.py.

◆ get_body_of_operation()

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_body_of_operation	(		self,
			operation_name )

Return actual C++ code snippets to be inserted into C++ code.

See class' string constants starting with OPERATION_ for possible values of operation_name.

Reimplemented from peano4.solversteps.ActionSet.ActionSet.

Definition at line 420 of file ProjectPatchOntoFaces.py.

Here is the call graph for this function:

◆ get_includes()

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_includes ( self )

Return include statements that you need.

All of these includes will eventually end up in the header of the generated C++ code.

Reimplemented from exahype2.solvers.rkfd.actionsets.AbstractRKFDActionSet.AbstractRKFDActionSet.

Definition at line 462 of file ProjectPatchOntoFaces.py.

◆ guards() [1/2]

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.guards ( self )

Definition at line 399 of file ProjectPatchOntoFaces.py.

Referenced by exahype2.solvers.rkdg.actionsets.DynamicAMR.DynamicAMR.get_body_of_operation(), exahype2.solvers.rkdg.actionsets.HandleBoundary.HandleBoundary.get_body_of_operation(), exahype2.solvers.rkdg.actionsets.LinearCombinationOfEstimates.LinearCombinationOfEstimates.get_body_of_operation(), exahype2.solvers.rkdg.actionsets.ProjectLinearCombinationOfEstimatesOntoFaces.ProjectLinearCombinationOfEstimatesOntoFaces.get_body_of_operation(), exahype2.solvers.rkdg.actionsets.SolveRiemannProblem.SolveRiemannProblem.get_body_of_operation(), exahype2.solvers.rkdg.actionsets.SolveVolumeIntegral.SolveVolumeIntegral.get_body_of_operation(), exahype2.solvers.rkfd.actionsets.LinearCombinationOfEstimates.LinearCombinationOfEstimates.get_body_of_operation(), and exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_body_of_operation().

Here is the caller graph for this function:

◆ guards() [2/2]

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.guards	(		self,
			new_guards )

Definition at line 405 of file ProjectPatchOntoFaces.py.

Here is the caller graph for this function:

Field Documentation

◆ __Template_TouchCellLastTime

str exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.__Template_TouchCellLastTime

staticprivate

Definition at line 140 of file ProjectPatchOntoFaces.py.

Referenced by exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces.get_body_of_operation(), exahype2.tracer.DumpTracerIntoDatabase.DumpTracerIntoDatabase.get_body_of_operation(), peano4.toolbox.particles.ParticleAMR.ParticleAMR.get_body_of_operation(), peano4.toolbox.particles.ParticleTreeAnalysis.ParticleTreeAnalysis.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_Sets.UpdateParticle_MultiLevelInteraction_Sets.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists.UpdateParticle_MultiLevelInteraction_StackOfLists.get_body_of_operation(), peano4.toolbox.particles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.UpdateParticle_MultiLevelInteraction_StackOfLists_ContiguousParticles.get_body_of_operation(), swift2.actionsets.DynamicMeshRefinementAnalysis.DynamicMeshRefinementAnalysis.get_body_of_operation(), and swift2.actionsets.UpdateParticleMarker.UpdateParticleMarker.get_body_of_operation().

◆ _butcher_tableau

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces._butcher_tableau

protected

Definition at line 396 of file ProjectPatchOntoFaces.py.

◆ _guards

exahype2.solvers.rkfd.actionsets.ProjectPatchOntoFaces.ProjectPatchOntoFaces._guards

protected

Definition at line 395 of file ProjectPatchOntoFaces.py.

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

python/exahype2/solvers/rkfd/actionsets/ProjectPatchOntoFaces.py

Public Member Functions

Protected Attributes

Static Private Attributes

Additional Inherited Members

Detailed Description

Auxiliary parameters

Last Runge-Kutta step

Invocation order

Write data

Realisation

Boundary flags

Use action set in additional helper sweeps

Constructor & Destructor Documentation

◆ __init__()

Member Function Documentation

◆ get_action_set_name()

◆ get_body_of_operation()

◆ get_includes()

◆ guards() [1/2]

◆ guards() [2/2]

Field Documentation

◆ __Template_TouchCellLastTime

◆ _butcher_tableau

◆ _guards

◆ init()