AMR+LimitingADERDGSolver crashes for certain limiter status changes
1. Issue:
There is another issue with the MUSCL-Hancock solver which crashes in the min and max determination after a global recomputation.
147.062 info exahype::runners::Runner::updateMeshFusedTimeStepping(...) recompute solution locally (if applicable) and compute new time step size
assertion in file /home/dominic/dev/codes/c/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/LimitingADERDGSolver.cpp, line 1111 failed: *(observablesMin+i)<std::numeric_limits<double>::max()
parameter i: 1
parameter solverPatch.toString(): (solverNumber:0,neighbourMergePerformed:[1,1,1,1],isInside:[1,1,0,1],parentIndex:69,isAugmented:0,newlyCreated:0,type:Cell,refinementEvent:None,level:5,offset:[0.518519,0],size:[0.0123457,0.0123457],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:1.79769e+308,correctorTimeStepSize:0.000497671,correctorTimeStamp:0.0909671,predictorTimeStepSize:0,predictorTimeStamp:0.0914648,solution:2838,solutionAverages:2843,solutionCompressed:-1,previousSolution:2839,previousSolutionAverages:2841,previousSolutionCompressed:-1,update:2840,updateAverages:2842,updateCompressed:-1,extrapolatedPredictor:2844,extrapolatedPredictorAverages:2846,extrapolatedPredictorCompressed:-1,fluctuation:2845,fluctuationAverages:2847,fluctuationCompressed:-1,solutionMin:2848,solutionMax:2849,facewiseAugmentationStatus:[0,0,0,0],augmentationStatus:0,facewiseHelperStatus:[2,2,2,2],helperStatus:2,facewiseLimiterStatus:[0,0,0,0],limiterStatus:0,previousLimiterStatus:3,iterationsToCureTroubledCell:10,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:305,bytesPerDoFInSolution:-296662368,bytesPerDoFInUpdate:32765,bytesPerDoFInExtrapolatedPredictor:0,bytesPerDoFInFluctuation:0)
ExaHyPE-Euler: /home/dominic/dev/codes/c/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/LimitingADERDGSolver.cpp:1111: void exahype::solvers::LimitingADERDGSolver::determineSolverMinAndMax(exahype::solvers::LimitingADERDGSolver::SolverPatch&): Assertion `false' failed.
I have to gather more information about this first.
2. Issue
Cell of type 3 or 4 (FV->DG) changes to Troubled. Neighbour is of Type 1 or 2 (DG->FV).
Example:
- Fix 1: Need to stop iterations if situation detected in neighbour merging -> write stable values, i.e. own values to ghost layer -> Perform rollback in affected cells (=>irregular limiter domain chage; requires local recomputation)
- Fix 2: Use less dissipative FV methods or higher order ADERDG => finer subcell resolution Or set parameter steps to cure troubled cells to a higher value
3. Found bugs:
- The whole global recomputation thing is more sophisticated than previously thought. I have to be careful how I go back in time. This is based on the previous limiter status. I am only allowed to delete patches after the recomputation.
4. Ways to increase stability
- Do not change Local Recomputation to Global Recomputation if limiter based mesh refinement is also necessary.
5. Algorithms:
(Stuff above is outdated. Keep it for reference.)
Local Recomputation
- limiter status spreading
- local reinitialisation
- local recomputation + local predictor computation
Global Recomputation
- limiter status spreading
- global rollback (keep new limiter status) <-ensures we adjust the previous solution during mesh refinement
- mesh refinement according to new limiter status
- overwrite new limiter status with previous values
- recompute time step size
- reinitialise fused time stepping and recompute predictor
Problems:
- TimeStepSizeComputation does update the time stamps (solved)
- Need additional adapter for global rollback (global reinitialisation)
- I am not allowed to deallocate limiter patches during limiter status spreading
- Have to keep in mind to overwrite the limiter status in finalise mesh refinement.
Mesh Refinement
- mesh refinement according to ref. crit.
- recompute time step size
- reinitialise fused time stepping and recompute predictor