ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-09-20T15:46:39+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/127Revise time stepping notation2019-09-20T15:46:39+02:00Ghost UserRevise time stepping notationI have to write down carefully how I handle the time step sizes for
* fused time stepping
* standard time stepping
and what I do during mesh refinement for
* fused time stepping
* standard time stepping
This is getting a little comp...I have to write down carefully how I handle the time step sizes for
* fused time stepping
* standard time stepping
and what I do during mesh refinement for
* fused time stepping
* standard time stepping
This is getting a little complicated and the docu just gives an partial overview.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/126CFL factor per solver as const int the specfile2019-04-15T12:37:03+02:00Ghost UserCFL factor per solver as const int the specfileThis reduces inconsistencies. Can now be easily generated as constexpr double into the AbstractMySolver class.This reduces inconsistencies. Can now be easily generated as constexpr double into the AbstractMySolver class.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/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/69Do memory precision tests2019-03-07T19:23:10+01:00Ghost UserDo memory precision testsTobias schreibt:
>
ich braeuchte mal Deine Hilfe (ja, natuerlich schnell, weil das in die Praesentation rein soll, aber das haste eh vermutet ;-). Die neue ExaHyPE-Version von gestern Nacht kann mit Zahldarstellungen <IEEE double Standa...Tobias schreibt:
>
ich braeuchte mal Deine Hilfe (ja, natuerlich schnell, weil das in die Praesentation rein soll, aber das haste eh vermutet ;-). Die neue ExaHyPE-Version von gestern Nacht kann mit Zahldarstellungen <IEEE double Standard arbeiten. Das ist teuer (erste Schritte suggerieren einen Faktor 5 in der Laufzeit, aber das koennte auch am Chip liegen, d.h. ich muss die Russenmaschine testen), aber es reduziert halt den Speicherbedarf einer Simulation etwas. Ich bekomm 10% schon fuer den einfachen Euler 2d mit Ordnung 3 - hoffe aber, dass das bei anderen Setups deutlich signifikanter ist. Einschalten laesst sich das Feature, indem man
>
double-compression = 0.000001
>
auf etwas zwischen 0 und 1 setzt. Das andere Flag spawn-double-compression-as-background-thread kannste vergessen, das ist meine Baustelle. Meine Frage/Bitte ist nun: Hast Du einen sinnvollen Benchmark zur Hand aus der Astrophysik und kannst Du mal
double-compression = 0.0
double-compression = 0.0001
double-compression = 0.000001
double-compression = 0.000000000001
>
damit ausprobieren und mir sagen, ob Werte grosser 0 die Loesung qualitativ verschlechtern? Ich hab keine Ahnung, was Ihr Euch typischerweise anseht (Ankunftszeiten/Amplituden/...?) deswegen brauch ich da ein qualifiziertes Auge. Wenn Du parallel noch drauf schaust, was er als memoryUsage ausgibt (macht er jetzt automatisch, wenn man nicht mit MPI uebersetzt), dann wuerde mir das sehr helfen, da eine Einschaetzung zu bekommen.
>
Nachtrag: So saehe dann eine Optimisation Sectino aus
```
optimisation
fuse-algorithmic-steps = on
fuse-algorithmic-steps-factor = 0.99
timestep-batch-factor = 0.0
skip-reduction-in-batched-time-steps = on
disable-amr-if-grid-has-been-stationary-in-previous-iteration = off
double-compression = 0.000001
spawn-double-compression-as-background-thread = off
end optimisation
```
@svenk: Machen.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/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/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/111Delete Logo.h from repository and include minimal PNG decoding library2018-06-15T15:13:43+02:00Ghost UserDelete Logo.h from repository and include minimal PNG decoding libraryThe ExaHyPE repository has more than 2000 commits and weights only 10MB. Now in January somebody added a **10MB C++ header file** containing an uncompressed picture. It's not only possible to read in this picture in any image reader any...The ExaHyPE repository has more than 2000 commits and weights only 10MB. Now in January somebody added a **10MB C++ header file** containing an uncompressed picture. It's not only possible to read in this picture in any image reader any more, but the repository just blew to the double size and nobody really wants to deal with such files (try to load it in a text editor).
First, the commit introducing this picture should be changed and the monster file deleted out of the repository.
Second, it should be replaced by an actual picture in GIF, JPG, PNG or similar efficient formats (will be less than **20kb**!) and a suitable decompression routine should be added to the Demonstrator. This mimics how actual offline initial data generators work. We do _not_ need to introduce a dependency on an external library but can embed an Open Source minimal decoding library. There are a lot of them, for instance one of these:
* https://github.com/nothings/stb/blob/master/stb_image.h - single file header only PNG decompressor (*public domain*, 200kB code)
* https://github.com/elanthis/upng - another micro PNG decompressor single file library (*as-is* license)
* http://lodev.org/lodepng/ - another pico PNG decomressor, 500lines (*as-is* license)
* https://github.com/hidefromkgb/gif_load/blob/master/gif_load.h - a 400 lines GIF reader (*public domain*, 20kB code)
This is really the way to go as it allows users to exchange the picture with another one _at runtime_.
I @sven volunteer to implement this.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/114BC: Right handed coordinate system in guidebook2018-06-15T15:13:43+02:00Ghost UserBC: Right handed coordinate system in guidebookCartesian coordinates are by definition *Rechtshändig*, ( https://de.wikipedia.org/wiki/Rechtssystem_(Mathematik) ):
![rechts](https://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Koordinatensysteme_L%2BR.svg/800px-Koordinatensyste...Cartesian coordinates are by definition *Rechtshändig*, ( https://de.wikipedia.org/wiki/Rechtssystem_(Mathematik) ):
![rechts](https://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Koordinatensysteme_L%2BR.svg/800px-Koordinatensysteme_L%2BR.svg.png)
However, in the guidebook its not:
![dafuq](/uploads/4166e787580d36966833580132607419/dafuq.png)
Also the figure is extremely misleading. I interpret the convention as following:
```
! faces: 0-left, 1-right, 2-front, 3-back, 4-bottom, 5-top
! ie. 0 x=0 1 x=max, 2 y=0 3 y=max 4 z=0 5 z=max
```
As "left", "right", etc. is really not well defined.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/115Version string crashing2018-06-15T15:13:43+02:00Ghost UserVersion string crashingAt least with ADERDG Limiting applications, when calling `--version`, we get a crash:
```
$ ./ExaHyPE-MHD --version
0.000146866 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned ...At least with ADERDG Limiting applications, when calling `--version`, we get a crash:
```
$ ./ExaHyPE-MHD --version
0.000146866 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[vertex] the free tag 0
0.000248671 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[cell] the free tag 1
0.000282049 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[cell-marker] the free tag 2
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abgebrochen
```
This is certainly because the Solver `toString()` methods print a lot of information and somewhere there is a nullpointer inbetween, probably the linked FV solver in the limiting scheme.
I don't like to have such a verbose `toString()` anyway, but we'll see. Maybe I put in a more decent `toString()` method.
The `toString`s also lack the name of the actual class, ie. the new output how Dominic created it is no more able to tell about the actual class names.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/116Specfile Constants don't accept strings2018-06-15T15:13:43+02:00Ghost UserSpecfile Constants don't accept stringsWhen running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maxim...When running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maximum-mesh-size = 0.9
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
limiter-kernel const = generic::Godunov
limiter-language const = C
dmp-relaxation-parameter = 0.0001
dmp-difference-scaling = 0.001
constants = foo:bar
...
```
where I want the variable `foo` to set the String value `bar`, the parser complaints:
```
ERROR: eu.exahype.parser.ParserException: [70,42] expecting: float number
```
It also doesn't accept a string (`foo:"bar"`):
```
ERROR: eu.exahype.lexer.LexerException: [70,42] Unknown token: "
```
In our applications, the majority of parameters are strings, next to boolean values.
I rank this ticket *Minor* as constants have never worked for me (always issues with the parser #44) and I stick to environment variables and command line arguments.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/103Run long EulerFlow simulation to understand constant plotting issue and inclu...2018-06-15T15:13:43+02:00Ghost UserRun long EulerFlow simulation to understand constant plotting issue and include CSV dt outputzweiter. Diskussionspunkt: "Zeitschritte" im Sinne des "Constantly Plottings" bzw. "Output every nth iteration", verhalten sich anders als erwartet. Wir vergleichen das reale Erstellen des Plots ab Simulationsstart mit dem erwarteten ide...zweiter. Diskussionspunkt: "Zeitschritte" im Sinne des "Constantly Plottings" bzw. "Output every nth iteration", verhalten sich anders als erwartet. Wir vergleichen das reale Erstellen des Plots ab Simulationsstart mit dem erwarteten idealen Erstellen des Plots. Die Messung nehmen wir von exahype::plotters::Plotter::UserOnTheFlyPostProcessing::startPlotting(double time) ab.
Zwei Beobachtungen:
* (i) die Kurve tIdeal-tReal ist mal <0, mal >0. Messfehler?
* (ii) Die Kurve tIdeal-tReal weist einen Trend propertional zur Simulationszeit auf. Fehler in ExaHyPE?
2a) Tobias schlägt vor, die Simulation länger laufen zu lassen, um mehr Daten zu haben. Kann ich mit EulerFlow/ShuVortex + TBB schlecht machen weil sich der 2D-Vortex in der Diagonalen bewegt, Simulationsdomäne damit quadratisch zur Zeit und ich keinen Benchmark mehr machen will der einen Tag lang läuft. => Benötige MPI-Reductions. Wird gemacht.
**2b) Einbau eines CSV-Plotters für Zeitschritte direkt in den Code, damit ich nicht die stdout-Ausgaben parsen muss. Kann ich machen.**https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/120Cleanup generic kernels2018-06-15T15:13:43+02:00Ghost UserCleanup generic kernelsIts producing a lot of warnings, ie.
```
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels....Its producing a lot of warnings, ie.
```
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h:222:0,
from /media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:13:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/solutionAdjustment.cpph: In instantiation of ‘void kernels::aderdg::generic::c::solutionAdjustment(SolverType&, double*, const tarch::la::Vector<3, double>&, const tarch::la::Vector<3, double>&, double, double) [with SolverType = GRMHD::GRMHDSolver]’:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:84:115: required from here
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/solutionAdjustment.cpph:49:19: warning: unused variable ‘dofStartIndex’ [-Wunused-variable]
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h:227:0,
from /media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:13:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/dummyK_Kernel.cpph: In instantiation of ‘void kernels::aderdg::generic::c::dummyK_Kernel(SolverType&, double, double, const tarch::la::Vector<3, double>&, const tarch::la::Vector<3, double>&, int, int, int, double*) [with SolverType = GRMHD::GRMHDSolver]’:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:115:209: required from here
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/dummyK_Kernel.cpph:30:10: warning: unused variable ‘x0’ [-Wunused-variable]
double x0[3];
```
also get rid of `malloc`, use stack.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/74Do nightly convergence tests2018-06-15T15:13:43+02:00Ghost UserDo nightly convergence testsAs an initiative for proving and monitoring the correctness of ExaHyPE, we should come up with a series of very simple tests which demonstrate how we debug the code and also give convergence rates.
This is something Sven and Vasco can d...As an initiative for proving and monitoring the correctness of ExaHyPE, we should come up with a series of very simple tests which demonstrate how we debug the code and also give convergence rates.
This is something Sven and Vasco can do.
A problem is that almost all tests require periodic BC, thought.
## Collection of problems
We could solve:
* Advection Equations
* With the Initial Data:
* Low order polynomials (`Q(:) = 1 + v0 * x(0) - v0 * t`). Intermediate solver steps are always analytically known
* No polynomials (`Q(:) = ICA * SIN(2*pi*(x(0) - t))` et al)
* For random matter distributions
* Implemented as conservative equation (`F(Q) = Q`)
* Implemented as nonconservative equation (`F=0, BgradQ = (1,0,0), S=0`)
* EulerFlow, SRHD, MHD: See the [List of Benchmarks](https://gitlab.lrz.de/gi26det/ExaHyPE/wikis/list%20of%20benchmarks)
See also: gi26det/ExaHyPE#73 and gi26det/ExaHyPE#64.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/107An idea to solve both the toolkit overwriting and file location problem2018-06-15T15:13:43+02:00Ghost UserAn idea to solve both the toolkit overwriting and file location problemThe Java toolkit creates C++ files in the application directory ("output Directory"). This creates (amongst others) two problems:
1. In large applications, users cannot freely structure their code in subdirectories
2. Users cannot u...The Java toolkit creates C++ files in the application directory ("output Directory"). This creates (amongst others) two problems:
1. In large applications, users cannot freely structure their code in subdirectories
2. Users cannot understand which files are overwritten and which not
To address problem (1), I recently introduced an heuristic approach, [FileSearch.java](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/6e7e9552fb3d65b4c5feb5c70e36038be06499ad/Toolkit/src/eu/exahype/FileSearch.java). This allows to put a file *with a similar name* in any subdirectory in the output directory. Thus, for instance, we can have an application to be structured in folders like
```
SRMHD
├── C2P-MHD.f90
├── C2P-MHD.h
├── C2PRoutines.f90 -> ../SRHD/C2PRoutines.f90
├── ExaHyPE-MHDSolver-p2
├── extended.log
├── InitialDataAdapter.cpp
├── InitialDataAdapter.h
├── InitialData.f90
├── KernelCalls.cpp
├── Makefile
├── make-p2.log
├── MHDSolver.cpp
├── MHDSolver_generated.cpp
├── MHDSolver.h
├── Parameters.f90
├── parameters.mod
├── PDE.f90
├── PDE.h
├── run_withEnv.sh
└── Writers
├── ConservedWriter.cpp
├── ConservedWriter.h
├── ErrorWriter.cpp
├── ErrorWriter.h
├── ExactPrimitivesWriter.cpp
├── ExactPrimitivesWriter.h
├── IntegralsWriter.cpp
├── IntegralsWriter.h
├── PrimitivesWriter.cpp
├── PrimitivesWriter.h
├── RelativeErrorWriter.cpp
├── RelativeErrorWriter.h
└── TimeSeriesReductions.h -> ../../EulerFlow/TimeSeriesReductions.h
```
ie. note the `Writers` subdirectory.
Actually, this ticket shall propose an idea which solves the problems (1) and (2) altogether.
## Defining a header
My idea proposes to define a magic line at any place (ie. header or footer) of the generated `.h` or `.cpp` files, containing something like:
```
/** ExaHyPE.jar: autogenerated at Fr 3. Feb 19:08:51 CET 2017 **/
/** ExaHyPE.jar: File identifier: Plotter[i].HeaderCode **/ <- this is the identifier line
/** ExaHyPE.jar: Rebuild options: [x] Rebuild on every toolkit call [ ] Manually disable rebuild [ ] Rebuild on structural change **/ <- This can be changed by user
```
The identifier line solves the problem to find an appropriate file. It allows users to rename them as he wants. The toolkit has to inspect all possible files with a `grep` like search, but this is not too bad. We don't really expect too big applications...
The options line allows the user both to understand the default setting and to enforce his own rules. This is very helpful when working at ExaHyPE internals and to stop this long lasting conflict with the toolkit overwriting stuff. It also allows users to request an overwrite of a file. The specific syntax is open to discussion, ie. one could also choose something better machine readable here.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 Gallardhttps://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/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/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.