GitLab

TODO:

• Make Generic C/C++ kernels support parameters x {FV,ADERDG}

• Make Generic fortran kernels support parameters. ( solutionUpdate is here the problem.)

• In all kernels using the solver template argument switch to the constexpr for variables,parameters,and order/basisSize.

• MyElasticWaveSolver: Realised that we have to rethink our material approach a little. Material parameters are not available from Q during the space-time predictor computation which uses the space-time predictor or predictor DoF. We need either:

  • store the material values in solution(+previousSolution), predictor,and space-time predictor

  • or pass the material values as separate argument to flux,eigenvalues,ncp,matrixb etc. We should then also pass them as separate arguments to adjustedSolutionValues.

    Follow up: It might wise then to split the material parameters from the variables. We have chosen the first option.

• The Nonlinear 2D ADER-DG C/C++ kernels do not support materials yet.

• The Nonlinear 3D ADER-DG C/C++ kernels do not support materials yet.

• The Linear 2D ADER-DG C/C++ kernels do not support materials yet.

• ~~ The Linear3D ADER-DG C/C++ kernels do not support materials yet.~~

• The Fortran ADER-DG kernels do not support materials yet.

• The 2D FV kernels do not support materials yet.

• The 3D FV kernels do not support materials yet.

• The Linear 2D+3D ADER-DG C/C++ kernels need to consider material parameters in the AMR operators.

• (Optional) Transform all generic kernels to templates and use constexpr for variables,parameters and order/basisSize.

Questions:

• What happens at the boundary for the Finite Volumes method? Currently, we hand no material parameters in at the boundary.
• Are there no time averaged source terms in the spaceTimePredictorLinear2d/3d? Yes, I consider them now at least in the striding.
• The linear ADER-DG kernels work with time derivatives. Does it make sense to let the user set the nodal values?
• Why wasn't tempPointForceSources merged into tempSpaceTimeUnknowns. The API change wasn't necessary.

Follow ups:

• Add a boolean to the AbstractMySolver class indicating if we consider Linear or Nonlinear kernels.
• Distinguish more clearly between temporary array sizes and dof array sizes.
• Add a boolean to the AbstractMySolver class indicating if we consider Linear or Nonlinear kernels.