ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2020-01-15T11:36:58+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/304Merge with Latest Peano to resolve debug logging errors2020-01-15T11:36:58+01:00Samuel TootleMerge with Latest Peano to resolve debug logging errorsWhen compiling with MODE=Debug, various errors arise related to Peano logging. I checked the Peano master repo and discovered that this issue has been resolved, however, this version has not yet been synched with Exahype sub-modules. T...When compiling with MODE=Debug, various errors arise related to Peano logging. I checked the Peano master repo and discovered that this issue has been resolved, however, this version has not yet been synched with Exahype sub-modules. This was tested using updateSubmodules.sh which results in reverting to the old git hash even after manually pulling Peano/master.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/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/229Add level as parameter to adjustSolution function2018-06-19T11:10:57+02:00Ghost UserAdd level as parameter to adjustSolution functionThe seismic applications need this for topology interpolation.The seismic applications need this for topology interpolation.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/209Toolkit should accept command line arguments for finetuning2019-04-15T12:40:31+02:00Ghost UserToolkit should accept command line arguments for finetuning> **Note:** This is a **minor feature suggestion**. Something which should be done on the **long term** to improve the users daily life. It is **not important right now**
Currently, the toolkit has a way of overwriting some files always...> **Note:** This is a **minor feature suggestion**. Something which should be done on the **long term** to improve the users daily life. It is **not important right now**
Currently, the toolkit has a way of overwriting some files always while creating some files only if they do not yet exist.
Sometimes, especially when the API or toolkit changes, one needs to recreate everything. The typical workflow is then to call `rm Abstract*Solver* KernelCalls*`. Instead, it would be nice if the toolkit supports some option `--overwrite` or similar to always recreate the files. It could also offer an option `--compare` to print whether generated files differ from existing files.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/204Guidebook should not be written in LaTeX2018-01-26T11:39:44+01:00Ghost UserGuidebook should not be written in LaTeX> Note: This issue is really low-importance. Do not continue reading if you care about your time.
The guidebook is currently written in LaTeX, with a primary focus on printing and much efforts put into aligning figures and styling text...> Note: This issue is really low-importance. Do not continue reading if you care about your time.
The guidebook is currently written in LaTeX, with a primary focus on printing and much efforts put into aligning figures and styling texts. IMHO this is the wrong focus. Instead, the guidebook should *focus on content, not on layout*. It should be written in some simple markup language which allows rendering to a web page and a PDF similarly. This is useful for easier deep-linking and reading on screen. It also encourages a more uniform style accross the book.
There are several instances of such language. One very common in the Python world is [Shinx](http://www.sphinx-doc.org), it is very widespread due to its simple syntax in Markdown. I recently stumbled over the [Visit documentation](http://visit-sphinx-user-manual.readthedocs.io) which was rewritten with Sphinx and renders at the same time to a comprehensive website and a [400 page book/pdf](https://media.readthedocs.org/pdf/visit-sphinx-user-manual/latest/visit-sphinx-user-manual.pdf) with a table of contents, numbered images and all that. An example page is http://visit-sphinx-user-manual.readthedocs.io/en/latest/Quantitative/Expressions.html which is generated by the very readable restructuredtext source http://visit-sphinx-user-manual.readthedocs.io/en/latest/_sources/Quantitative/Expressions.rst.txt
Translating our current LaTeX guidebook to something like Restructuredtext or Markdown is a <1h job, therefore switching the publication system is not a mammoth task at all. It is more something people have to agree on. I wonder if Tobias will?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/197Let tarch VTK plotters pass file creation errors to ExaHyPE plotters2018-03-02T12:46:18+01:00Ghost UserLet tarch VTK plotters pass file creation errors to ExaHyPE plottersThis is something where I want to patch Peano and subsequently send the patch to Tobias:
Currently it's annoying that some ExaHyPE plotters stop the program when they cannot open output files (the ASCII/CSV writers as well as my CarpetH...This is something where I want to patch Peano and subsequently send the patch to Tobias:
Currently it's annoying that some ExaHyPE plotters stop the program when they cannot open output files (the ASCII/CSV writers as well as my CarpetHDF5 writer) while other silently ignore this issue (Tobias tarch-based VTK writers). Clearly, we want the user to be able to control whether problems at output shall be severe or not.
I can easily implement this in the ExaHyPE codebase, but I don't control peano, so I have to make sure Peano passes such errors into exahype's domain.
=> TODO @ Sven.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/193Inconsitencies with the solver constructors (ParserView, cmd line passing)2017-10-18T09:07:53+02:00Ghost UserInconsitencies with the solver constructors (ParserView, cmd line passing)Note: This is a _minor_ long term issue.
I noticed (once again) that we have inconsistencies in the handling of the user solver constructor, the abstract solver constructor and the user `init` function, all this for FV, ADERDG and Limit...Note: This is a _minor_ long term issue.
I noticed (once again) that we have inconsistencies in the handling of the user solver constructor, the abstract solver constructor and the user `init` function, all this for FV, ADERDG and LimitingADERDG solvers. While the Command line options passing (`std::vector<std::string>& cmdlineargs`) is mandatory in all solvers, they only get the `exahype::Parser::ParserView& constants` when there *are* constants in the specfile. This creates a lot of trouble for the users, for instance when they decide to introduce constants on an existing application because they need to introduce the new signature then on their own.
Even worse: Currently, the `ParserView&` works for FV solvers, but not for ADERDG solvers (at some point, a `ParserView` instead of a `ParserView&` is needed) and therefore also not for coupled LimitingADERDG solvers.
I know that Tobias wants to keep the first code the user see's in his solver as small as possible. So what about always passing the `cmdlineargs` and a `constants` reference and either storing everything in some class
```
struct SpecfileOptions { // or so
std::vector<std::string>& cmdlineargs;
exahype::Parser::ParserView& constants;
// could store even more, for instance general access to the parser,
// static build information, paths, etc.
};
```
and just pass a `SpecfileOptions& options` to the constructors and the `init` function.
As an alternative or additionally, we can make the `init` function virtual and put an empty implementation into the `Abstract*Solver.{cpp,h}`. Then the user could introduce it into his solver only when he needs it.
We are talking about startup code which is only called once, so this should really be as comfortable as possible, performance does not matter at all.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/191Pass std::vectors to patchwise functions2017-10-13T20:55:05+02:00Ghost UserPass std::vectors to patchwise functions- It's safer - size is available e.g.
- Signatures are clearer. User kernels still get the raw pointers.
- We can just do vector.data() to pass a pointer to the existing kernels.- It's safer - size is available e.g.
- Signatures are clearer. User kernels still get the raw pointers.
- We can just do vector.data() to pass a pointer to the existing kernels.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/188Global Reduction of Time Stepping Data2017-10-11T11:50:37+02:00Ghost UserGlobal Reduction of Time Stepping DataI currently do the following to reduce and broadcast global
values, like e.g. the minimum time step size:
* I broadcast time step data from master to worker
all the way down to the "lowest" worker.
* I reduce time step data from worker...I currently do the following to reduce and broadcast global
values, like e.g. the minimum time step size:
* I broadcast time step data from master to worker
all the way down to the "lowest" worker.
* I reduce time step data from worker to master
all the way up to the global master rank.
I could use a simple MPI_Reduce and a simple MPI_Gather to
perform the above steps.~~
Postponed.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/187No time averaging and kernel's signature2017-10-24T15:25:13+02:00Jean-Matthieu GallardNo time averaging and kernel's signatureHi,
Small design decision. The no time averaging (NTA) option has the effect that the SpaceTimePredictor and VolumeIntegral don't take the same argument with or without the option.
In the case of the SpaceTimePredictor it's a few data ...Hi,
Small design decision. The no time averaging (NTA) option has the effect that the SpaceTimePredictor and VolumeIntegral don't take the same argument with or without the option.
In the case of the SpaceTimePredictor it's a few data storage that aren't required (the one storing the time averaged data) so it's not a bid deal as I can just pass the pointer that happen to be nullptr if NTA is enabled.
In the case of the VolumeIntegral however it's a bit dirtier: it needs either lFhi (time averaged flux) or lFi. Currently I have chosen to always gives the kernel both storage and let it use the right one, ignoring the other (lFhi might be nullptr, lFi is always correct). Another possibility since both lFi and lFhi are double* would be to use the same signature and just pass the correct one, which I could detect by checking if lFhi is nullptr but it would be a bit unclean because it would mean assuming it has to be nullptr when using NTA (which it currently is, but I don't like having such hidden relationship in the code).
Do you agree with the current design (giving everything to the kernel, possibly nullptr, and letting it do the correct choice based on its template parameters) or do you have another design preference ?
Best,
JM
@svenk @di25cox @gi26detJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/185[Toolkit] Makefile generation with template engine + remove ARCHITECTURE2017-10-06T16:28:14+02:00Jean-Matthieu Gallard[Toolkit] Makefile generation with template engine + remove ARCHITECTURETODO
* Generate the Makefile using the template engine
* Remove the ARCHITECTURE parameter export, use the one from the spec fileTODO
* Generate the Makefile using the template engine
* Remove the ARCHITECTURE parameter export, use the one from the spec fileJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/176Bug in optimised kernel generation for limiting ader-dg solver2017-09-06T13:58:22+02:00Ghost UserBug in optimised kernel generation for limiting ader-dg solverInclude file is wrong. Is <MySolver>_ADERDG.h for Limiting-ADER-DG solver.
```
/ddn/home/jdmd33/dev/ExaHyPE-Engine/./Benchmarks/hamilton/Euler/kernels/EulerSolver/stableTimeStepSize.cpp(7): catastrophic error: cannot open source file "E...Include file is wrong. Is <MySolver>_ADERDG.h for Limiting-ADER-DG solver.
```
/ddn/home/jdmd33/dev/ExaHyPE-Engine/./Benchmarks/hamilton/Euler/kernels/EulerSolver/stableTimeStepSize.cpp(7): catastrophic error: cannot open source file "EulerSolver.h"
#include "EulerSolver.h"
^
```Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/162Combine adapters SolutionUpdate and TimeStepSizeComputation2017-08-16T13:06:55+02:00Ghost UserCombine adapters SolutionUpdate and TimeStepSizeComputation......https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/160Support a Tecplot-compatible output format2018-06-15T15:13:42+02:00Ghost UserSupport a Tecplot-compatible output formatThis is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common ...This is really low priority, but just to not forget about:
TecPlot360 is a proprietary but amazing visualization software which feels (in my hands) much better then Visit or ParaView. However, it does not (even) load the smalles common denominator VTK. Instead, a number of file formats are supported in-house:
```
• CGNS Loader
• DEM Loader
• DXF Loader
• EnSight Loader
• Excel Loader
• FEA Loader
• FLOW-3D Loader
• FLUENT Loader
• General Text Loader
• HDF Loader
• HDF5 Loader
• Kiva Loader
• PLOT3D Loader
• PLY Loader
• Tecplot-Format Loader
• Text Spreadsheet Loader
```
See also: http://home.ustc.edu.cn/~cbq/360_data_format_guide.pdf with meaningful pictures as this one:
![beautiful-tecplot-nodal-values](/uploads/c4ea3adb5281c5c2f713199792c50f53/beautiful-tecplot-nodal-values.png)
Instead of Trentos code, we don't want to implement a writer which writes only the tecplot-specific format but instead use some of these widespread formats, for instance "FLUENT" or so.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/152Dynamic plotter registration2019-03-07T19:39:00+01:00Ghost UserDynamic plotter registrationUsers shall be able to add, comment out or remove plotters at runtime without recompiling. The plotter ordering should not be fixed.
This is not too hard to obtain, just requires changes at `KernelCalls.cpp` with having a generated plot...Users shall be able to add, comment out or remove plotters at runtime without recompiling. The plotter ordering should not be fixed.
This is not too hard to obtain, just requires changes at `KernelCalls.cpp` with having a generated plotter registration function (semi pseudocode)
```c++
Writer* kernels::getNamedWriter(std::string name, Solver& solver) {
if(name == "ConservedWriter") return new GRMHD::ConservedWriter(*static_cast<exahype::solvers::LimitingADERDGSolver*>(solver));
if(name == "usw") return new GRMHD::SomeOtherWriter(*static_cast<exahype::solvers::ADERDGSolver*>(solver));
if(name == ...
else
failure: Dont now this plotter type.
}
```
We then can replace the generated current section
```c++
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,0,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,1,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,2,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,3,parser,new GRMHD::ConservedWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
exahype::plotters::RegisteredPlotters.push_back( new exahype::plotters::Plotter(0,4,parser,new GRMHD::IntegralsWriter( *static_cast<exahype::solvers::LimitingADERDGSolver*>(exahype::solvers::RegisteredSolvers[0])) ));
```
with a non-generated section (pseudocode)
```c+++
for(const int& solvernum : Parser->getSolvers()) {
int plotternum=0;
for( const string& plottername : Parser->getPlotterNamesForSolver(solvernum)) {
exahype::plotters::RegisteredPlotters.push_back(new exahype::plotters::Plotter(solvernum,plotternum++,parser,getNamedWriter(plottername, exahype::solvers::RegisteredSolvers[solvernum]));
}
}
```
This is something I can do on my own. If the Parser gives the neccessary data...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/142ADERDG, inverseDX2018-06-19T11:17:55+02:00Jean-Matthieu GallardADERDG, inverseDX* Problem: most kernel use 1/dx instead of dx. Slow operation that could easily be optimized away.
* Solution:
- Peano implement a cellDescription.getInverseSize()
- ADERDGSolver use it
- ADERDG Kernel adapted
* Already done:
- Op...* Problem: most kernel use 1/dx instead of dx. Slow operation that could easily be optimized away.
* Solution:
- Peano implement a cellDescription.getInverseSize()
- ADERDGSolver use it
- ADERDG Kernel adapted
* Already done:
- Optimized kernel adapted, generate the inverseDx in the ADERDGSolver (code isolated with preprocessor)
@di25coxJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/139Kernel activation functions2018-06-15T15:13:43+02:00Ghost UserKernel activation functionsSome notes we might want to pickup later on:
* ``useNCP`` and ``useMatrixB`` are always used as a pair since the Matrix B is fed into the ncp kernel.
* ``useNCP``, ``useMatrixB``, and ``useFlux`` are set for all cells globally. It does ...Some notes we might want to pickup later on:
* ``useNCP`` and ``useMatrixB`` are always used as a pair since the Matrix B is fed into the ncp kernel.
* ``useNCP``, ``useMatrixB``, and ``useFlux`` are set for all cells globally. It does not make
sense to turn them off or on locally in contrast to source terms and point sources.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/133Variables in wrong class2018-06-15T15:13:43+02:00Ghost UserVariables in wrong classJust found out with my clang static source analyzer: We have
```
class Z4::AbstractZ4Solver: public exahype::solvers::ADERDGSolver {
public:
static constexpr int NumberOfVariables = 54;
static constexpr int NumberOfParameters...Just found out with my clang static source analyzer: We have
```
class Z4::AbstractZ4Solver: public exahype::solvers::ADERDGSolver {
public:
static constexpr int NumberOfVariables = 54;
static constexpr int NumberOfParameters = 0;
static constexpr int Order = 3;
class Variables;
class ReadOnlyVariables;
class Fluxes;
...
```
but then
```
class Z4::Z4Solver::ReadOnlyVariables {
private:
const double* const _Q;
public:
static constexpr int SizeVariables
...
```
However, it should be `Z4::AbstractZ4Solver::ReadOnlyVariables` or the forward declarations have to change classes.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/132MySolver::flux parameter F (double**) contiguous or not ?2018-06-15T15:13:43+02:00Jean-Matthieu GallardMySolver::flux parameter F (double**) contiguous or not ?Here is the signature of the flux function:
`void GRMHD::GRMHDSolver::flux(const double* const Q,double** F)`
When using Fortran user code, it is assumed by @svenk that F is a contiguous array. This is true with the generic kernel but...Here is the signature of the flux function:
`void GRMHD::GRMHDSolver::flux(const double* const Q,double** F)`
When using Fortran user code, it is assumed by @svenk that F is a contiguous array. This is true with the generic kernel but false with the optimized one due to changing the data layout of LFi from (t, z, y, x, nDim + 1 for Source, nVar) to (nDim + 1 for Source,t, z,y, x, , nVar_padded)
The assumption that F is contiguous was never explicitly given so my question:
Should F be assumed to be contiguous ?
If yes I need to adapt the optimized kernel, if not then the Fortran user code should at least explicitly mention this and if possible do the conversion himself.
Concerned: @svenk @ga96nuv @di25cox @gi26detJean-Matthieu GallardJean-Matthieu Gallard