Peano 4
Loading...
Searching...
No Matches
applications::exahype2::ccz4 Namespace Reference

Namespaces

namespace  internal
 

Data Structures

class  CCZ4
 
class  FiniteVolumeCCZ4
 
class  RKDGCCZ4
 

Functions

KeywordToAvoidDuplicateSymbolsForInlinedFunctions void ncp (double *BgradQ, const double *const Q, const double *const gradQSerialised, const int normal, const int CCZ4LapseType, const double CCZ4ds, const double CCZ4c, const double CCZ4e, const double CCZ4f, const double CCZ4bs, const double CCZ4sk, const double CCZ4xi, const double CCZ4mu, const double CCZ4SO) InlineMethod
 
KeywordToAvoidDuplicateSymbolsForInlinedFunctions void source (double *S, const double *const Q, const int CCZ4LapseType, const double CCZ4ds, const double CCZ4c, const double CCZ4e, const double CCZ4f, const double CCZ4bs, const double CCZ4sk, const double CCZ4xi, const double CCZ4itau, const double CCZ4eta, const double CCZ4k1, const double CCZ4k2, const double CCZ4k3, const double CCZ4SO) InlineMethod
 The source term is one out of two terms that we use in our CCZ4 formulation.
 
KeywordToAvoidDuplicateSymbolsForInlinedFunctions double maxEigenvalue (const double *const Q, int normal, const double CCZ4e, const double CCZ4ds, const double CCZ4GLMc, const double CCZ4GLMd) InlineMethod
 
void admconstraints (double *constraints, const double *const Q, const double *const gradQSerialised)
 This is a postprocessing routine to monitor if the physical constraints are fulfilled.
 
void ThetaOutputNCP (double *NCPterm, const double *const Q, const double *const gradQSerialised, int normal)
 A temporary test function, to output Hamilton constraint related term in theta, 1 terms: RPlusTwoNablaZNCP.
 
void TestingOutput (double *terms, const double *const Q, const double *const gradQSerialised)
 A temporary test function, to output some testing values 0,1 entries: Hamilton constraint related term in theta, 2 terms: RPlusTwoNablaZSrc, pure Src 2-10 entry: no-symmetry version of R_ij.
 
void Psi4Calc (double *Psi4, const double *const Q, const double *const gradQSerialised, double *coor)
 This function is for the calculation of psi4, a quantity related to gravitional wave.
 
void enforceCCZ4constraints (double *__restrict__ newQ)
 A postprocessing routine which pushes the volume solution back into the area of the CCZ4 constraints.
 
void enforceCCZ4constraints (const double *__restrict__ oldQ, double *__restrict__ dQdt, double timeStepSize)
 Anticipate Euler step and correct dQdt such that outcome does fulfill constraints.
 
void gaugeWave (double *__restrict__ Q, const tarch::la::Vector< Dimensions, double > &x, double t)
 
void diagonal_gaugeWave (double *__restrict__ Q, const tarch::la::Vector< Dimensions, double > &x, double t)
 
void linearWave (double *__restrict__ Q, const tarch::la::Vector< Dimensions, double > &X, double t)
 
void flat (double *__restrict__ Q, const tarch::la::Vector< Dimensions, double > &X, double t)
 
void recomputeAuxiliaryVariablesFD4_4thOrder (::exahype2::CellData &patchData, int numberOfGridCellsPerPatchPerAxis, int haloSize, int unknowns, int auxiliaryVariables)
 Recompute auxiliary variables for FD4 scheme with a 4th order scheme.
 
void recomputeAuxiliaryVariablesFD4_centralDifferences (::exahype2::CellData &patchData, int numberOfGridCellsPerPatchPerAxis, int haloSize, int unknowns, int auxiliaryVariables)
 
void recomputeAuxiliaryVariablesFD4_leftDifferences (::exahype2::CellData &patchData, int numberOfGridCellsPerPatchPerAxis, int haloSize, int unknowns, int auxiliaryVariables)
 
