ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2017-09-04T14:16:41+02:00https://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/175Symbolic flux calculations reduce speed significantly2019-03-21T10:56:35+01:00Ghost UserSymbolic flux calculations reduce speed significantlyI just completed some Likwid performance measurements for the generic and optimised kernels.
For the optimised kernels, I tested a variant using "symbolic variables" in the
flux and eigenvalue computation and another variant using
classi...I just completed some Likwid performance measurements for the generic and optimised kernels.
For the optimised kernels, I tested a variant using "symbolic variables" in the
flux and eigenvalue computation and another variant using
classic array indexing (optimised-nonsymbolic).
The files are suffixed by a ".likwid.csv".
I further attached measured Peano adapter times
The files are suffixed by a ".csv".
Setup
--------
* Compressible Euler equations (Euler_Flow)
* pure ADER-DG scheme (no limiter)
* polynomial orders p=3,5,7,9;
regular 27^3 grid (3D)
* TBB threads=1,12,24.
* Intel icpc17 (USE_IPO=on).
* nonfused (3 algorithmic phases) vs. fused (a single pipelined algorithmic phase) ADER-DG implementation
* no predictor reruns did occur for the fused implementation
Preliminary Results
----------------------------
* Optimised kernels are faster than the generic ones (I kind of expected this 😉)
* Raw array access (optimised-nonsymbolic) is significantly faster than using the "symbolic variables"(optimised).
* Fused scheme pays off (as long as number of reruns is low; very interesting for linear PDEs (no reruns here))
Files
-----
[Euler_ADERDG-no-output-generic.csv](/uploads/f671c93a33e70c9549853f1f51518c9d/Euler_ADERDG-no-output-generic.csv)
[Euler_ADERDG-no-output-generic.likwid.csv](/uploads/0d52ad214f0b1d6cfae4d658a9997cb5/Euler_ADERDG-no-output-generic.likwid.csv)
[Euler_ADERDG-no-output-optimised.csv](/uploads/422288cdc222b1b250b3aad9e2ad73a1/Euler_ADERDG-no-output-optimised.csv)
[Euler_ADERDG-no-output-optimised-nonsymbolic.csv](/uploads/0f84240941230d4bc9f06c76b154396b/Euler_ADERDG-no-output-optimised-nonsymbolic.csv)
[Euler_ADERDG-no-output-optimised.likwid.csv](/uploads/135bd71c668ca0c4c4ee5b7988ea2f17/Euler_ADERDG-no-output-optimised.likwid.csv)
[Euler_ADERDG-no-output-optimised-nonsymbolic.likwid.csv](/uploads/7606eefe559499a1f6de62b5f33905d0/Euler_ADERDG-no-output-optimised-nonsymbolic.likwid.csv)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/169Do not impose initial conditions in every mesh refinement iteration2017-11-21T13:42:50+01:00Ghost UserDo not impose initial conditions in every mesh refinement iterationIt turned out that this is quite costly.
It might be responsible for time outs encountered during the
initial grid setup.
Min and max search:
--------------------
- This should be done once in FinaliseMeshRefinement
since we have a lar...It turned out that this is quite costly.
It might be responsible for time outs encountered during the
initial grid setup.
Min and max search:
--------------------
- This should be done once in FinaliseMeshRefinement
since we have a larger concurrency level here.
- We further should move around some of the behaviour of LocalRecomputation
into FinaliseMeshRefinement.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.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/145SegFault occurs if I turn conservative flux off2018-06-15T15:13:07+02:00Ghost UserSegFault occurs if I turn conservative flux offProject: DIM_LimitingADERDGProject: DIM_LimitingADERDGhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/129Access to neighbours for which kernels?2018-06-15T15:13:07+02:00Ghost UserAccess to neighbours for which kernels?Finite Volumes Solver:
- source; ex: bathymetry in SWEFinite Volumes Solver:
- source; ex: bathymetry in SWEhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/110Compression2018-06-15T15:13:07+02:00Ghost UserCompression## TODO
* ~~add "hint-size" to the relevant compression fields.~~
* support the Finite Volumes solver degrees of freedom## TODO
* ~~add "hint-size" to the relevant compression fields.~~
* support the Finite Volumes solver degrees of freedom