Support material parameters
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.