Peano

Searching...

No Matches

The handling of (dynamically) adaptive meshes for finite differences. More...

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

[legend]

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

[legend]

Public Member Functions
	__init__ (self, solver, interpolation, restriction)
	Construct object.

	get_action_set_name (self)
	Return unique action set name.

	get_includes (self)
	Return include statements that you need.

Public Member Functions inherited from peano4.toolbox.blockstructured.DynamicAMR.DynamicAMR
	get_constructor_body (self)
	Define a tailored constructor body.

	get_destructor_body (self)

	get_body_of_getGridControlEvents (self)

	user_should_modify_template (self)
	Is the user allowed to modify the output.

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

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

	get_clear_guard (self)

	get_restrict_guard (self)

	get_interpolate_guard (self)

	switch_interpolation_scheme (self, interpolation_scheme)

	switch_restriction_scheme (self, restriction_scheme)

Public Member Functions inherited from peano4.solversteps.ActionSet.ActionSet
	get_static_initialisations (self, full_qualified_classname)

	get_body_of_prepareTraversal (self)

	get_body_of_unprepareTraversal (self)

Protected Attributes
	_Template_TouchFaceFirstTime

	_Template_DestroyHangingFace

	_Template_DestroyPersistentFace

	_Template_CreateHangingFace

	_Template_CreatePersistentFace

	_Template_CreateCell

	_Template_DestroyCell

Additional Inherited Members
Data Fields inherited from peano4.toolbox.blockstructured.DynamicAMR.DynamicAMR
	d

	additional_includes

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"

Static Protected Attributes inherited from peano4.toolbox.blockstructured.DynamicAMR.DynamicAMR
str	_Template_TouchFaceFirstTime

str	_Template_TouchCellFirstTime

str	_Template_CreateHangingFace

str	_Template_DestroyHangingFace

str	_Template_CreatePersistentFace

str	_Template_DestroyPersistentFace

str	_Template_CreateCell

str	_Template_DestroyCell

Detailed Description

The handling of (dynamically) adaptive meshes for finite differences.

This class just invokes interpolation operators. Please consult the documentation of the base class CellCenteredFiniteDifferences for a discussion of interpolation and restriction operators. The class documentation also explains how you switch to operators that you pass in manually.

Definition at line 11 of file DynamicAMR.py.

Constructor & Destructor Documentation

◆ init()

exahype2.solvers.rkfd.actionsets.DynamicAMR.DynamicAMR.__init__	(	self,
		solver,
		interpolation,
		restriction )

Construct object.

:: Interpolation

Don't interpolate in initialisation. If you have a parallel run with AMR, then some boundary data has not been received yet and your face data thus is not initialised at all. Other than that, the interpolation is always on.

:: Restriction

In contrast to the interpolation, it is absolutely key that we restrict alreaday in the initialisation. If we have a cell that is adjacent to a refined cell, then this cell requires proper face data for the subsequent first time step. So we have to restrict in the initialisation even if there's no update yet - just to get the coarse representation of fine hanging faces initialised.

:: Restriction of destructed faces

A destructed face has to restrict its data: We've already restricted the cells, but now we also have to restrict the faces, as faces span time spans. The cell is only a snapshot, so we have to manually restrict.

It is important to also disable the projection in return. The projection onto the faces happens in leaveCell. However, if you have a face in-between two 3x3 patches, then you will have a destruction of the left patch (and a corresponding cell restriction), the coarse cell will then project its data onto the face, you go down on the other side and now the face will be destroyed. If you restrict now, you overwrite the projected data with some (old) data, and you will get an inconsistent face data. However, you always have to restrict both sides of persistent face when it is destroyed. If you only restricted the inner part, you'd run into situations where a 3x3 patch is coarsened, but its neighbour remains refined. That is, logically the face transitions from a persistent one to a hanging face. When yo go through the mesh next time, you'll need, on the coarse level, some valid data. So we have to restrict both sides.

There's still a inconsistency here. To have really consistent data, we'd have to average 3^{d-1} cells when we project them onto the face, such that the cell-restricted data followed by a (single cell) projection gives the same result as a projection first and then a face restriction. I neglect this fact here.

:: Interpolation throughout the grid initialisation

Throughout the grid initialisation, we cannot interpolate the halo layers reliably. If we descend into a cell and want to initialise one of its hanging faces, we cannot know, if the coarser cell on the other side has been initialised already. Therefore, we cannot initialise the halo of a hanging face.

For persistent faces, this is something we don't bother about: We create both adjacent cells of the respective face and then we will project this solution onto the faces. Problem set, as all data is properly set.

For hanging faces, we will get the projection from the adjacent real cell. But we cannot get a proper initialisation for the other half of the face data. These data however is required for some restrictions. Even if we mask out the impact of halo data on the restriction, it might, in the initialisation sweep, hold nans, and 0 * nan = nan. So we will get garbage. In later time steps, this does not hold, as we have properly initialised coarse grid data then on all sides.

To solve this issue, we initialise the hanging face data properly using the user's callbacks. These data will later be overwritten with (coarser) data which is interpolated. For the initialisation, it provides us with proper initial guesses.

Reimplemented from peano4.toolbox.blockstructured.DynamicAMR.DynamicAMR.

Definition at line 24 of file DynamicAMR.py.

Referenced by exahype2.solvers.rkfd.actionsets.DynamicAMR.DynamicAMR.__init__().

Here is the call graph for this function:

Here is the caller graph for this function:

Member Function Documentation

◆ get_action_set_name()

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

Return unique action set name.

Returns a description (word) for the mapping which is also used as class name for the generated type. As a consequence, the result should be one word (if possible) and uppercase. Also, every subclass should overwrite this routine.

The generator will take the result and construct eventually classes similar to MyStep2Dummy.h and MyStep2Dummy.cpp or similar for the example below, where we return Dummy.

Reimplemented from peano4.toolbox.blockstructured.DynamicAMR.DynamicAMR.

Definition at line 426 of file DynamicAMR.py.