ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2017-09-26T10:19:58+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/180Compression - take ghostLayers and padding into account2017-09-26T10:19:58+02:00Ghost UserCompression - take ghostLayers and padding into account- FiniteVolumesSolver - Compression should take ghostLayers+padding (alignment) into account
- ADERDGSolver - Compression should take padding (alignment) into account- FiniteVolumesSolver - Compression should take ghostLayers+padding (alignment) into account
- ADERDGSolver - Compression should take padding (alignment) into accounthttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/178Limiting ADER-DG: Solution min and max computation is very expensive2017-09-04T16:02:23+02:00Ghost UserLimiting ADER-DG: Solution min and max computation is very expensiveWe found that the min/max computation (in ExaHyPE) can currently be by a factor 10 more
expensive than the space-time predictor computation.
Test case was Euler equations in 3D with p=5 polynomials and a Sod shock tube scenario.We found that the min/max computation (in ExaHyPE) can currently be by a factor 10 more
expensive than the space-time predictor computation.
Test case was Euler equations in 3D with p=5 polynomials and a Sod shock tube scenario.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/177Batching required for LTS and ExaHyPE's limiter-based refinement2017-09-04T14:16:41+02:00Ghost UserBatching required for LTS and ExaHyPE's limiter-based refinementLimiting ADER-DG in ExaHyPE
---------------------------
In ExaHyPE, we do not consider adaptive refinement for the Finite Volumes (FV)
solver.
We thus only use FV on the finest level of the adaptive mesh
if we employ a limiting ADER-DG ...Limiting ADER-DG in ExaHyPE
---------------------------
In ExaHyPE, we do not consider adaptive refinement for the Finite Volumes (FV)
solver.
We thus only use FV on the finest level of the adaptive mesh
if we employ a limiting ADER-DG solver.
If a limiting ADER-DG solver detects a shock, i.e. a cell where we need to
limit non-physical oscillations, we refine it down to
the finest adaptive mesh level.
And we further refine its neighbours down to the finest mesh level.
Local Time Stepping
-------------------
TBC
Local Time Stepping plus limiting ADER-DG in ExaHyPE
-----------------------------------------------------
It is possible that a cell is marked as troubled during the
local time stepping. This will require potentially
more refinement around the cell, or to refine the cell itself.
The newly refined cells might not have done any time stepping
at all during the current LTS batch since
their parents stem from a coarser level.
They lag behind in time.
The question is what to do in those scenarios.
Batching
--------
One idea is to consider the number of local time steps to run as a batch.
We remember the solution before a batch starts.
In case (limiter-based) refinement is triggered, we memorise the cells to refine,
perform a rollback to the memorised solution.
Afterwards, we refine the memorised cells and run the batch again.
It can happen multiple times that we have to rerun a batch.
On the other hand, we ensure that our grid is always tracking a shock correctly.
Further techniques
------------------
On the expense of computational cost, we could refine the mesh generously (according to the restricted limiter status)
This would reduce the number of batch reruns.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/173LimitingADERDGSolver with limiter layers = 1 crashes in certain scenarios2017-08-29T18:48:26+02:00Ghost UserLimitingADERDGSolver with limiter layers = 1 crashes in certain scenarios* ~~I might need to stop merging the limiter status on-the-fly if
there is only 1 limiter layer.~~
* Does also affect helper-layers =2 runs.
* The crash is prevented by choosing a stricter dmp-relaxation-parameter.
It seems to be a ...* ~~I might need to stop merging the limiter status on-the-fly if
there is only 1 limiter layer.~~
* Does also affect helper-layers =2 runs.
* The crash is prevented by choosing a stricter dmp-relaxation-parameter.
It seems to be a numerical issue with the MUSCL-Hancock scheme.
* I will check if the issue does not appear if I use the Godunov scheme again.
https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/172High time outs required during mesh refinement iterations2017-08-25T11:24:13+02:00Ghost UserHigh time outs required during mesh refinement iterationsI could get a p=9 243^3 Euler scenario run (64x14 ranks) but only if
I set the timeout to a large value of 360 sec.
Issue presumed to be related to imposing initial conditions
on-the-fly during the grid setup iterations.
This would exp...I could get a p=9 243^3 Euler scenario run (64x14 ranks) but only if
I set the timeout to a large value of 360 sec.
Issue presumed to be related to imposing initial conditions
on-the-fly during the grid setup iterations.
This would explain the worse behaviour in 3d as well as
for the limiting ADER-DG solver.
For the latter, also the min and max is computed on-the-fly.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/165Minimise limiter status based halo refinement2017-08-15T16:59:19+02:00Ghost UserMinimise limiter status based halo refinementIf the a-posteriori troubled cell indicators indicate a troubled cell, we refine
this cell down to the finest mesh level specified by the user.
I further have to ensure that I can place helper cell layers around the troubled cell
also o...If the a-posteriori troubled cell indicators indicate a troubled cell, we refine
this cell down to the finest mesh level specified by the user.
I further have to ensure that I can place helper cell layers around the troubled cell
also on the finest mesh level. Thus, I need some halo refinement.
Currently, I refine all neighbours of a cell with limiter status 1 and 2 in order to ensure
that the diagonal neighbours are refined as well.
In principle, I could however refine the cells with have a limiter status of 1 and
the cells which have two neighbours with a limiter status 1.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/164Extrapolate space-time polynomials and wrap boundary condition imposition in ...2017-07-12T20:24:40+02:00Ghost UserExtrapolate space-time polynomials and wrap boundary condition imposition in time-integralThis will further be a first step for local time steppingThis will further be a first step for local time steppinghttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/163Have a maximum-timestep-size in the spec file2017-07-12T17:49:05+02:00Ghost UserHave a maximum-timestep-size in the spec fileThis value can then be used to prescribe a time step size as long.
As the solver does not require a smaller one at least.This value can then be used to prescribe a time step size as long.
As the solver does not require a smaller one at least.