ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2018-09-05T14:23:33+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/243Toolkit2: Create .gitignore2018-09-05T14:23:33+02:00Ghost UserToolkit2: Create .gitignoreWe could think about such an option to let the toolkit create a `.gitignore` in the output directory. That could hold something like
```
Abstract*
KernelCalls*
README_generated.md
```
However, these files are not solver-name-dependent ...We could think about such an option to let the toolkit create a `.gitignore` in the output directory. That could hold something like
```
Abstract*
KernelCalls*
README_generated.md
```
However, these files are not solver-name-dependent and easy to track in the global `.gitignore`, too.
Would a local `.gitignore` have any features beyond?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/245Toolkit2: Allow users to share binaries, move them accross computers, etc.2019-03-21T10:47:08+01:00Ghost UserToolkit2: Allow users to share binaries, move them accross computers, etc.The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises p...The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises problems in certain use cases:
* The user shares his Executable to another user on the system/cluster but does not make the access permissions correctly for the Toolkit
* The user copies only the Executable to another machine but not the overall Code (especially not the Toolkit code)
* The user renames the path to his installation (probably when cleaning up his home directory) but wants to keep an ExaHyPE build working (obviously this is not possible)
We have no solution for all these use cases, but we should include checks in the C++ code to deal with them:
* Check whether `Path/to/Toolkit/toolkit.sh` exists, is readable and executablehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/239Toolkit2: Be consistent with interactivity2018-09-10T19:38:15+02:00Ghost UserToolkit2: Be consistent with interactivityThe toolkit.sh is blocking for user input if dependency problems occur. Will be fatal when called from Engine. Simple solution: Take --interactive etc flags into account.
Can fix that.The toolkit.sh is blocking for user input if dependency problems occur. Will be fatal when called from Engine. Simple solution: Take --interactive etc flags into account.
Can fix that.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/252Toolkit validation shows non-deterministic behaviour2018-09-21T11:30:46+02:00Ghost UserToolkit validation shows non-deterministic behaviourI discovered that the toolkit validation shows non-deterministic behaviour.
I use a specification file where I remove the 'cores' option which is required
in the 'shared_memory' section.
The validation does not complain in some runs but...I discovered that the toolkit validation shows non-deterministic behaviour.
I use a specification file where I remove the 'cores' option which is required
in the 'shared_memory' section.
The validation does not complain in some runs but fails correctly in other
runs.
1. It works the first time (it shouldn't as the 'shared_memory/core' is missing.
```
17:14 $ ../../../Toolkit/toolkit.sh -v -format=any ../Euler_ADERDG.exahype
controller.py:77(__init__):INFO
______ __ __ ____ ______
/ ____/ ______ _/ / / /_ __/ __ \/ ____/ *************************
/ __/ | |/_/ __ `/ /_/ / / / / /_/ / __/ The ExaHyPE Toolkit v2
/ /____> </ /_/ / __ / /_/ / ____/ /___ www.exahype.eu
/_____/_/|_|\__,_/_/ /_/\__, /_/ /_____/ Commit: 77efa02
/____/ *************************
This project has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 671698 (ExaHyPE).
Copyright (c) 2018, All rights reserved
ExaHyPE is based on the PDE framework Peano (www.peano-framework.org).
Released under the BSD 3 Open Source License.
controller.py:85(__init__):INFO Read input file /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG.exahype.
omni_reader.py:46(__init__):INFO 4 file formats registered: json,hjson,exahype-v1,mexa
omni_reader.py:156(read):INFO No specific file format requested, trying all available file formats in order.
omni_reader.py:124(read_omni):INFO Trying to read file format json
omni_reader.py:136(read_omni):INFO The input file is certainly not written in the format json as a ParserError occured: Expecting value: line 1 column 1 (char 0)
omni_reader.py:124(read_omni):INFO Trying to read file format hjson
omni_reader.py:130(read_omni):INFO Cannot check file format hjson because neccessary library is not installed. The missing library is: No module named 'hjson'
omni_reader.py:131(read_omni):INFO Will silently ignore this problem
omni_reader.py:124(read_omni):INFO Trying to read file format exahype-v1
specfile1_reader.py:521(read_lines):INFO Converting legacy specification file (95 lines) to INI file...
specfile1_reader.py:523(read_lines):INFO OK
specfile1_reader.py:532(read_lines):INFO Mapping INI structure to JSON input object...
specfile1_reader.py:534(read_lines):INFO OK
omni_reader.py:126(read_omni):INFO Success reading file format exahype-v1
directories.py:37(check):INFO Peano kernel path: /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/Peano ... ok
directories.py:37(check):INFO Peano kernel path: /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/Peano holds tarch ... ok
[...]
/Euler_ADERDG/Makefile'
controller.py:152(run):INFO please change into directory /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ApplicationExamples/Euler/Euler_ADERDG and type make
ensure that you set all environment variables before:
export COMPILER=GNU Select GNU compiler
export COMPILER=Intel Select Intel compiler (default)
[...]
export USE_IPO=on Compile using IPO for the solvers and kernels (only with Intel compilers)
If USE_IPO is not specified, it falls back to "off" (compilation without IPO).
If you run CSH, please replace "export ARG=VALUE" with "setenv ARG VALUE".
```
2. It fails the second time which is the correct behaviour:
```
✔ ~/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG [master|✚ 16…1135⚑ 58]
17:18 $ ../../../Toolkit/toolkit.sh -v -format=any ../Euler_ADERDG.exahype
rm: cannot remove ‘*.o’: No such file or directory
rm: cannot remove ‘cipofiles.mk’: No such file or directory
rm: cannot remove ‘ffiles.mk’: No such file or directory
rm: cannot remove ‘cfiles.mk’: No such file or directory
rm: cannot remove ‘kernels’: No such file or directory
controller.py:77(__init__):INFO
______ __ __ ____ ______
/ ____/ ______ _/ / / /_ __/ __ \/ ____/ *************************
/ __/ | |/_/ __ `/ /_/ / / / / /_/ / __/ The ExaHyPE Toolkit v2
/ /____> </ /_/ / __ / /_/ / ____/ /___ www.exahype.eu
/_____/_/|_|\__,_/_/ /_/\__, /_/ /_____/ Commit: 77efa02
/____/ *************************
This project has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 671698 (ExaHyPE).
Copyright (c) 2018, All rights reserved
ExaHyPE is based on the PDE framework Peano (www.peano-framework.org).
Released under the BSD 3 Open Source License.
controller.py:85(__init__):INFO Read input file /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG.exahype.
omni_reader.py:46(__init__):INFO 4 file formats registered: json,hjson,exahype-v1,mexa
omni_reader.py:156(read):INFO No specific file format requested, trying all available file formats in order.
omni_reader.py:124(read_omni):INFO Trying to read file format json
omni_reader.py:136(read_omni):INFO The input file is certainly not written in the format json as a ParserError occured: Expecting value: line 1 column 1 (char 0)
omni_reader.py:124(read_omni):INFO Trying to read file format hjson
omni_reader.py:130(read_omni):INFO Cannot check file format hjson because neccessary library is not installed. The missing library is: No module named 'hjson'
omni_reader.py:131(read_omni):INFO Will silently ignore this problem
omni_reader.py:124(read_omni):INFO Trying to read file format exahype-v1
specfile1_reader.py:521(read_lines):INFO Converting legacy specification file (95 lines) to INI file...
specfile1_reader.py:523(read_lines):INFO OK
specfile1_reader.py:532(read_lines):INFO Mapping INI structure to JSON input object...
specfile1_reader.py:534(read_lines):INFO OK
omni_reader.py:126(read_omni):INFO Success reading file format exahype-v1
controller.py:218(validateAndSetDefaults):ERROR Specification file does not hold a valid ExaHyPE specification, it did not pass the schema validation step. The error message is: 'cores' is a required property
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/88Toolkit should fail when python code generator fails2018-06-15T15:13:44+02:00Ghost UserToolkit should fail when python code generator failsSee [toolkit.log](/uploads/ae5aac96264410fadd50bcdc997db2a7/toolkit.log): When invoking an external command fails, java should also fail.See [toolkit.log](/uploads/ae5aac96264410fadd50bcdc997db2a7/toolkit.log): When invoking an external command fails, java should also fail.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/209Toolkit should accept command line arguments for finetuning2019-04-15T12:40:31+02:00Ghost UserToolkit should accept command line arguments for finetuning> **Note:** This is a **minor feature suggestion**. Something which should be done on the **long term** to improve the users daily life. It is **not important right now**
Currently, the toolkit has a way of overwriting some files always...> **Note:** This is a **minor feature suggestion**. Something which should be done on the **long term** to improve the users daily life. It is **not important right now**
Currently, the toolkit has a way of overwriting some files always while creating some files only if they do not yet exist.
Sometimes, especially when the API or toolkit changes, one needs to recreate everything. The typical workflow is then to call `rm Abstract*Solver* KernelCalls*`. Instead, it would be nice if the toolkit supports some option `--overwrite` or similar to always recreate the files. It could also offer an option `--compare` to print whether generated files differ from existing files.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/93Toolkit compilation fails with "TTokenCoupleSolvers.java:30: error: cannot fi...2018-06-15T15:13:43+02:00Ghost UserToolkit compilation fails with "TTokenCoupleSolvers.java:30: error: cannot find symbol"When invoking `make all` or `./build.sh` in the Toolkit directory, an error occurs, ie.
```
javac -sourcepath . eu/exahype/node/TTokenCoupleSolvers.java
eu/exahype/node/TTokenCoupleSolvers.java:30: error: cannot find symbol
((A...When invoking `make all` or `./build.sh` in the Toolkit directory, an error occurs, ie.
```
javac -sourcepath . eu/exahype/node/TTokenCoupleSolvers.java
eu/exahype/node/TTokenCoupleSolvers.java:30: error: cannot find symbol
((Analysis) sw).caseTTokenCoupleSolvers(this);
^
symbol: method caseTTokenCoupleSolvers(TTokenCoupleSolvers)
location: interface Analysis
```
cf.: [toolkit-build.log](/uploads/c8e2870a7b0d9adb8bbed50cc9490a71/toolkit-build.log)
Reported to Tobias at 2016-12-23:
> thanks for the present! Unfortunately, the toolkit no more compiles
> for me. Seems to be a problem with the code generated by SableCC. I'm
> compiling with OpenJDK javac 1.7.0.
Answer:
> probier mal ein make clean. Das ist kein Java-spezifischer Fehler. Das
> ist was Dependencies-meassiges. Kannst auch mal das nodes Verzeichnis
> loeschen. Das war bei mir mal ein Problem,
Make clean doesn't help.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/124Toolkit - Move from replaceAll to true template engine2018-09-21T12:09:36+02:00Jean-Matthieu GallardToolkit - Move from replaceAll to true template engineThe templates used by the Toolkit start to require some logic. For example the NamingScheme tag requires to expand a Set to multiple lines.
Currently we put that logic in the java class and use a replaceAll but it would be better to put...The templates used by the Toolkit start to require some logic. For example the NamingScheme tag requires to expand a Set to multiple lines.
Currently we put that logic in the java class and use a replaceAll but it would be better to put that logic in the template itself using a true template engine. For example the NamingScheme tag would be replace with a foreach loop that expand the Set in the template. Also this would help factorizing the code by putting common tag and their value into a more global context set for the template engine
Switching should be simple as we are already using standard template tags for our variable.
Ofc the template engine needs to be light and fully available in a jar or any format requiring no installation to avoid adding new dependencies. For example https://github.com/HubSpot/jinjava or http://jtwig.org/
This is a "nice to have" feature so we should do it when we have more time.
Concerned: @di25cox , @gi26det , @svenk , @ga96nuvJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/137The GRMHD, SRMHD, and EulerFlow error plotters seem to not work correctly (Th...2018-06-15T15:13:42+02:00Ghost UserThe GRMHD, SRMHD, and EulerFlow error plotters seem to not work correctly (The ADERDG correctness is broken (GRMHD AccretionDisk 2D/3D) )The errors in the AccretionDisk3D, GRMHD application, looked very good (`max mesh ref = 0.5` on a domain `0.0 .. 2.0` in x,y,z) one week ago:
```
sven@nils:~/numrel/exahype/Engine-ExaHyPE/ApplicationExamples/GRMHD$ cat output/error-r...The errors in the AccretionDisk3D, GRMHD application, looked very good (`max mesh ref = 0.5` on a domain `0.0 .. 2.0` in x,y,z) one week ago:
```
sven@nils:~/numrel/exahype/Engine-ExaHyPE/ApplicationExamples/GRMHD$ cat output/error-rho.asc
plotindex time l1norm l2norm max min avg
1 0.000000e+00 5.669120e-12 7.324244e-11 3.750836e-09 1.676159e-13 8.555365e-13
2 1.333333e-02 1.852645e-06 2.236011e-06 3.977681e-05 2.178258e-13 2.698931e-07
3 2.000000e-02 2.860199e-06 3.615806e-06 6.110038e-05 2.300382e-13 4.156812e-07
4 2.666667e-02 3.469631e-06 4.545670e-06 7.338015e-05 2.300382e-13 5.023163e-07
5 3.333333e-02 3.877169e-06 5.212832e-06 8.077556e-05 2.300382e-13 5.578673e-07
6 4.000000e-02 4.180962e-06 5.713450e-06 8.532972e-05 2.300382e-13 5.966567e-07
7 4.666667e-02 4.433994e-06 6.101790e-06 8.813653e-05 2.300382e-13 6.268654e-07
8 5.333333e-02 4.662388e-06 6.411162e-06 8.981804e-05 2.300382e-13 6.524981e-07
9 6.000000e-02 4.880226e-06 6.663393e-06 9.074876e-05 2.300382e-13 6.756477e-07
```
The solution was stationary and the errors should always stay in the same order of magnitude. They did.
Now, we experience something different *both in 2D and 3D ADERDG* and probably also in the FV scheme (but this could have another source).
This ticket shall track these problems.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/83Testing MHD by solving with Two kernels at the same time2018-06-15T15:13:43+02:00Ghost UserTesting MHD by solving with Two kernels at the same timeA proposal by Vasco
2016-11-21 10:16 GMT+01:00 Vasco Varduhn <varduhn@tum.de>:
>
> Hi,
>
>
>
> I had an idea in for testing the C kernels i.e. comparing them with the FORTRAN kernels. In the MySomethingSolver_generated.cpp are the ca...A proposal by Vasco
2016-11-21 10:16 GMT+01:00 Vasco Varduhn <varduhn@tum.de>:
>
> Hi,
>
>
>
> I had an idea in for testing the C kernels i.e. comparing them with the FORTRAN kernels. In the MySomethingSolver_generated.cpp are the calls to the kernels.
>
>
>
> In there you could copy the input data to additional arrays, call both the C and the FORTRAN kernels on the different copies, and then compare the output data entry by entry and throw an error, if the values differ (too much).
>
>
>
> This would allow for an element-wise comparison of all kernels.
>
>
>
> Best,
>
> Vasco
>
>
As a followup from gi26det/ExaHyPE#72https://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/117Support material parameters2019-09-20T15:46:49+02:00Ghost UserSupport material parametersTODO:
* ~~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 swit...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.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/160Support a Tecplot-compatible output format2018-06-15T15:13:42+02:00Ghost UserSupport a Tecplot-compatible output formatThis is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common ...This is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common denominator VTK. Instead, a number of file formats are supported in-house:
```
• CGNS Loader
• DEM Loader
• DXF Loader
• EnSight Loader
• Excel Loader
• FEA Loader
• FLOW-3D Loader
• FLUENT Loader
• General Text Loader
• HDF Loader
• HDF5 Loader
• Kiva Loader
• PLOT3D Loader
• PLY Loader
• Tecplot-Format Loader
• Text Spreadsheet Loader
```
See also: http://home.ustc.edu.cn/~cbq/360_data_format_guide.pdf with meaningful pictures as this one:
![beautiful-tecplot-nodal-values](/uploads/c4ea3adb5281c5c2f713199792c50f53/beautiful-tecplot-nodal-values.png)
Instead of Trentos code, we don't want to implement a writer which writes only the tecplot-specific format but instead use some of these widespread formats, for instance "FLUENT" or so.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/146Static AMR SharedMemory-Memory Leaks2018-06-15T15:13:43+02:00Ghost UserStatic AMR SharedMemory-Memory LeaksI observe
* a very slightly increasing memory consumption
of the ADERDGSolver
![memory_leak_slow](/uploads/edfb85be1570b74f2da985597a17f76b/memory_leak_slow.png)
* plus an increase of the memory consumption of the ADERDGSo...I observe
* a very slightly increasing memory consumption
of the ADERDGSolver
![memory_leak_slow](/uploads/edfb85be1570b74f2da985597a17f76b/memory_leak_slow.png)
* plus an increase of the memory consumption of the ADERDGSolver
by large chunks.
![memory_leak_fast](/uploads/9d464f1c3b545dbe93a2beeb2ab94bd6/memory_leak_fast.png)
Both can probably be traced back to a problem with allocating
deallocating temporary variables in the mappings.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/228stableTimeStepSize kernels should return maximum eigenvalue for (classical) l...2018-06-14T16:10:38+02:00Ghost UserstableTimeStepSize kernels should return maximum eigenvalue for (classical) local time steppingIn general, we cannot associate the smallest time step size with the finest mesh
level as there might be larger eigenvalues present on coarser mesh levels.
This is an issue for local time stepping where you scale the smallest time
step ...In general, we cannot associate the smallest time step size with the finest mesh
level as there might be larger eigenvalues present on coarser mesh levels.
This is an issue for local time stepping where you scale the smallest time
step size by a factor k (k=3 in Peano) with decreasing mesh level.
The kernels should thus return the maximum eigenvalue, too, or only the maximum eigenvalue.
The minimum local time step size would then be computed according to:
```
dt_min = CFL * max_{over all cells} lambda / min_{over all cells} cellSize
```
which is different to what we are currently doing for global time stepping:
```
dt_min = CFL * min_{over all cells} ( lambda / cellSize )
```
The ADERDGSolver superclass would then decide which minimisation to
perform.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/179Split TimeStepSizeComputation and merge parts with SolutionUpdate and LocalRe...2017-10-04T17:11:38+02:00Ghost UserSplit TimeStepSizeComputation and merge parts with SolutionUpdate and LocalRecomputation- TimeStepSizeComputation will be reduced to a simple
time step size computation function.
SolutionUpdate and LocalRecomputation will also
compute a time step size and will further advance in time.
This will reduce logic.
- Next step wi...- TimeStepSizeComputation will be reduced to a simple
time step size computation function.
SolutionUpdate and LocalRecomputation will also
compute a time step size and will further advance in time.
This will reduce logic.
- Next step will be a fusion of multiple algorithmic phases of the
ADER-DG and Limiting ADER-DG schemes in a single solver function.
This will hopefully make it easier to optimise for the compiler
and easier for the processor cache to decide what to hold or drop.
- We might be able to get rid of mapping FusedTimeSteppingInitialisation
with the above split.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/271Specification File Defaults in C++ Parser2019-05-08T13:41:02+02:00Ghost UserSpecification File Defaults in C++ ParserWe have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema....We have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema.
**Edit 2:**
There is now also a C/C++ header-only library for
JSON file validation.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/116Specfile Constants don't accept strings2018-06-15T15:13:43+02:00Ghost UserSpecfile Constants don't accept stringsWhen running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maxim...When running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maximum-mesh-size = 0.9
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
limiter-kernel const = generic::Godunov
limiter-language const = C
dmp-relaxation-parameter = 0.0001
dmp-difference-scaling = 0.001
constants = foo:bar
...
```
where I want the variable `foo` to set the String value `bar`, the parser complaints:
```
ERROR: eu.exahype.parser.ParserException: [70,42] expecting: float number
```
It also doesn't accept a string (`foo:"bar"`):
```
ERROR: eu.exahype.lexer.LexerException: [70,42] Unknown token: "
```
In our applications, the majority of parameters are strings, next to boolean values.
I rank this ticket *Minor* as constants have never worked for me (always issues with the parser #44) and I stick to environment variables and command line arguments.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`.