ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-03-05T22:06:05+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/263Optimised kernels won't compile if Architecture is noarch2019-03-05T22:06:05+01:00Ghost UserOptimised kernels won't compile if Architecture is noarchThe toolkit should stop processing if `Architecture=="noarch" but optimisation="optimised"` is selected and raise an error, instead of building nonworking code which won't compile. Otherwise, users will be confronted with C compiler erro...The toolkit should stop processing if `Architecture=="noarch" but optimisation="optimised"` is selected and raise an error, instead of building nonworking code which won't compile. Otherwise, users will be confronted with C compiler errors like
```
/zhome/academic/HLRS/xfp/xfpskoep/ExaHyPE/Engine/./AstroApplications/CCZ4GRMHD/AbstractCCZ4GRMHDSolver_ADERDG.h(257): error: identifier "ALIGNMENT" is undefined
inline double* allocateArray(const int size) {return ((double* ) _mm_malloc(sizeof(double)*size, ALIGNMENT));}
^
/zhome/academic/HLRS/xfp/xfpskoep/ExaHyPE/Engine/./AstroApplications/CCZ4GRMHD/AbstractCCZ4GRMHDSolver_ADERDG.cpp(89): error: identifier "ALIGNMENT" is undefined
double tempUpdate[CCZ4GRMHD::CCZ4GRMHDSolver_ADERDG_kernels::aderdg::getUpdateSize()] __attribute__((aligned(ALIGNMENT))); // TODO no heap variant implemented
^
```
which are hard to understand.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/249Toolkit2: Proper handling of parameters to plotters2019-04-15T12:36:17+02:00Ghost UserToolkit2: Proper handling of parameters to plottersJM reports:
```
vers/0/plotters/0/parameters
0.0855118 19:11:35 [mpp2r02c02s08]rank:0 info exahype::plotters::Plotter::Plotter(...) write snapshot to file ./reference_solution every 0.005 time units with f...JM reports:
```
vers/0/plotters/0/parameters
0.0855118 19:11:35 [mpp2r02c02s08]rank:0 info exahype::plotters::Plotter::Plotter(...) write snapshot to file ./reference_solution every 0.005 time units with first snapshot at 0. plotter type is probe::ascii. Plotter configuration=(solver no=0,plotter identifier (type)=probe::ascii,written unknowns=9,time=0,repeat=0.005,file name=./reference_solution,plotter parameters={"select":{"x":0.5,"y":0.5,"z":0.8}},device configured=0)
0.085593 19:11:35 [mpp2r02c02s08]rank:0 error exahype::plotters::ADERDG2ProbeAscii::init() Probe location is invalid. Require x,y,z values. Have {"select":{"x":0.5,"y":0.5,"z":0.8}} (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./ExaHyPE/exahype/plotters/ADERDG2ProbeAscii.cpp,line:56)
0.085651 19:11:35 [mpp2r02c02s08]rank:0 error exahype::parser::Parser::getIntFromPath() Missing entry /solvers/0/plotters/0/parameters/x ([json.exception.out_of_range.403] key 'x' not found) (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./ExaHyPE/exahype/parser/Parser.cpp,line:346)
0.0856928 19:11:35 [mpp2r02c02s08]rank:0 error exahype::parser::Parser::getIntFromPath() Missing entry /solvers/0/plotters/0/parameters/y ([json.exception.out_of_range.403] key 'y' not found) (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./ExaHyPE/exahype/parser/Parser.cpp,line:346)
0.0857256 19:11:35 [mpp2r02c02s08]rank:0 error exahype::parser::Parser::getIntFromPath() Missing entry /solvers/0/plotters/0/parameters/z ([json.exception.out_of_range.403] key 'z' not found) (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./ExaHyPE/exahype/parser/Parser.cpp,line:346)
0.0879261 error was not able to open input file exahype.log-filter (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./Peano/tarch/logging/LogFilterFileReader.cpp,line:88)
0.0879611 warning filter file exahype.log-filter was invalid. Switch on all log statements (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./Peano/tarch/logging/LogFilterFileReader.cpp,line:105)
0.0879824 error do not run code as parser reported errors (file:/home/hpc/pr63so/di57wuf/ExaHyPE-Engine/toolkit2-linear_flux_ncp_mm.exahype-build/./ExaHyPE/exahype/runners/Runner.cpp,line:691)
0.0879934 info quit with error code 1
status=COMPLETED
```
This does not seem to be a fault by the C++ Parser but maybe instead by the `classic-exahype -> JSON` converter in the toolkit.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/244Toolkit2: Should have --pretend and --clean option2019-04-15T12:40:31+02:00Ghost UserToolkit2: Should have --pretend and --clean optionEvery invocation of the toolkit currently overwrites certain files. However, as a user, I miss two options:
* Clean the generated files, especially the glue files. For a *novice user*, it is not obvious what to clean when wanting certai...Every invocation of the toolkit currently overwrites certain files. However, as a user, I miss two options:
* Clean the generated files, especially the glue files. For a *novice user*, it is not obvious what to clean when wanting certain files to be regenerated. A `--clean` file should exeute `rm Abstract* KernelCalls*`
* Explain what the toolkit would do. Some tools such as [rename(1)](http://man7.org/linux/man-pages/man1/rename.1.html) or [rsync(1)](https://linux.die.net/man/1/rsync) have an option called `--pretend`, `--dry-run` or `--no-act` which *explain* what the tool would do. We should offer such an option to make it more transparent what especially a second run of the toolkit does.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/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/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.