Peano

Searching...

No Matches

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

#include <RefinementControl.h>

Collaboration diagram for exahype2::RefinementControl:

[legend]

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

Public Member Functions
	RefinementControl (double tolerance=0.01)

virtual	~RefinementControl ()

void	clear ()
	Clears the new 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.

std::string	toString () const

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

NewEvents	_newEvents
	Container to accumulate new events.

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

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.

Definition at line 45 of file RefinementControl.cpp.

◆ ~RefinementControl()

exahype2::RefinementControl::~RefinementControl ( )

virtual

Definition at line 50 of file RefinementControl.cpp.

Member Function Documentation

◆ addCommand()

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.

Definition at line 59 of file RefinementControl.cpp.

References assertion, assertionNumericalEquals1, peano4::grid::GridControlEvent::Erase, peano4::grid::GridControlEvent::getH(), peano4::grid::GridControlEvent::getWidth(), logDebug, logTraceInWith3Arguments, logTraceOutWith1Argument, peano4::grid::GridControlEvent::Refine, peano4::grid::GridControlEvent::toString(), and toString().

Here is the call graph for this function:

◆ clear()

void exahype2::RefinementControl::clear ( )

Clears the new 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.

Definition at line 54 of file RefinementControl.cpp.

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

Here is the caller graph for this function:

◆ toString()

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

Definition at line 115 of file RefinementControl.cpp.

Friends And Related Symbol Documentation

◆ RefinementControlService

friend class RefinementControlService

friend

Definition at line 101 of file RefinementControl.h.

Field Documentation

◆ _log

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

staticprivate

Definition at line 153 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 166 of file RefinementControl.h.

Referenced by exahype2::RefinementControlService::merge().

◆ _semaphore

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

staticprivate

Definition at line 155 of file RefinementControl.h.

◆ _Tolerance

const double exahype2::RefinementControl::_Tolerance