variant1 Namespace Reference

There are a total of six variants based on different assumptions. More...

Functions
void	runBenchmarks (int numberOfCells, double timeStamp, double timeStepSize, const tarch::la::Vector< DIMENSIONS, double > cellCenter, const tarch::la::Vector< DIMENSIONS, double > cellSize)

Variables
tarch::logging::Log	_log
	This is variant 1 of the fused kernels. More...

Detailed Description

There are a total of six variants based on different assumptions.

The first assumption has to do with whether face data is defined per face, as in left and right values for a given face, or per cell, as in any given cell having its four (six in 3d) faces.

The second assumption has to do with whether the data for the faces can be shared between neighbours or not, i.e. can two cells share a pointer or does data need to be copied from one to another.

The third assumption is only relevant if two cells cannot share a pointer, and has to do with whether we can solve the Riemann problem once per face and share the solutions of this, or whether we can only share the previous faces data, and must perform the riemann solve on each side of the face independently

The details of the variants are described in their respective files, but the concepts/assumptions are as follows:

1. Face Data defined per cell, only contains a given cells' values
2. Face Data defined per cell, contains values from both sides of the face, but each cell has its own copy of the data which must therefore be transmitted between timesteps
3. Face Data defined per cell, contains values from both sides of the face, with said data shared between two adjacent cells, i.e. both have a pointer to the same data.
4. Face Data defined per face, but not shared between cells, i.e. the data must be copied between two instances of face data. Riemann solvers performed once per face.
5. Face Data defined per face, but not shared between cells. In this variant however the data between the faces is copied and the Riemann solver is then performed per cell.
6. Face Data is defined per face, and shared between cells. I.e. there exists one instance of face data which two cells share and on which the Riemann solver can be computed

Function Documentation

runBenchmarks()

void variant1::runBenchmarks	(	int	numberOfCells,
		double	timeStamp,
		double	timeStepSize,
		const tarch::la::Vector< DIMENSIONS, double >	cellCenter,
		const tarch::la::Vector< DIMENSIONS, double >	cellSize
	)

Definition at line 224 of file Variant1.cpp.

References _log, cellCenter, exahype2::CellFaceData< inType, outType >::cellCentre, exahype2::CellFaceData< inType, outType >::cellSize, cellSize, exahype2::CellFaceData< inType, outType >::dt, firstTask(), initialTask(), benchmarks::exahype2::kernelbenchmarks::initInputData(), benchmarks::exahype2::kernelbenchmarks::NumberOfInputEntriesPerCell, benchmarks::exahype2::kernelbenchmarks::NumberOfOutputEntriesPerCell, exahype2::CellFaceData< inType, outType >::QIn, exahype2::CellFaceData< inType, outType >::QOut, benchmarks::exahype2::kernelbenchmarks::reportRuntime(), secondTask(), exahype2::CellFaceData< inType, outType >::t, timeStamp, timeStepSize, and timingComputeKernel.

Referenced by main().

Here is the call graph for this function:

Here is the caller graph for this function:

Variable Documentation

_log

tarch::logging::Log variant1::_log

extern

This is variant 1 of the fused kernels.

In this variant, we will assume that faceData is constructed per cell, and that it only contains the data from one's own cell, e.g. it cannot access the side of the faces that belong to the neighbour.

This means that the Riemann kernel cannot be performed within a given cell, but must be performed outside of the cells.

Each cell therefore only perform the "cell" kernels and "face" kernels are expected to be performed before any of the cell kernels are accessed.

This can be implemented efficiently as two enclave tasks, with one being dependent on the other, but requires a lot of complicated and fiddly management of faces to ensure that the Riemann kernels are correctly performed on each neighbouring pair of faces, which is very fiddly and uncomfortable.

Upsides: only requires each Riemann Kernel to be performed once does not require any copying of data whatsoever only one dependency between two groups of tasks

Downsides: very fiddly and bug-prone management of faces task dependency is within a timeStep instead of between timeSteps

Referenced by runBenchmarks(), variant2::runBenchmarks(), variant3::runBenchmarks(), variant4::runBenchmarks(), variant5::runBenchmarks(), and variant6::runBenchmarks().