void recomputeAuxiliaryVariablesFD4_rightDifferences (::exahype2::CellData &patchData, int numberOfGridCellsPerPatchPerAxis, int haloSize, int unknowns, int auxiliaryVariables)
 

Function Documentation

◆ admconstraints()

void applications::exahype2::ccz4::admconstraints ( double * constraints,
const double *const Q,
const double *const gradQSerialised )

This is a postprocessing routine to monitor if the physical constraints are fulfilled.

Used in python script.

Definition at line 132 of file CCZ4Kernels.cpp.

References j, k, and tarch::memset().

Here is the call graph for this function:

◆ diagonal_gaugeWave()

void applications::exahype2::ccz4::diagonal_gaugeWave ( double *__restrict__ Q,
const tarch::la::Vector< Dimensions, double > & x,
double t )

< Amplitude of the wave, B in the note

Definition at line 53 of file InitialValues.cpp.

References tarch::memset().

Referenced by applications::exahype2::ccz4::CCZ4::initialCondition(), applications::exahype2::ccz4::FiniteVolumeCCZ4::initialCondition(), benchmarks::exahype2::ccz4::CCZ4::initialCondition(), and applications::exahype2::ccz4::RKDGCCZ4::initialCondition().

Here is the call graph for this function:
Here is the caller graph for this function:

◆ enforceCCZ4constraints() [1/2]

void applications::exahype2::ccz4::enforceCCZ4constraints ( const double *__restrict__ oldQ,
double *__restrict__ dQdt,
double timeStepSize )

Anticipate Euler step and correct dQdt such that outcome does fulfill constraints.

Definition at line 12 of file CCZ4Kernels.cpp.

References enforceCCZ4constraints().

Here is the call graph for this function:

◆ enforceCCZ4constraints() [2/2]

void applications::exahype2::ccz4::enforceCCZ4constraints ( double *__restrict__ newQ)

A postprocessing routine which pushes the volume solution back into the area of the CCZ4 constraints.

This is a local operation that we can invoke after each time step per volume.

If works on the full set of unknowns of the first-order formulation

Referenced by enforceCCZ4constraints().

Here is the caller graph for this function:

◆ flat()

void applications::exahype2::ccz4::flat ( double *__restrict__ Q,
const tarch::la::Vector< Dimensions, double > & X,
double t )

Definition at line 118 of file InitialValues.cpp.

References tarch::memset().

Referenced by applications::exahype2::ccz4::CCZ4::initialCondition(), applications::exahype2::ccz4::FiniteVolumeCCZ4::initialCondition(), and benchmarks::exahype2::ccz4::CCZ4::initialCondition().

Here is the call graph for this function:
Here is the caller graph for this function:

◆ gaugeWave()

void applications::exahype2::ccz4::gaugeWave ( double *__restrict__ Q,
const tarch::la::Vector< Dimensions, double > & x,
double t )
  • * This file is automatically created by Peano. I need it to interact with
    • * the Python API, i.e. to read out data set there.

< Amplitude of the wave

Definition at line 20 of file InitialValues.cpp.

References tarch::memset().

Referenced by applications::exahype2::ccz4::CCZ4::initialCondition(), applications::exahype2::ccz4::FiniteVolumeCCZ4::initialCondition(), benchmarks::exahype2::ccz4::CCZ4::initialCondition(), and applications::exahype2::ccz4::RKDGCCZ4::initialCondition().

Here is the call graph for this function:
Here is the caller graph for this function:

◆ linearWave()

void applications::exahype2::ccz4::linearWave ( double *__restrict__ Q,
const tarch::la::Vector< Dimensions, double > & X,
double t )

< Amplitude of the wave, should be very small to keep linearized.

Definition at line 92 of file InitialValues.cpp.

References tarch::memset().

Referenced by applications::exahype2::ccz4::CCZ4::initialCondition(), applications::exahype2::ccz4::FiniteVolumeCCZ4::initialCondition(), benchmarks::exahype2::ccz4::CCZ4::initialCondition(), and applications::exahype2::ccz4::RKDGCCZ4::initialCondition().

