ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-04-15T12:40:31+02:00https://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/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/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/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/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/226Use sensible Fortran flags2018-04-24T11:58:40+02:00Ghost UserUse sensible Fortran flagsAt the moment the fortran code is compiled with minimal flags, and therefore the compiler has its hands tied. However, the code is written in a way which should be easily vectorisable by the compiler.
Ekatherine from RSC is currently te...At the moment the fortran code is compiled with minimal flags, and therefore the compiler has its hands tied. However, the code is written in a way which should be easily vectorisable by the compiler.
Ekatherine from RSC is currently testing:
`-xCORE-AVX512 -fma -align array64byte`
and has mentioned that `-qopt-prefetch=3` worked well with the prototype code.
To be updated...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/275User-friendly API, use AbstractSolver as Adapter2019-07-23T10:40:16+02:00Ghost UserUser-friendly API, use AbstractSolver as AdapterIn order to make the code more easy to use, we could reestablish the MySolver_Variables
data access classes.
We could implement the user hooks that take a raw pointer in the AbstractSolver,
and would then call the user solver's implemen...In order to make the code more easy to use, we could reestablish the MySolver_Variables
data access classes.
We could implement the user hooks that take a raw pointer in the AbstractSolver,
and would then call the user solver's implementation which takes the
data access object as argument.
**Example:**
```
void MyAbstractSolver::adjustPointSolution(double* const Q,...) {
Variables vars(Q);
static_cast<MyUserSolver*>(this)->adjustPointSolution(vars,...);
}
```
We could then have additional data access classes for the full solution array, e.g. ``Solution`` and ``ReadOnlySolution``.
Potentially, we could then introduce dimension-aware iterators with appropriate typecast to
a ``Variables`` or ``ReadOnlyVariables`` object.
This would allow writing code like the following.
**Example:**
```
void MyAbstractSolver::refinementCriterion(ReadOnlySolution solution,...) {
double rhoMax = 0;
for ( ReadOnlyVariables& Q : solution ) {
rhoMax = std::max( Q.rho(), rhoMax );
}
}
```
Remarks
-------
``(ReadOnly)Variables`` and ``Variables`` must be split or declared in such a way that
it is clear that there is not necessarily a contiguous array storing
and variables and parameters. We should get rid of the index operator and
have separate functions ``double`` parameter(int i), ``double& variable(int i)`` instead.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/266Write plotters which really plot limited DOF where the limiter is active2019-03-21T10:41:52+01:00Ghost UserWrite plotters which really plot limited DOF where the limiter is activeFor VTK, this is straightforward.
For other formats, this is a nice to have.For VTK, this is straightforward.
For other formats, this is a nice to have.