Skip to content

GitLab

Closed
Created by Dominic Charrier@di25coxOwner

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.