Here is the call graph for this function:
Here is the caller graph for this function:

◆ maxEigenvalue()

KeywordToAvoidDuplicateSymbolsForInlinedFunctions double applications::exahype2::ccz4::maxEigenvalue ( const double *const Q,
int normal,
const double CCZ4e,
const double CCZ4ds,
const double CCZ4GLMc,
const double CCZ4GLMd )
Todo
Han
Todo
Han

Definition at line 6 of file CCZ4Kernels.cpph.

Referenced by applications::exahype2::ccz4::CCZ4::maxEigenvalue(), and applications::exahype2::ccz4::FiniteVolumeCCZ4::maxEigenvalue().

Here is the caller graph for this function:

◆ ncp()

KeywordToAvoidDuplicateSymbolsForInlinedFunctions void applications::exahype2::ccz4::ncp ( double * BgradQ,
const double *const Q,
const double *const gradQSerialised,
const int normal,
const int CCZ4LapseType,
const double CCZ4ds,
const double CCZ4c,
const double CCZ4e,
const double CCZ4f,
const double CCZ4bs,
const double CCZ4sk,
const double CCZ4xi,
const double CCZ4mu,
const double CCZ4SO )
See also
source() for a discussion of annotations.

Definition at line 509 of file CCZ4Kernels.cpph.

References j, and k.

◆ Psi4Calc()

void applications::exahype2::ccz4::Psi4Calc ( double * Psi4,
const double *const Q,
const double *const gradQSerialised,
double * coor )

This function is for the calculation of psi4, a quantity related to gravitional wave.

Not used yet.

Definition at line 376 of file CCZ4Kernels.cpp.

References j, and k.

◆ recomputeAuxiliaryVariablesFD4_4thOrder()

void applications::exahype2::ccz4::recomputeAuxiliaryVariablesFD4_4thOrder ( ::exahype2::CellData & patchData,
int numberOfGridCellsPerPatchPerAxis,
int haloSize,
int unknowns,
int auxiliaryVariables )

Recompute auxiliary variables for FD4 scheme with a 4th order scheme.

We are given a patch as well as the number of mesh cells per axis within this patch. I also parameterise over the unknowns and the auxiliaryVariables. By default, we'd expect 59 and 0 here, but we want to routine to work for augmented systems, too.

The reconstruction uses a 4th order Finite Difference scheme. The implementation in applications::exahype2::ccz4::internal::recomputeAuxiliaryVariablesFD4_4thOrder_LoopBody() realises the normal stencil

[1 -8 0 8 -1]

scaled with \( \frac{1}{12h} \). There is a fundamental problem with this variant which is worth mentioning: To evaluate this stencil, we need a halo layer of at least two. For a given haloSize, we can never update the outermost two layers of the code.

Shortcomings

As we use a fourth order scheme, we need two neighbours around each point to construct the outcome. That means, when we are given a patch with size 3 (left illustation above), we effectively can only calculate the auxiliary variables within the patch (green) and the first halo layer around it (brownish). This is illustrated to the right.

There's one further complexity: we usually do not have the digonal values in ExaHyPE. What we really get is not the illustration above to the left but the one in the centre. The diagonal blocks hold garbage. As a consequence, the auxiliary data in the brown data layer to the right is not properly computed. In the left brown layer, only the x-derivatives are properly reconstructed. The y-derivatives contain garbage.

Parameters
patchDataHost the actual patch data. For this function, we only have to ensure that the QIn (data plus halo) are properly set, and that the patch size in patchData is correct. All the other (meta data) properties have no influence and can hold any data.
numberOfGridCellsPerPatchPerAxisHas to be at least 3, as the halo is also at least three. More general, has to be bigger or equal to haloSize.
haloSizeHas to be at least 3.
unknownsTypically 59, but can be bigger if you hold additional quantities within the PDE.
auxiliaryVariablesTypically 0.
See also
applications::exahype2::ccz4::internal::recomputeAuxiliaryVariablesFD4_4thOrder_LoopBody()

