ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2019-09-20T15:46:49+02:00https://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/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/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/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/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/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/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/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/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/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/242Toolkit2: Fix old merge2019-03-21T10:46:28+01:00Ghost UserToolkit2: Fix old mergehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix though):
* Make sure you are using `ValueError` instead of `JSONDecodeError(ValueError)`.
Otherwise, the code requires python3 version>=3.5.0.
This is a typical error message you get:
```
controller.py:215(getSpec):ERROR Could not read specification file '../Euler_ADERDG.exahype': 'module' object has no attribute 'JSONDecodeError'
```
* Make sure `mexa.py` is python3.
I regex-replaced
`print (".+"\s*(%\s*\(.+\))?)$` with `print(\1)`https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/247Toolkit2: Make subprocess invocation of ExaHyPE main code optional2018-09-06T15:37:41+02:00Ghost UserToolkit2: Make subprocess invocation of ExaHyPE main code optionalSome people might not like the idea that the ExaHyPE code calls the Toolkit in order to (pre)parse specification files.
We should offer a specfile option within the specfiles to allow to generate code which does not calls a subprocess b...Some people might not like the idea that the ExaHyPE code calls the Toolkit in order to (pre)parse specification files.
We should offer a specfile option within the specfiles to allow to generate code which does not calls a subprocess but instead expects the input to be JSON.
This could be seen as advance hotfix when people report problems in complex MPI environments.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/238Toolkit2: OmniReader needs fix2018-08-14T15:56:04+02:00Ghost UserToolkit2: OmniReader needs fixThe current "Omni" specfile reader fails more or less silently if no reader had success. Instead, it should then choose one mandatory reader by the filename extension of the read-in-file. Otherwise users won't be able to debug broken spe...The current "Omni" specfile reader fails more or less silently if no reader had success. Instead, it should then choose one mandatory reader by the filename extension of the read-in-file. Otherwise users won't be able to debug broken specfiles.
Easy task, will do so today.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/274Toolkit: add flux limiter choice to FV solvers2019-03-20T09:31:43+01:00Ghost UserToolkit: add flux limiter choice to FV solversThis is basically low priority because we have a working solution on the [minmod branch](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/minmod): A replacement of the `minmod` flux limiter in the 2nd order FV scheme with something more...This is basically low priority because we have a working solution on the [minmod branch](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/minmod): A replacement of the `minmod` flux limiter in the 2nd order FV scheme with something more sophisticated.
However, users need to be able to choose which flux limiter they want to have with a FV solver. Therefore, the task of this issue is the integration into the ExaHyPE options language, i.e. implement what is discussed in the comments of https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/bc9063c5d8dc9ccb77eae346b00ff8f676808353:
> Thanks for the comment, @domcha. I think the way to go is to implement the *flux limiter* as a choice in the FV solver section in the toolkit, and to call a `solver` method right in the `kernels::finitevolumes::musclhancock::c::solutionUpdate` in place of the former `minmod` function. Choices would be then: `minmod`, `koren`, `user-defined`, where the latter creates a function stub in the generated user FV solver. Toolkit code generation as usual.
>
> I will implement this in a seperate feature branch and merge it then into various branches (such as `master`, as well as Lukes current working branch, i.e. the `minmod` branch).
>
> One principal thing is that this function is scalar, while it probably should be vectorized. That is easily possible with `inline` functions, but not any more with `user-defined` ones. But I don't think there is an urgent need for `user-defined` anyway. Maybe we can just offer a choice. Adding another one should then be an easy task.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/108Toolkit: Parser errors with faulty specfile2018-06-15T15:13:43+02:00Ghost UserToolkit: Parser errors with faulty specfileSo the specfile introduced new attributes (properties, or however you call them) and the first what happens is that the toolkit does not run any more with old specfiles. Today: Trying to parse [SRMHD.exahype](/uploads/02379c4f0485dad9d1a...So the specfile introduced new attributes (properties, or however you call them) and the first what happens is that the toolkit does not run any more with old specfiles. Today: Trying to parse [SRMHD.exahype](/uploads/02379c4f0485dad9d1a69748d0ca7445/SRMHD.exahype) as it is in the [current](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/3c8a41ad41a55cab990b0b452fa3cc6e0369b8da) repository:
```
ERROR: eu.exahype.parser.ParserException: [66,5] expecting: 'buffer-size'
```
I don't get this error message. If you open the [SRMHD.exahype](/uploads/02379c4f0485dad9d1a69748d0ca7445/SRMHD.exahype) there is nothing happening at this line.
So I tried out:
* Inserting the new `log-file = mylogfile.log` - didnt change a thing
* Inserting `variables = rho:1,j:3,E:1,B:3,damping:1` - didnt change a thing
* Commenting out `/* constants = {initialdata:alfven} */` gave me this error : ```ERROR: eu.exahype.lexer.LexerException: [61,41] Unknown token: *``` **WHY THE HELL CAN'T I JUST COMMENT OUT STUFF**??
* It turned out that I had to **REMOVE** the constants to get the toolkit running throught. **COMMENTING OUT IS NOT ENOUGH. WHY?**https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/259TOV Perturbations2019-04-15T12:33:18+02:00Ghost UserTOV Perturbations*This is an old textual note which I digitize here because I throw the textual one away. Has to be sorted in accordingly*
Plan from an old coding week:
* Trento: Artificial viscosity
* Frankfurt: Perturbed TOV, with THC, FIL
Perturb...*This is an old textual note which I digitize here because I throw the textual one away. Has to be sorted in accordingly*
Plan from an old coding week:
* Trento: Artificial viscosity
* Frankfurt: Perturbed TOV, with THC, FIL
Perturbations:
1. `p = alpha * p_0`
2. `rho = rho_0 * (1 + alpha * cos(2pi r/R))`
Trento codes:
* Tractor: AMR-3D (=all features, but slow)
* Ferrari: ADER-DG (=prototype, clean, vectorized, fast, but only unigrid and no limiter)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/68Treatment of ExternalLibraries and dependencies2018-06-15T15:13:43+02:00Ghost UserTreatment of ExternalLibraries and dependenciesAt the branch `nonconservative` (for the nonconservative Z4 formulation which requires Kernel modifications) I introduced a standalone ID code by using *git submodules*, cf. https://gitlab.lrz.de/gi26det/ExaHyPE/tree/nonconservative/Code...At the branch `nonconservative` (for the nonconservative Z4 formulation which requires Kernel modifications) I introduced a standalone ID code by using *git submodules*, cf. https://gitlab.lrz.de/gi26det/ExaHyPE/tree/nonconservative/Code/ExternalLibraries
We will quickly get more external dependencies at this place. They will all introduce Makefile changes, ie. as in the Makefile at https://gitlab.lrz.de/gi26det/ExaHyPE/blob/4af8a855a1b15ea795ec1d94365421ab0ac4da84/Code/Applications/Z4/Makefile
```
# This is to include the dependency to GSL, needed for the TwoPuncture code
PROJECT_CFLAGS+=-I../../ExternalLibraries/TwoPunctures/libtwopunctures
PROJECT_LFLAGS+=../../ExternalLibraries/TwoPunctures/libtwopunctures/libtwopunctures.a -lgsl -lgslcblas -lm
```
There should be a better method, especially because the Makefile will be overwritten everytime I run the toolkit on the application.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/186Turn mapping events off on coarse levels2019-09-20T15:46:32+02:00Ghost UserTurn mapping events off on coarse levels* We basically will go from here:
```
peano::MappingSpecification
exahype::mappings::XYZ::enterCellSpecification(int level) const {
return peano::MappingSpecification(
peano::MappingSpecification::WholeTree,
peano::...* We basically will go from here:
```
peano::MappingSpecification
exahype::mappings::XYZ::enterCellSpecification(int level) const {
return peano::MappingSpecification(
peano::MappingSpecification::WholeTree,
peano::MappingSpecification::RunConcurrentlyOnFineGrid,true);
}
```
To here:
```
peano::MappingSpecification
exahype::mappings::XYZ::enterCellSpecification(int level) const {
if (level < exahype::solvers::getCoarsestMeshLevelOfAllSolvers()) {
return peano::MappingSpecification(
peano::MappingSpecification::Nop,
peano::MappingSpecification::RunConcurrentlyOnFineGrid,true);
}
return peano::MappingSpecification(
peano::MappingSpecification::WholeTree,
peano::MappingSpecification::RunConcurrentlyOnFineGrid,true);
}
```
* Second, we should set the alterState bool only to true in mappings where this is necessary, i.e.,
where we perform reductions or use temporary variables.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/283Use ADER CFL Correction Factors When Determining FV Patch Resolution2019-07-09T15:18:48+02:00Ghost UserUse ADER CFL Correction Factors When Determining FV Patch ResolutionThe ADER-DG time step size does not only depend on the DG CFL number that
scales with ``1/(2*N+1)`` but by an additional order-dependent correction factor ``C_ADER(N)``.
For order 5, e.g., this factor is roughly 0.5.
We currently use 2*...The ADER-DG time step size does not only depend on the DG CFL number that
scales with ``1/(2*N+1)`` but by an additional order-dependent correction factor ``C_ADER(N)``.
For order 5, e.g., this factor is roughly 0.5.
We currently use 2*N+1 FV cells per FV patch in our implementation of the a posteriori
limiting ADER-DG method. The motivation is to match the time step size
of the coupled ADER-DG and the FV scheme.
This does not take the correction factor into account, i.e. we add unneccessary
numerical dissipation as we use unnecessary small time step sizes in the FV cells.
Using the same ADER-DG time step size, we can increase the FV cell sizes by
a factor ``1/C_ADER(N)``. For order 5, e.g., we can double the size of the FV patches.
The following table corrects the patch sizes. I round down to not go below the ADER-DG time step size with
the FV time step sizes.
| Order N | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|-------------------------------------|---------|--------|--------|--------|--------|---------|---------|---------|---------|---------|
| C_ADER | 100.0 % | 99.0 % | 85.0 % | 70.0 % | 62.1 % | 49.5 % | 49.4 % | 45.0 % | 34.0 % | 28.5 % |
| Patch Scaling | 1.00 | 1.01 | 1.18 | 1.43 | 1.61 | 2.02 | 2.02 | 2.22 | 2.94 | 3.51 |
| Corr. Patch Size (Orig. Patch Size) | 1 | 3 | 5 | 10 (7) | 14 (9) | 22 (11) | 26 (13) | 33 (15) | 50 (17) | 66 (19) |
Tasks
-----
Proposed switch "Limiting-ADER-DG" solver specification:
``"patch_size" : ("original" | "max" | number)``
- ``max`` would look up the corrected patch size in a lookup table.
- ``original`` would use the original 2*order+1.
- ``number`` would use a user prescribed number. Control code must
check if the FV time step size is smaller or equal to the ADER-DG time step size.
Otherwise, an error must be printed out **OR** the ADER-DG method's CFL condition must be adjusted.
If a number is specified, then the ADER-DG to FV projectors have to be constructed manually.
For "max" and "original", they can be precomputed once.
* [x] Decide if a generic implementation of the patch size feasible or if the corrected patch sizes should be hardcoded?.
**A:** *Eventually both but first the hardcoded versions.*
* [x] Modify toolkit's solver controllers and templates:
* [x] ``exahype-specfile.schema.json``: Extend ``patch_size`` option in spec file schema
* [x] ``exahype/toolkit/solverController.py``: Take ``patch_size`` parameter into account.
Found issue: Defaults are not set.
* [x] Generic kernels:
* [x] Check that the CFL factor is picked up properly in the ADER-DG stableTimeStepSize kernel
* [x] ``GenericLimiterSolver(Header|Implementation).template``:
* [x] Update arguments passed to limiter kernels
* [x] Allocate Limiter projection matrices
* Dimensions:
* ``uh2lim[n] = new double[basisSize*basisSizeLim]();``
* ``uh2lob[n] = new double[basisSize*basisSize]();``
* ``lim2uh[n] = new double[basisSizeLim*basisSize]();``
* [x] Look up the FV to DG least-squares projection
* Main reference: M. Dumbser et al., *A posteriori subcell limiting of the discontinuous Galerkin finite element method for hyperbolic conservation laws*, Journal of Computational Physics, vol. 278, pp. 47–75, Dec. 2014.
* Least-squares reference: M. Dumbser and M. Käser, *Arbitrary high order non-oscillatory finite volume schemes on unstructured meshes for linear hyperbolic systems*, Journal of Computational Physics, vol. 221, no. 2, pp. 693–723, Feb. 2007.
* Objective function is
```math
\min_{u_h} \| u_h(x) - v_h(x) \|_{L^2(K)} = ([A] \{u\} - \{v\}) \cdot ([A] \{u\} - \{v\})
```
s.t. mass conservation constraint. $`[A]`$ is the DG to FV projection matrix. The objective function evaluates the DG solution $`u_h`$ at the FV cell centers $`v_h`$.
* Mass conservation constraint:
```math
\int_K u_h(x) dx = \int_K v_h(x)\,\text{d}x
```
```math
\sum_i u_i \int_{\bar K} \bar\phi_i (\bar x) \text{d}\bar x =
\sum_j v_j \cdot \frac{\bar V}{\bar K}
```
```math
\sum_i u_i w_i =
\sum_j v_j \cdot \frac{1}{\text{volumes per patch}}
```
```math
[C] \{u\} = [R] \{v\}
```
Above steps exploited properties of DG basis functions (Gauss-Legendre support points).
* Constraint coupled via Lagrange multiplier. Updated objective function:
```math
f = ([A] \{u\} - \{v\}) \cdot ([A] \{u\} - \{v\}) + \lambda \cdot ([C] \{u\} - [R] \{v\})
```
*
* Optimality condition (degrees of freedom/parameters: $`\{u\}`$ and $`\lambda`$):
```math
\begin{pmatrix}
2 [A] [A] & -[C]\\
[C] & 0
\end{pmatrix}
\cdot
\begin{pmatrix}
\{u\}\\
\lambda
\end{pmatrix}
=
\begin{pmatrix}
2\,[A]\,\{v\}\\
[R]\,\{v\}
\end{pmatrix}
```
To obtain solution $`\{u\}`$ and Lagrange multipliers $`\lambda`$, the
equations must be inverted. $`C`$ is sparse due to the tensor product structure.
$`[A]`$ is dense. As each nodal DG DOF is associated with a basis functions,
the above procedure yields a FV to DG projector.
* I can reuse JM's existing code. Essential is that I replace $`[A]`$, which I do anyway.
Convenient.
* [x] ``kernels/limiter/generic/Limiter.(h|cpp)``: Update signatures to take limiter patch size into account
* [x] ``LimiterProjectionMatrices.(h|cpp)``: Do not use original functions anymore
* [x] Optimised kernels:
* [x] Check if changes are necessary in ``OptimisedLimiterSolver(Header|Implementation).template``
* [x] Make sure ``dg2fv``, ``fv2dg`` and ``nDofLim``, ``nDofLimPad``, ``getBasisSizeLimiter()`,
and ``getBasisSizeLimiterPadded()`` are defined and used correctly:
* [x] Usage:
* [x] CodeGenerator/codegenerator/templates/configurationParameters_cpph.template (20 matches)
* [x] CodeGenerator/codegenerator/templates/limiter_cpp.template (51 matches)
* [x] CodeGenerator/codegenerator/templates/Quadrature_cpp.template (2 matches)
* [x] Definition:
* [x] CodeGenerator/codegenerator/templates/controller.py (5 matches)
* [x] CodeGenerator/codegenerator/models/limiterModel.py (29 matches)
* [x] CodeGenerator/codegenerator/models/quadratureModel.py (4 matches)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/215User Defined plotters API: Pass the information from the specfile2019-04-15T12:36:16+02:00Ghost UserUser Defined plotters API: Pass the information from the specfileHow can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is so...How can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is something I can do :)