ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2018-09-21T12:07:11+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/253Optimised kernels and AMR application do not work together2018-09-21T12:07:11+02:00Ghost UserOptimised kernels and AMR application do not work togetherWhen I run the Euler_ADERDG application with an adaptive grid and the optimised kernels,
I compute a time step size of approx. zero after the first time step. The simulation terminates.
The generic kernels do thousands of time steps with...When I run the Euler_ADERDG application with an adaptive grid and the optimised kernels,
I compute a time step size of approx. zero after the first time step. The simulation terminates.
The generic kernels do thousands of time steps without any complaints for the same problem.
The optimised kernels work without problems for the same application when uniform grids are used.
Files
* [specification file (text file)](/uploads/d25264d843ed7f543cf1a3b4e01a6d26/temp)
* [output generic kernels (text file)](/uploads/10715a9248f96b814909c75a5b333fbc/temp)
* [output optimised kernels (text file)](/uploads/a87857d5bf68669a97085bf8450db026/temp)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/237Toolkit extensibility threatened by java method size limit2018-09-10T19:37:48+02:00Ghost UserToolkit extensibility threatened by java method size limitProblem description
-------------------
When adding a few more tokens to the `exahype.grammar` file, the ExaHyPE Toolkit does not compile
anymore. The compilation stops with the following error:
```
javac -cp ../lib/commons-cli.jar -sou...Problem description
-------------------
When adding a few more tokens to the `exahype.grammar` file, the ExaHyPE Toolkit does not compile
anymore. The compilation stops with the following error:
```
javac -cp ../lib/commons-cli.jar -sourcepath . eu/exahype/GenerateSolverRegistration.java
eu/exahype/parser/Parser.java:104: error: code too large
public Start parse() throws ParserException, LexerException, IOException
^
1 error
```
Function `parse()` in file `eu/exahype/parser/Parser.java` contains a large `switch`-`case` statement
considering nearly 3000 cases and has more than 17000 lines of code.
`Parser.java` is unfortunately autogenerated by SableCC.
Further reading:
* https://dzone.com/articles/method-size-limit-java
* https://stackoverflow.com/a/17422590
The Typical *Let's rewrite everything!* Proposal
------------------------------------------------
From my point of view, above issue is just another reason why we should abandon SableCC grammars and switch to a proper data serialisation
format like JSON or YAML (internally). Validation can be performed via JSON schemata. It would be still possible
to keep our current specification file format. We would just introduce a precompilation step.
Additionally, we could consider to rewrite the toolkit in python. A lot is realised via template files anyway and
the code generator for the optimised kernels is written in python, too.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/196Fix musclhancock scheme for certain patch sizes2018-02-22T09:45:39+01:00Ghost UserFix musclhancock scheme for certain patch sizesFor me, for certain patch sizes, our 2nd order FV scheme in ExaHyPE (musclhancock) fails. Godunov runs fine. This has to be debugged (it certainly depends on the patch size: Some work, some not).
2nd order is crucial for some applicatio...For me, for certain patch sizes, our 2nd order FV scheme in ExaHyPE (musclhancock) fails. Godunov runs fine. This has to be debugged (it certainly depends on the patch size: Some work, some not).
2nd order is crucial for some applications (GRMHD,CCZ4).
I will do this, ticket just for book keeping.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/153Constants in specfiles2018-09-10T19:42:06+02:00Ghost UserConstants in specfilesI have too much constants that a specfile syntax
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size...I have too much constants that a specfile syntax
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = initial_data:tovstar,boundary_x_lower:reflective,boundary_y_lower:reflective,boundary_z_upper:outgoing,tovstar-mass:1.234,tovstar-rl-ratio:2.345
```
would make sense. Tobias thinks in such a case a user would do something like
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = configuration-file:foobar.txt
```
and outsource the configuration in a language the user likes. However, this breaks with the idea of a single specfile for a single run. Therefore, I see two options
## Add a DATA section after the specfile
This is what many script languages do, for instance perl ([the DATA syntax in perl](https://stackoverflow.com/questions/13463509/the-data-syntax-in-perl)). The idea is just that the parsers ignore what goes after the end of the specfile (ie. the line containing `end exahype-project`). Users could dump there any content in their favourite language. I would vote for this as it is super easy to implement, allows file concatenation and flexibility.
## Allow user constant section
We could also just allow users to do something like
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = parameters:appended
limiter-kernel const = generic::musclhancock
limiter-language const = C
dmp-observables = 2
dmp-relaxation-parameter = 1e-2
dmp-difference-scaling = 1e-3
steps-till-cured = 0
simulation-parameters
foo = bar
baz = bar
blo = bar
blu = bar
etc.
end simulation-parameters
plot vtk::Cartesian::vertices::limited::binary ConservedWriter
variables const = 19
time = 0.0
repeat = 0.00166667
output = ./vtk-output/conserved
end plot
...
```
This would go well with the specfile syntax. In order to implement, we need
* Such a section with any key-value pairs added to the grammar, so the toolkit does not complain
* Support in the `Parser.cpp` (which is not too hard to add)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/73ShuVortex convergence tests interpretation2018-06-15T15:13:43+02:00Ghost UserShuVortex convergence tests interpretationAt 28. Sept Michael Dumbser wrote about the convergence rates of the Euler ShuVortex simulation:
>
I think the convergence results are not bad at all. The "systematic artefacts" are not artefacts, but we clearly understand where they co...At 28. Sept Michael Dumbser wrote about the convergence rates of the Euler ShuVortex simulation:
>
I think the convergence results are not bad at all. The "systematic artefacts" are not artefacts, but we clearly understand where they come from and the code would be wrong if we could not see them :-) To get a clean and proper convergence table for Exahype without periodic boundary conditions, you must simulate the ShuVortex
>
1. only until a rather small final time, say t=0.5 or t=1.0. The vortex must not touch the boundary at all, and since the vortex is an exponential function,
the high order DG scheme will even see very small errors of the order 1e-7 or 1e-8, hence the Gaussian must really be perfectly flat on the boundary, well below this accuracy. Not only at the initial, but also at the final time. In numerical analysis, it is not common practice to report convergence order over simulation time. Usually, one reports the error in a certain norm (L1, L2, Linf) on a given mesh for a fixed output time, which satisfies all the necessary theoretical criteria for getting high order (sufficiently smooth solution). If convergence order drops due to boundary effects, at least one of the necessary criteria (regularity) is violated, so it is clear that no convergence at the expexted rate is observed.
>
2. If you want larger simulation times, you must increase the domain size (even bigger than the canonical [0,10]^2 domain, say [-10,20]^2), in order to make sure that
the Gaussian is perfectly flat on the boundary, up to the desired error threshold.
>
3. A nice test case which works for arbitrarily large times and without periodic boundaries is the large Amplitude Alfven wave for SRMHD. Olindo can send you the setup. The exact solution is a travelling sine wave, and if you impose the exact solution on the boundaries, you should be able to simulate the problem even without periodic boundaries and without any artefact.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/72MHD crashes after few timsteps2018-06-15T15:13:43+02:00Ghost UserMHD crashes after few timstepsThis was urgently raised last week by Michael Dumbser: The MHD AlfenWave is still crashing very quickly. We have to find the reason for that, otherwise there will be no convergence result next week.This was urgently raised last week by Michael Dumbser: The MHD AlfenWave is still crashing very quickly. We have to find the reason for that, otherwise there will be no convergence result next week.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/60Spec file parsing errors in comments2018-06-15T15:13:43+02:00Ghost UserSpec file parsing errors in commentsThis specification file does not compile:
```
....
optimisation
fuse-algorithmic-steps = on
fuse-algorithmic-steps-factor = 0.99
end optimisation
/*
Q0 = das skalare Feld "dens", die relativistische ruh...This specification file does not compile:
```
....
optimisation
fuse-algorithmic-steps = on
fuse-algorithmic-steps-factor = 0.99
end optimisation
/*
Q0 = das skalare Feld "dens", die relativistische ruhemasse,
(Q1,Q2,Q3) = den relativistischen Geschwindigkeitsvektor (Impuls),
Q4 = das skalare Feld der inneren Energie (Hydrodynamik),
(Q5,Q6,Q7) = das Magnetfeld (Vektorfeld, für SRHD=0).
Q8 = Die Divergenz des Magnetfelds, die verschwinden muss und ein Mass fuer die numerische Exaktheit ist
*/
solver ADER-DG MHDSolver
variables = 9
parameters = 0
order = 3
...
```
This is due to the comment. **Comments in the specification file are not working like comments but they are parsed**. The comment was actually added by Tobias himself in https://gitlab.lrz.de/gi26det/ExaHyPE/commit/3f7028f1989ce5367d92336a09bb25fc640eca43 and when doing this, the toolkit fails with the unhelpful message `IOException: "Pushback buffer overflow"`, without mentioning any line number or so.
This is a real drawback of the proprietary configuration file format, as already mentioned by Fabian in https://gitlab.lrz.de/gi26det/ExaHyPE/issues/56#note_16127. If we had instead a simple configuration format as INI, JSON, YAML or so, such errors would not occur and instead, we could have fail proof comments like `/* comment */`, `// comment` or `# comment`.