Definition at line 155 of file SecondOrderAuxiliaryVariablesReconstruction.cpp.

References assertion, exahype2::CellData::cellCentre, exahype2::CellData::cellSize, exahype2::CellData::numberOfCells, and exahype2::CellData::QIn.

◆ recomputeAuxiliaryVariablesFD4_centralDifferences()

void applications::exahype2::ccz4::recomputeAuxiliaryVariablesFD4_centralDifferences ( ::exahype2::CellData & patchData,
int numberOfGridCellsPerPatchPerAxis,
int haloSize,
int unknowns,
int auxiliaryVariables )

◆ recomputeAuxiliaryVariablesFD4_leftDifferences()

void applications::exahype2::ccz4::recomputeAuxiliaryVariablesFD4_leftDifferences ( ::exahype2::CellData & patchData,
int numberOfGridCellsPerPatchPerAxis,
int haloSize,
int unknowns,
int auxiliaryVariables )

◆ recomputeAuxiliaryVariablesFD4_rightDifferences()

void applications::exahype2::ccz4::recomputeAuxiliaryVariablesFD4_rightDifferences ( ::exahype2::CellData & patchData,
int numberOfGridCellsPerPatchPerAxis,
int haloSize,
int unknowns,
int auxiliaryVariables )

◆ source()

KeywordToAvoidDuplicateSymbolsForInlinedFunctions void applications::exahype2::ccz4::source ( double * S,
const double *const Q,
const int CCZ4LapseType,
const double CCZ4ds,
const double CCZ4c,
const double CCZ4e,
const double CCZ4f,
const double CCZ4bs,
const double CCZ4sk,
const double CCZ4xi,
const double CCZ4itau,
const double CCZ4eta,
const double CCZ4k1,
const double CCZ4k2,
const double CCZ4k3,
const double CCZ4SO )

The source term is one out of two terms that we use in our CCZ4 formulation.

As it is used within the compute kernel, we also want to use it on the GPU, and we want to vectorise over it aggressively. To make this work, we have to inline the function plus ensure that the interna of the function are not vectorised before we inline the routine.

So we first declare it as simd and then we also say explicitly that it should be inlined. In my opinion, the inlining should imply that we wanna use it as SIMD, but my guess is that the simd statement ensures that the compiler doesn't prematurely vectorise.

See also
ncp()

Main variables of the CCZ4 system

Definition at line 25 of file CCZ4Kernels.cpph.

References j, and k.

Referenced by applications::exahype2::ccz4::internal::recomputeAuxiliaryVariablesFD4_centralDifferences_LoopBody(), applications::exahype2::ccz4::internal::recomputeAuxiliaryVariablesFD4_leftDifferences_LoopBody(), applications::exahype2::ccz4::internal::recomputeAuxiliaryVariablesFD4_rightDifferences_LoopBody(), applications::exahype2::ccz4::CCZ4::sourceTerm(), applications::exahype2::ccz4::FiniteVolumeCCZ4::sourceTerm(), and benchmarks::exahype2::ccz4::CCZ4::sourceTerm().

Here is the caller graph for this function:

◆ TestingOutput()

void applications::exahype2::ccz4::TestingOutput ( double * terms,
const double *const Q,
const double *const gradQSerialised )

A temporary test function, to output some testing values 0,1 entries: Hamilton constraint related term in theta, 2 terms: RPlusTwoNablaZSrc, pure Src 2-10 entry: no-symmetry version of R_ij.

Definition at line 678 of file CCZ4Kernels.cpp.

References j, k, and tarch::memset().

Here is the call graph for this function:

◆ ThetaOutputNCP()

void applications::exahype2::ccz4::ThetaOutputNCP ( double * NCPterm,
const double *const Q,
const double *const gradQSerialised,
int normal )

A temporary test function, to output Hamilton constraint related term in theta, 1 terms: RPlusTwoNablaZNCP.

Definition at line 955 of file CCZ4Kernels.cpp.

References j, and k.