ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-01-18T10:27:26+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/260Some nonlinear behavior with MPI2019-01-18T10:27:26+01:00Ghost UserSome nonlinear behavior with MPII got some strange behavior when I try to run GPR on the new skylake i9 here in Trento. The application is the GPR one used with the GPR_2D.exahype spec file. The test is a travelling smooth shock and it runs with non static limiter and ...I got some strange behavior when I try to run GPR on the new skylake i9 here in Trento. The application is the GPR one used with the GPR_2D.exahype spec file. The test is a travelling smooth shock and it runs with non static limiter and AMR. I report some results we got:
2D 4 TBB 1MPI 1 AMR NoOpt ok in 177,54s
2D 4 TBB 1MPI 1 AMR Opt ok in 170,85s
2D 8 TBB 1MPI 1 AMR Opt ok in 145,24
2D 2 TBB 1MPI 1 AMR Opt ok in 292,18
2D 2 TBB 4MPI 1 AMR Opt do not work (issue in musclhancock)
2D 1 and 2 TBB 4MPI 1 AMR Opt using Godunov, do not work, it frozen in initialization and doesn't do anything
2D 1 TBB 4MPI 0 AMR NoOpt using Godunov, it explode
2D 1 TBB 1MPI 0 AMR NoOpt ok in 37,42s (every spawn optimization disabled)
2D 1 TBB 1MPI 1 AMR NoOpt ok in 219.433s (every spawn optimization disabled)
In summary it seems to work all the times we use 1 MPI, more than one seems to be in trouble.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/258Minfy JSON (filter out comments and son) before deserialisation2018-11-13T18:10:26+01:00Ghost UserMinfy JSON (filter out comments and son) before deserialisationThe JSON parser allows specifying a callback for this purpose:
```
/** [...]
@param[in] i input to read from
@param[in] cb a parser callback function of type @ref parser_callback_t
which is used to control the deseriali...The JSON parser allows specifying a callback for this purpose:
```
/** [...]
@param[in] i input to read from
@param[in] cb a parser callback function of type @ref parser_callback_t
which is used to control the deserialization by filtering unwanted values
(optional)
*/
static basic_json parse(detail::input_adapter&& i,
const parser_callback_t cb = nullptr,
const bool allow_exceptions = true)
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/251Ideas for new sweep features2018-11-13T18:01:05+01:00Ghost UserIdeas for new sweep features* The change to toolkit2 did change the set of compile-time parameters. I consider to
have a mandatory INI file parameter where the user specifies what parameter change requires a
rebuild of the application. This would however requi...* The change to toolkit2 did change the set of compile-time parameters. I consider to
have a mandatory INI file parameter where the user specifies what parameter change requires a
rebuild of the application. This would however require more care from the user's side.
* Have a plug-in point for parsers: The main functionality of sweep is spawning jobs for a parameter set and
then associating this parameter set with an output file. It then allows to parse the output file and
puts the result into CSV tables where the parameters are representing the key entries and the values parsed from
the output file the value entries of a row.
In theory, it should be easy to provide a plug-in point for user parsers.
Those parsers could be listed in the INI file.
* Have a validation procedure. Have a versioning system.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/256CarpetHDF5 Writer lacks Dataset support2018-11-01T17:30:43+01:00Ghost UserCarpetHDF5 Writer lacks Dataset supportfrom rug:
```
realname = hfile["Parameters and Global Attributes/Datasets"].value.decode("ascii")[:-1]
```
lacks dataset name
```
sven@nils:/tmp/hdf5$ rug window -f 'log10(y)' whatever.h5 0
Traceback (most recent call last):
...from rug:
```
realname = hfile["Parameters and Global Attributes/Datasets"].value.decode("ascii")[:-1]
```
lacks dataset name
```
sven@nils:/tmp/hdf5$ rug window -f 'log10(y)' whatever.h5 0
Traceback (most recent call last):
File "/home/sven/bin/rug", line 265, in <module>
modules.call(args)
File "/home/sven/numrel/ET/rugutils/modules.py", line 68, in call
return function(**given_args)
File "/home/sven/numrel/ET/rugutils/window.py", line 173, in window
realname, struct = read_file_structure(hfile, name)
File "/home/sven/numrel/ET/rugutils/read_hdf5.py", line 165, in read_file_structure
realname = hfile["Parameters and Global "
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2847)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2805)
File "/usr/lib/python3/dist-packages/h5py/_hl/group.py", line 167, in __getitem__
oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2847)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2805)
File "h5py/h5o.pyx", line 190, in h5py.h5o.open (/build/h5py-qzs83i/h5py-2.7.1/h5py/h5o.c:3738)
KeyError: "Unable to open object (object 'Datasets' doesn't exist)"
```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/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/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/250Issue with Limiting ADER-DG combined with Material Parameters2018-09-13T12:31:58+02:00Ghost UserIssue with Limiting ADER-DG combined with Material ParametersMaurizio's observations
-----------------------
1. If I use the linear kernerl for the "linear elastic part", the NCP term is called sometime with Q==0, so since one component contains the density it divide by 0 at a certain time and th...Maurizio's observations
-----------------------
1. If I use the linear kernerl for the "linear elastic part", the NCP term is called sometime with Q==0, so since one component contains the density it divide by 0 at a certain time and this destroy the solution. In this case if I simply add a check on Q, like if(max(|Q|)<1.e-13) return zero, then it seems to work fine. Also this is strange but maybe we have to better undestand exactly where the wrong call take place.
2. If I use parameters for the material and the linear kernel it seems to work fine.
3. If I use parameters for the material in combination with the limiter, godunov limiter-type, I get a completelly wrong (and unstable) solution, even if I simply add the parameters in the spec file but I don't really use them in the PDE system. In this case if I use musclhancock I simply does not get the solution due to an error in the first time step.
TODOs:
--------------
We currently do not know if it is a problem of the coupling or of the
FV solvers.
1. ~~Does the pure FV solver work correctly with parameters?~~ Yes. It appears so.
2. Does the nonlinear limiting ADER-DG solver work correctly with parameters? No, as shown below.
An error appears at the interface of ADER-DG and FV cells in an experiment where a local recomputation
is performed.
![image](/uploads/549ee942b71bf6adc4640a8555147257/image.png)
~~This might indicate that the DG->FV projectors are still wrong. Sometimes I wish someone wrote some proper unit tests ;-)~~
Apparently, the error does not appear if the limiter domain is static. This would imply
that projectors are correct ~~but something goes wrong in the recomputation.~~
![image](/uploads/c13830aa15de648ff5b73d2d0edbbb3c/image.png)
![image](/uploads/e9b97157968bff16a69f2f2096400a5e/image.png)
The recomputation algorithm was correct. The issue was in the ``updateSolution`` function where
the backup of the previous solution did not take parameters into account.
https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/212Number of Plotters is not detected2018-09-10T19:43:27+02:00Ghost UserNumber of Plotters is not detectedWhen you compile an ExaHyPE application with a Specfile with *n* plotters but run it with *m* plotters (say the types of the first *m-n* plotters are the same), there is no detection that `m != n`. This leads to weird errors which even a...When you compile an ExaHyPE application with a Specfile with *n* plotters but run it with *m* plotters (say the types of the first *m-n* plotters are the same), there is no detection that `m != n`. This leads to weird errors which even are hardly understandable in DEBUG mode:
```
0.0310583 15:50:15 [nils]rank:0 debug exahype::parser::Parser::getIdentifierForPlotter() found token notoken (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:999)
assertion in file /home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp, line 1001 failed: token.compare(_noTokenFound) != 0
parameter token: notoken
parameter solverNumber: 0
parameter plotterNumber: 3
ExaHyPE-GRMHD: /home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp:1001: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> exahype::parser::Parser::getIdentifierForPlotter(int, int) const: Assertion `false' failed.
Abgebrochen
```
but completely nonunderstandable in Release mode:
```
0.00535548 15:32:20 [nils]rank:0 error exahype::parser::Parser::getFirstSnapshotTimeForPlotter() 'GRMHDSolver_FV' - plotter 3: 'time' value must be a float. (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:1046)
0.00538875 15:32:20 [nils]rank:0 error exahype::parser::Parser::getRepeatTimeForPlotter() 'GRMHDSolver_FV' - plotter 3: 'repeat' value must be a float. (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/parser/Parser.cpp,line:1067)
```
note that in this example, `n=4` and `m=3`, so especially plotter 3 looked allright where the error message tried to complain actually about the nonexisting plotter 4.
This is very bad. We need some better enforcement of this rule.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/157Plotter variables are not constants2018-09-10T19:41:33+02:00Ghost UserPlotter variables are not constantsActually the ExaHyPE runtime treats the number of writtenUnknowns per plotter as a runtime variable, ie.
```
plot hdf5::flash ConservedWriter
variables = 19
time = 0.0
repeat = 0.00001
output = ./hdf5-flash/c...Actually the ExaHyPE runtime treats the number of writtenUnknowns per plotter as a runtime variable, ie.
```
plot hdf5::flash ConservedWriter
variables = 19
time = 0.0
repeat = 0.00001
output = ./hdf5-flash/conserved
end plot
```
one can change `variables = x` without recompiling. However, the toolkit wants this to be a constant:
```
plot hdf5::flash ConservedWriter
variables const = 19
time = 0.0
repeat = 0.00001
output = ./hdf5-flash/conserved
end plot
```
otherwise it says `ERROR: eu.exahype.parser.ParserException: [71,17] expecting: 'const'`
This should not happen, ie. the toolkit grammar should accept without `const`.
As always, there is assumably no case when somebody wants to do this **except benchmarking plotter file formats which is exactly what I'm doing now** and the typical generated code by the toolkit is not aware of a non-constexpr number of variables, but all the `ExaHyPE/exahype/plotters/` code actually treats the number as runtime constant and I see no reason why to artificially introduce something constexpr here.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/213Named variables in VTK plots2018-09-10T19:38:52+02:00Ghost UserNamed variables in VTK plotsI want to have them. I will implement this tonight via the plotter mapping class as an optional virtual function (isn't this already there? HDF5 uses it) and pass the data straight forwards throught VTK. This will result in a patch for p...I want to have them. I will implement this tonight via the plotter mapping class as an optional virtual function (isn't this already there? HDF5 uses it) and pass the data straight forwards throught VTK. This will result in a patch for peano.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/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/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/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/241Improve Plotter infrastructure2018-09-04T20:38:44+02:00Ghost UserImprove Plotter infrastructureThis is a long term goal:
The plotters were growing features in a weird way with tons of code duplication and the fact that now some plotters have features which others don't and there is no obvious reason why (for instance: VTK Legendr...This is a long term goal:
The plotters were growing features in a weird way with tons of code duplication and the fact that now some plotters have features which others don't and there is no obvious reason why (for instance: VTK Legendre basis plotter cannot do patchwise mapping of quantities while VTK Cartesian basis plotter can).
The obvious answer to this problem is *abstraction*. I already started once when introducing a `Slicer` interface class to allow various kind of slicing operations without having to specify them in the individual plotters. They just pass the parameters given by the specfile.
In a similar way, we need more abstraction for the quantities mapping, for labeling of the written quantities (named instead of `Q0...QN`), interpolation on different subcell grids, Support of the *isTroubled* flag or in general bitmasks of patch statusses, etc. The following picture is a sketchy overview:
![plotters](/uploads/876457ebab375ee2e1a15bd32a43c1f3/plotters.png)
To be honest I made this ticket here only becaue I wanted to throw away that sketch paper. It is at least one year old.
Figure as PDF: [Sbizhub1318082520330.pdf](/uploads/d4279ca1621927df8155582c66726dd0/Sbizhub1318082520330.pdf)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/246Toolkit2: If it is configure, it should test the make system2018-09-01T15:54:55+02:00Ghost UserToolkit2: If it is configure, it should test the make systemCodes using the popular [Autotools/Autoconf ecosystem](https://www.gnu.org/software/autoconf/manual/autoconf.html) expect users to compile code by something like
```
wget http://example.com/code.tar.gz && unpack || git clone ...
./confi...Codes using the popular [Autotools/Autoconf ecosystem](https://www.gnu.org/software/autoconf/manual/autoconf.html) expect users to compile code by something like
```
wget http://example.com/code.tar.gz && unpack || git clone ...
./configure --with-MPI --with-TBB --without-lapack
make
```
Configure does several things, but typically it
* Checks whether the neccessary *compilers and libraries* are installed by doing test compilations and executions
* Generates a Makefile
We probably all dislike configure for doing these lengthy tests which always consume time.
In similarity to *configure*, some ExaHyPE users (notably Dominic) interpret the ExaHyPE toolkit as a *configure step*:
```
wget http://exahype.eu/obtain/exahype.tar.gz ...
./toolkit.sh PathToSpecfile.exahype
make
```
We know this analogy at least does not hold because some build decisions are made at making time, for instance the choice for MPI, TBB and Assertions. Our toolkit never executes any compiler, it only generates code. There is a clean distinction.
However, frequently compilation fails and users must find out why. What a real *configure* step would provide is a check for compiler capabilities. With tough problems, users have to debug these capabilities anyway, for instance by [compiling and running my compiler challanges](https://bitbucket.org/svek/compiler-challenges).
I suggest we add an option `--test` to the Toolkit which brings in some *configure* flavour. When enabled, after the invocation of the regular Toolkit it could compile and run some tests and test for
* A valid C++11 and Fortran (long lines + REAL=8 bytes) compiler (test programs)
* Presence of a modern and working TBB (test program)
* Presence of a working MPI (test program)
Of course, running these tests probably requires to have some flags such as `EXAHYPE_CC` already set.
As an alternative, I suggest we have another Makefile target for our make system: `make test`, which does not compile the code but instead compiles (and runs) these tests.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/240Access to all patches of a peano cell from within user interface/code2018-08-24T11:55:39+02:00Ghost UserAccess to all patches of a peano cell from within user interface/codeHi,
I'm trying to access all patches within a peano cell from within the user code. I'm using the EulerFV example. Is it possible to document this?
I understand that one has to override the function adjustSolution in the Abstract class...Hi,
I'm trying to access all patches within a peano cell from within the user code. I'm using the EulerFV example. Is it possible to document this?
I understand that one has to override the function adjustSolution in the Abstract class (AbstractMyEulerSolver.cpp) as there kernels::finitevolumes::commons::c::solutionAdjustment() is called.
To my understanding kernels::finitevolumes::commons::c::solutionAdjustment() loops through all the patches within a peano cell.
I override the abstract function but there is a compiler error in commons.cpph that says "too few arguements in function call" - line 493. I suspect that the error is caused by the overriding.
Any help/documentation would be helpful.
thankshttps://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.