Manage refine/erase requests within ExaHyPE 2. More...

#include <RefinementControl.h>

Collaboration diagram for exahype2::RefinementControl:

[legend]

Data Structures
struct	SiblingEraseEvent
	Erase request of one cell which knows its parent. More...

Public Types
typedef std::list< std::pair< peano4::grid::GridControlEvent, int > >	NewEvents

typedef std::list< SiblingEraseEvent >	NewSiblingEraseEvents

Public Member Functions
	RefinementControl (double tolerance=0.01)

virtual	~RefinementControl ()

void	clear ()
	Clears the new events, including the sibling erase events.

void	addCommand (const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h, exahype2::RefinementCommand command, int lifetime)
	Add a new command.

void	addCommand (const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h, exahype2::RefinementCommand command, int lifetime, const tarch::la::Vector< Dimensions, int > &relativePositionWithinFatherCell)
	Add a new command of a cell which knows its position within its parent.

std::string	toString () const

Private Member Functions
peano4::grid::GridControlEvent	createEraseEvent (const tarch::la::Vector< Dimensions, double > &x, const tarch::la::Vector< Dimensions, double > &h) const
	Construct the grid control event which erases the cell with centre x and size h.

Private Attributes
const double	_Tolerance
	We blow up the region around refinement criterion slightly.

NewEvents	_newEvents
	Container to accumulate new events.

NewSiblingEraseEvents	_newSiblingEraseEvents
	Erase requests of cells which know their parent,.

Static Private Attributes
static tarch::logging::Log	_log

static tarch::multicore::BooleanSemaphore	_semaphore

Friends
class	RefinementControlService

Detailed Description

Manage refine/erase requests within ExaHyPE 2.

This class is a very simple container which collects a point set of refinement and coarsening commands. It then constructs bounding boxes for each command and returns the bounding boxes to Peano 4.

Note: Peano will internally decide to merge many many bounding boxes into fewer, larger ones.

See also: peano4::grid::merge()

Refinement process

We have a two stage refinement process in ExaHyPE. These are ExaHyPE-specific stages and they have nothing to do with the fact that we always trigger the refinement and then refine in the subsequent grid sweep, i.e. it has nothing do do with the fact that ExaHyPE needs two grid sweeps to realise (commit) adaptive mesh refinement:

ExaHyPE first collects all refinement requests within this class. These events are called new events. After the sweep, we roll over the refinement requests. We commit them. These committed events then are delivered to the grid traversal automaton. finishStep() does the roll-over, the delivery happens once you call createGridControlEventsForNextTraversal() through the AMR observer.

Hence, the overall refinement spawns three grid traversals:

The container collects the refinement requests in the first sweep. Towards the end of the sweep, the requests are rolled over (committed).
The second sweep grabs the refinement requests from the container and runs through the mesh. It triggers the refinement for all affected vertices. Nothing is changed yet.
In the third grid sweep, the mesh is refined actually.

Due to the overall three-step mechanism, we make the bookkeeping of the events persistent. Each event can potentially survive a couple of sets within the new events. It is rolled over multiple times until it "expires" within the new events.

See also: _committedEvents

Multithreading

As we use the class within a multithreaded environment, Peano 4 creates an observer object per spacetree through a clone from observer no -1 (per rank, so this observer is not really an observer. It is rather an observer prototype) and then asks this observer how to refine. So we design the following pattern:

When an observer is created, it creates its own local refinement control.
We hand out refine/erase commands from the global one as this is our globally valid repository.
We accumulate the refine/erase instructions locally. So we clear() our local copy when we start to run through the grid and then pipe all commands into this local object.
When we are done, we merge the local copy back.

Definition at line 97 of file RefinementControl.h.

Member Typedef Documentation

◆ NewEvents

typedef std::list< std::pair<peano4::grid::GridControlEvent,int> > exahype2::RefinementControl::NewEvents

Definition at line 99 of file RefinementControl.h.

◆ NewSiblingEraseEvents

typedef std::list< SiblingEraseEvent > exahype2::RefinementControl::NewSiblingEraseEvents

Definition at line 121 of file RefinementControl.h.

Constructor & Destructor Documentation

◆ RefinementControl()

exahype2::RefinementControl::RefinementControl ( double tolerance = 0.01 )

Parameters

tolerance How much should the code add around each grid control. By default we use one percent additional tolerance.

◆ ~RefinementControl()

virtual exahype2::RefinementControl::~RefinementControl ( )

virtual

Member Function Documentation

◆ addCommand() [1/2]

void exahype2::RefinementControl::addCommand	(	const tarch::la::Vector< Dimensions, double > &	x,
		const tarch::la::Vector< Dimensions, double > &	h,
		exahype2::RefinementCommand	command,
		int	lifetime
	)

Add a new command.

Depending on the context, we add a new refinement instruction interpreting x and h. If you refine, I divide h by three.

Lifetime of a refinement event

If a refinement event is triggered, we keep it alive for a while. This avoids oscillations (refinement events always overwrite coarsening) and it helps ranks to catch up - a code might not be able to refine immediately as it implements a Runge-Kutta scheme, e.g. In this case, we keep the event alive and then realise it once the code is ready to do so.

Parameters

x	Centre of the cell for which this command is triggered. This is typically marker.x().
h	Size of this cell. Typically marker.h().
lifetime	Has to be greater equal 1.

◆ addCommand() [2/2]

void exahype2::RefinementControl::addCommand	(	const tarch::la::Vector< Dimensions, double > &	x,
		const tarch::la::Vector< Dimensions, double > &	h,
		exahype2::RefinementCommand	command,
		int	lifetime,
		const tarch::la::Vector< Dimensions, int > &	relativePositionWithinFatherCell
	)

Add a new command of a cell which knows its position within its parent.

Refine and keep commands are handled the same way as by the other addCommand(). An erase command is collected as SiblingEraseEvent instead: The refinement service keeps it only if all 3^d children of the cell's parent have asked to be erased within the same mesh sweep, and drops it otherwise. Peano could not realise an incomplete set of erase requests anyway, and such requests would only trigger mesh sweeps which do not change the mesh.

Parameters

relativePositionWithinFatherCell Position of the cell within its parent, typically marker.getRelativePositionWithinFatherCell(). Each entry is 0, 1 or 2.

◆ clear()

void exahype2::RefinementControl::clear ( )

Clears the new events, including the sibling erase events.

Has no affect for the committed events. This routine should only ever be called by the action sets on their local refinement control assembly. The global one is persistent and should not be cleared by the user, as you would loose all those events that should remain alive. Thererfore, there's no clear for the service.

Referenced by peano4.api.output.Makefile.Makefile::__init__().

Here is the caller graph for this function:

◆ createEraseEvent()

peano4::grid::GridControlEvent exahype2::RefinementControl::createEraseEvent	(	const tarch::la::Vector< Dimensions, double > &	x,
		const tarch::la::Vector< Dimensions, double > &	h
	)		const

private

Construct the grid control event which erases the cell with centre x and size h.

◆ toString()

std::string exahype2::RefinementControl::toString ( ) const

Friends And Related Symbol Documentation

◆ RefinementControlService

friend class RefinementControlService

friend

Definition at line 123 of file RefinementControl.h.

Field Documentation

◆ _log

tarch::logging::Log exahype2::RefinementControl::_log

staticprivate

Definition at line 198 of file RefinementControl.h.

◆ _newEvents

NewEvents exahype2::RefinementControl::_newEvents

private

Container to accumulate new events.

This is a list as we may assume that a lot of inserts are done per iteration.

Definition at line 211 of file RefinementControl.h.

◆ _newSiblingEraseEvents

NewSiblingEraseEvents exahype2::RefinementControl::_newSiblingEraseEvents

private

Erase requests of cells which know their parent,.

See also: SiblingEraseEvent

Definition at line 216 of file RefinementControl.h.

◆ _semaphore

tarch::multicore::BooleanSemaphore exahype2::RefinementControl::_semaphore

staticprivate

Definition at line 200 of file RefinementControl.h.

◆ _Tolerance

const double exahype2::RefinementControl::_Tolerance

private

We blow up the region around refinement criterion slightly.

Definition at line 205 of file RefinementControl.h.

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

src/exahype2/RefinementControl.h

Data Structures

Public Types

Public Member Functions

Private Member Functions

Private Attributes

Static Private Attributes

Friends

Detailed Description

Refinement process

Multithreading

Member Typedef Documentation

◆ NewEvents

◆ NewSiblingEraseEvents

Constructor & Destructor Documentation

◆ RefinementControl()

◆ ~RefinementControl()

Member Function Documentation

◆ addCommand() [1/2]

Lifetime of a refinement event

◆ addCommand() [2/2]

◆ clear()

◆ createEraseEvent()

◆ toString()

Friends And Related Symbol Documentation

◆ RefinementControlService

Field Documentation

◆ _log

◆ _newEvents

◆ _newSiblingEraseEvents

◆ _semaphore

◆ _Tolerance