ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2018-06-15T15:13:43+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/105[Design decision][CodeGenerator] Optimizing unused feature2018-06-15T15:13:43+02:00Jean-Matthieu Gallard[Design decision][CodeGenerator] Optimizing unused feature@di25cox @svenk @gi26det
I'm currently rewriting the SpaceTimePredictor Code Generator and have the following issue:
The source terms for the SpaceTimePredictor and VolumeIntegral (in memory: 4th block of tempFluxUnknowns = lFhi a...@di25cox @svenk @gi26det
I'm currently rewriting the SpaceTimePredictor Code Generator and have the following issue:
The source terms for the SpaceTimePredictor and VolumeIntegral (in memory: 4th block of tempFluxUnknowns = lFhi and tempSpaceTimeFluxUnknowns[0] = lFi in 3D, tempSpaceTimeFluxUnknowns[1] = gradQ and tempStateSizedVector = BgradQ) are totally unused in Euler and therefore weren't implemented at all in the optimized kernel.
I could implement them like the generic kernel do (always active) but it would be highly inefficient as a lot of tensor product and function call for nothing would be required, also the generic kernel should be optimized to be able to chose to disable this feature altogether if not required.
So I'll need to force the user to chose to activate the use of source term or not (at least for the optimized kernel, the generic ones can later be adapted the same way). I see 3 way of doing this efficiently:
* Write it somewhere in the spec file so that the Code Generator can generate code without source term if required
* Use preprocessor instruction and tell the user to modify the local makefile or a new compile configuration file to enable/disable it and then mark the source term related code with preprocessor branching
* Use templating and template metaprogramming to generate two or more version of the code, then let the user chose which one to use by changing a boolean that will be read in the MySolver_generated to choose the correct implementation
Example of solution 3:
```
template <boolean useSource>
void test() {
if(useSource) {
printf("Source term code used");
} else {
printf("No Source term code");
}
}
// [...] in Mysolver_generated
if(useSourceLocalBoolean) {
test<true>();
} else {
test<false>();
}
```
The advantage is that the branching optimization is done at compile time with 2 version of the code generated and the branching evaluation will be very cheap (once per cell per timestep). The drawback is that the code become more complex.
I would prefer solution 1 or 2 but we can discuss it as it is not urgent matter (I'm implementing without source at first).Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/104EulerFlow and SRMHD Convergence2018-06-15T15:13:43+02:00Ghost UserEulerFlow and SRMHD ConvergenceThere was a mistake in the EulerFlow and SRMHD error computation routines:
The analytical solution expressed in conserved variables was compared vs.
the numerical solution expressed in primitive variables.
I will report the errors ...There was a mistake in the EulerFlow and SRMHD error computation routines:
The analytical solution expressed in conserved variables was compared vs.
the numerical solution expressed in primitive variables.
I will report the errors for EulerFlow Moving Gauss 2D and SRMHD Alfven Wave 2D after the fix to make sure
we do not get the computation wrong again.
I further added a Gauss-Legendre quadrature based error computation
to the EulerFlow project in order to validate the Riemann quadrature values. Indeed, there is only a small
difference. Convergence is observed in both cases .
(I did not calculate the rates yet. Sven should have a script for that.)
Some debugging tips:
* **We need to make sure that always matching variables (cons.,prim.) are compared against eacht other -- also for the SRMHD convergence tests.)**
* **Even if the solver might get inaccurate in the long term, the initial data should always be better resolved on a finer mesh. We should always see
convergence in projecting the initial data!**
## EulerFlow moving Gauss 2D-- rho errors
settings: fused-algorithmic-steps=on,timestepping=globalfixed
### Gauss-Legendre quadrature:
maximum-mesh-size = 0.5
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.750382e-13 8.925639e-13 1.311617e-12 6.208367e-13 8.950533e-13
2 5.459310e-02 1.038389e-03 2.920092e-03 1.570339e-02 1.460953e-06 8.411925e-04
3 1.013872e-01 1.410669e-03 4.361094e-03 2.551770e-02 2.776317e-06 1.122370e-03
4 1.559803e-01 1.239346e-03 3.639293e-03 2.137039e-02 8.062877e-07 1.042290e-03
5 2.027744e-01 8.993649e-04 2.033884e-03 9.321796e-03 4.938160e-06 8.758699e-04
6 2.573675e-01 8.112109e-04 2.558304e-03 2.066562e-02 1.188077e-06 8.807274e-04
7 3.041615e-01 1.171406e-03 3.257146e-03 2.334808e-02 1.116484e-06 1.177089e-03
8 3.509556e-01 1.247573e-03 3.321656e-03 2.104360e-02 8.826953e-07 1.255401e-03
9 4.055487e-01 9.415592e-04 2.712697e-03 2.152044e-02 4.344998e-08 9.937017e-04
```
maximum-mesh-size = 0.15
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.772611e-13 8.949179e-13 1.507683e-12 6.206147e-13 8.976664e-13
2 5.199343e-02 1.824504e-04 1.173739e-03 1.840355e-02 1.319400e-11 1.656369e-04
3 1.013872e-01 1.463228e-04 8.135031e-04 1.585928e-02 9.383494e-12 1.586405e-04
4 1.507809e-01 1.511930e-04 7.129781e-04 7.640309e-03 6.468159e-13 1.499519e-04
5 2.001747e-01 1.799638e-04 1.039565e-03 1.571490e-02 7.177703e-12 1.593651e-04
6 2.521681e-01 2.472488e-04 1.460660e-03 2.225137e-02 1.960077e-11 2.191721e-04
7 3.015619e-01 2.123867e-04 9.078946e-04 1.156214e-02 2.549394e-11 2.037580e-04
8 3.509556e-01 1.996272e-04 1.025265e-03 1.816118e-02 3.995360e-11 2.028881e-04
9 4.003494e-01 2.200875e-04 1.407165e-03 2.126848e-02 6.046564e-10 1.847641e-04
```
maximum-mesh-size = 0.05
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.775711e-13 8.953091e-13 1.799227e-12 6.206147e-13 8.981400e-13
2 5.026031e-02 8.648108e-06 1.024604e-04 2.880816e-03 1.421085e-14 8.765676e-06
3 1.005206e-01 1.310812e-05 1.404085e-04 4.134064e-03 1.211253e-13 1.270370e-05
4 1.507809e-01 1.204385e-05 1.501490e-04 7.148238e-03 2.442491e-14 1.169658e-05
5 2.001747e-01 1.309551e-05 1.688337e-04 5.761659e-03 3.804734e-13 1.238790e-05
6 2.504350e-01 1.609669e-05 1.985765e-04 7.332591e-03 1.674216e-13 1.489681e-05
7 3.006953e-01 1.583313e-05 2.188010e-04 9.998774e-03 3.019807e-14 1.503079e-05
8 3.500891e-01 1.771167e-05 2.384444e-04 8.503132e-03 7.386314e-13 1.616133e-05
9 4.003494e-01 1.941804e-05 2.599394e-04 1.078235e-02 2.096101e-13 1.797866e-05
```
### Riemann quadrature:
maximum-mesh-size = 0.5
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.208791e-04 2.760006e-03 1.152340e-02 1.857846e-09 8.208791e-04
2 5.459310e-02 1.136775e-03 2.987134e-03 1.768960e-02 1.300473e-06 1.136775e-03
3 1.013872e-01 1.339213e-03 3.890847e-03 2.752230e-02 1.402174e-07 1.339213e-03
4 1.559803e-01 1.298609e-03 3.445100e-03 2.234650e-02 3.597158e-09 1.298609e-03
5 2.027744e-01 1.040780e-03 2.383341e-03 9.564163e-03 1.192050e-09 1.040780e-03
6 2.573675e-01 1.125659e-03 2.468552e-03 8.197815e-03 7.159261e-10 1.125659e-03
7 3.041615e-01 1.645793e-03 3.824891e-03 1.758752e-02 3.099943e-09 1.645793e-03
8 3.509556e-01 1.710023e-03 4.109781e-03 1.967037e-02 6.597448e-09 1.710023e-03
9 4.055487e-01 1.238782e-03 2.674109e-03 8.709187e-03 5.247924e-09 1.238782e-03
```
maximum-mesh-size = 0.15
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.976664e-13 9.187753e-13 1.507683e-12 6.206147e-13 8.976664e-13
2 5.199343e-02 1.656369e-04 1.006196e-03 1.840355e-02 1.319400e-11 1.656369e-04
3 1.013872e-01 1.586405e-04 8.668425e-04 1.585928e-02 9.383494e-12 1.586405e-04
4 1.507809e-01 1.499519e-04 7.055692e-04 7.640309e-03 6.468159e-13 1.499519e-04
5 2.001747e-01 1.593651e-04 8.780007e-04 1.571490e-02 7.177703e-12 1.593651e-04
6 2.521681e-01 2.191721e-04 1.259805e-03 2.225137e-02 1.960077e-11 2.191721e-04
7 3.015619e-01 2.037580e-04 8.841593e-04 1.156214e-02 2.549394e-11 2.037580e-04
8 3.509556e-01 2.028881e-04 1.060100e-03 1.816118e-02 3.995360e-11 2.028881e-04
9 4.003494e-01 1.847641e-04 1.146441e-03 2.126848e-02 6.046564e-10 1.847641e-04
```
maximum-mesh-size = 0.05
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 8.981400e-13 9.193660e-13 1.799227e-12 6.206147e-13 8.981400e-13
2 5.026031e-02 8.765676e-06 1.038935e-04 2.880816e-03 1.421085e-14 8.765676e-06
3 1.005206e-01 1.270370e-05 1.360760e-04 4.134064e-03 1.211253e-13 1.270370e-05
4 1.507809e-01 1.169658e-05 1.486293e-04 7.148238e-03 2.442491e-14 1.169658e-05
5 2.001747e-01 1.238790e-05 1.582185e-04 5.761659e-03 3.804734e-13 1.238790e-05
6 2.504350e-01 1.489681e-05 1.849682e-04 7.332591e-03 1.674216e-13 1.489681e-05
7 3.006953e-01 1.503079e-05 2.125449e-04 9.998774e-03 3.019807e-14 1.503079e-05
8 3.500891e-01 1.616133e-05 2.143398e-04 8.503132e-03 7.386314e-13 1.616133e-05
9 4.003494e-01 1.797866e-05 2.425857e-04 1.078235e-02 2.096101e-13 1.797866e-05
```
## SRMHD Alfven wave 2D -- vely errors
settings: fused-algorithmic-steps=off,timestepping=global
maximum-mesh-size = 0.5
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 1.547407e-03 2.445560e-03 4.573094e-03 2.602050e-05 1.547407e-03
2 6.015317e-02 1.111526e-03 1.657690e-03 3.769028e-03 3.275033e-06 1.111526e-03
3 1.002207e-01 1.398944e-03 1.869334e-03 4.319537e-03 2.836757e-04 1.398944e-03
```
maximum-mesh-size = 0.15
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 2.302968e-05 3.590189e-05 7.108230e-05 1.139464e-07 2.302968e-05
2 5.344862e-02 2.056201e-05 3.057057e-05 7.954177e-05 3.314441e-07 2.056201e-05
3 1.002171e-01 2.300635e-05 3.160379e-05 7.990042e-05 5.301505e-07 2.300635e-05
```
maximum-mesh-size = 0.05
```
plotindex time l1norm l2norm max min avg
1 0.000000e+00 2.913558e-07 4.523600e-07 9.036162e-07 4.721517e-10 2.913558e-07
2 5.122013e-02 3.221749e-07 4.326605e-07 1.331551e-06 5.221886e-09 3.221749e-07
3 1.002133e-01 3.809067e-07 5.525386e-07 1.662368e-06 1.168645e-09 3.809067e-07
```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/102Run SRMHD/AlfenWave benchmarks with LimitingAderDG solver2018-06-15T15:13:43+02:00Ghost UserRun SRMHD/AlfenWave benchmarks with LimitingAderDG solver1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwin...1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwinden die lokalen Oszillationen in der Simulation.
Task d):
1d) Alternative Herangehensweise, von Alejandro vorgeschlagen: LimitingADERDGSolver benutzen. Wir sehen dann vmtl. den Limiter in ExaHyPE öfter aktiviert als im Trento-Code und können über die Ursache dieses Problems nachdenken. Ich bin aber der Meinung damit verschieben wir das Diskussionsthema nur.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/101Run SRMHD AlfenWave benchmark to see the critical grids sizes when timestep i...2018-06-15T15:13:43+02:00Ghost UserRun SRMHD AlfenWave benchmark to see the critical grids sizes when timestep is too big1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwin...1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwinden die lokalen Oszillationen in der Simulation.
Task 1b) and 1c):
1b) Bei welchen Grid-Setups tritt der Fehler auf, bei welchen nicht? Dafür muss ich nochmal alle Settings laufen lassen.
1c) Warum ist das so? Zeitschritte (dt) mit Trento-Code vergleichen. Infrastruktur ist geschrieben, muss ich jetzt noch ausführen.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/100Do we see SRMHD convergence with reduced CFL Factor?2018-06-15T15:13:43+02:00Ghost UserDo we see SRMHD convergence with reduced CFL Factor?1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwin...1. Diskussionpunkt: Zeitschritte bei ExaHyPE scheinen manchmal zu groß gewählt. Dies haben Dominic und ich vor Weihnachten bei SRMHD/AlfenWave gelöst mit pure-ADERDG beobachtet. Wenn wir den CFL_FACTOR = 0.9 auf 0.4 reduzieren, verschwinden die lokalen Oszillationen in der Simulation.
1a) Sehen wir dann auch (endlich) Konvergenz? Muss ich endlich nachprüfen.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/99ADERDG2CartesianVTK vertices plotter refrains to work2018-06-15T15:13:43+02:00Ghost UserADERDG2CartesianVTK vertices plotter refrains to workWith assertions, EulerFlow, no TBB, no MPI, doesn't work any more:
```
0.0138609 info exahype::runners::Runner::createGrid(Repository) finished grid setup after 4 iterations
0.0138698 info exahype::runner...With assertions, EulerFlow, no TBB, no MPI, doesn't work any more:
```
0.0138609 info exahype::runners::Runner::createGrid(Repository) finished grid setup after 4 iterations
0.0138698 info exahype::runners::Runner::runAsMaster(...) start to initialise all data and to compute first time step size
0.0147572 info exahype::runners::Runner::runAsMaster(...) initialised all data and computed first time step size
assertion in file /dev/shm/exabuild-f6cb071ddf-Euler-euler-asserts/./ExaHyPE/exahype/plotters/ADERDG2CartesianVTK.cpp, line 350 failed: _writtenUnknowns==0 || _vertexTimeStampDataWriter!=nullptr
build-euler-asserts: /dev/shm/exabuild-f6cb071ddf-Euler-euler-asserts/./ExaHyPE/exahype/plotters/ADERDG2CartesianVTK.cpp:350: void exahype::plotters::ADERDG2CartesianVTK::plotPatch(const tarch::la::Vector<2, double>&, const tarch::la::Vector<2, double>&, double*, double): Assertion `false' failed.
```
Full run log:
[run-euler-asserts-shuvortex.log](/uploads/b7e9d8a86d4ce9827db9254e054c8f48/run-euler-asserts-shuvortex.log)
Specfile:
[ShuVortexConvergenceTpl.exahype](/uploads/f140d40aa2e3115d7bafdbb96782d989/ShuVortexConvergenceTpl.exahype)
Binary options:
[version.txt](/uploads/3f6358a7c0ba9aad6bbf38bcc6b8299a/version.txt)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/98Scalability Tests (MPI,TBB,MPI+TBB)2019-09-20T15:46:43+02:00Ghost UserScalability Tests (MPI,TBB,MPI+TBB)This is my spreadsheet.
## Tests
Testing scalability with parameters
* dim=2,3,
* p=3,5,7,9
* h=???
## Systems
| system | processor | cores per processor | cores per node | memory per node|
|----------|--------------|-...This is my spreadsheet.
## Tests
Testing scalability with parameters
* dim=2,3,
* p=3,5,7,9
* h=???
## Systems
| system | processor | cores per processor | cores per node | memory per node|
|----------|--------------|-------------------------|-------------------|---------------------- |
| phi1 | 2 Intel Xeon E5-2650 2.0 GHz | 8 cores per processor | 16 cores per node | 64 GByte RAM |
### ADER-DG
Additional parameters:
* ts=fused,standard,
Runs;
* **TBB**
* Strong scaling
* [EulerFlow,2D,phi1,Gnu](/uploads/c4c454dc3c41fe7ee0295a07320db9c7/EulerFlow_TBB_Gnu.tar.gz)
* [Z4,3D,phi1,Gnu](/uploads/4bac6f1c44aa732c4c6c06116f540754/Z4_TBB_Gnu.tar.gz)
* Weak scaling
* **MPI**
* Strong scaling
* Weak scaling
* **MPI+TBB**
* Strong scaling
* Weak scaling
### Godunov FV
Additional parameters:
Comment: Fused time stepping results here in a single sweep scheme.
* ts=fused,standard
Runs;
* **TBB**
* Strong scaling
* Weak scaling
* **MPI**
* Strong scaling
* Weak scaling
* **MPI+TBB**
* Strong scaling
* Weak scaling
### Limiting ADER-DG (ADER-DG + FV)
Comment: Fused time stepping is not supported yet for the
limiting ADER-DG solver.
Additional parameters:
* ts=standard,fused
Runs;
* **TBB**
* Strong scaling
* [EulerFlow,Explosion(t=0.4),2D,phi1,Gnu](/uploads/27c9c32a34c46c75e7d918578972cc7b/EulerFlow_LimitingADERDG_TBB_Gnu.tar.gz)
* Weak scaling
* **MPI**
* Strong scaling
* Weak scaling
* **MPI+TBB**
* Strong scaling
* Weak scaling
## Setting up experiments on Hamilton (Durham's HPC)
Here I will document an (more or less) efficient approach to run the above experiments
on Hamilton.
### Installing the latest ExaHyPE and Peano snapshots
* **Installing ExaHyPE**: Hamilton has git version 1.7.1 installed. Unfortunately, I had login issues while I was trying to clone the ExaHyPE-Engine reppository.
I am thus required to perform a two stage process to get ExaHyPE on my login node.
1. Check ExaHyPE out on my laptop.
2. Optional: scp to mira. Login to mira.
3. scp to hamilton.
* **Installing Peano**: Hamilton has svn version 1.6.11 installed.
* Obtaining Peano is very convenient. It is done via:
``svn checkout http://svn.code.sf.net/p/peano/code/trunk peano``
### Building ExaHyPE
...
### Job scripts
We have currently three different job script "frameworks" available in the ExaHyPE-Engine
repository.
While Dominics job scripts are only suited for TBB on Hamilton and SuperMUC,
Tobias' job script suite is suited to perform MPI and MPI+TBB benchmarks on Hamilton (DUR).
Vasco's python based job script framework can basically run anything on SuperMUC.
I will try to merge the three approaches into a python version with different backends based on the
supercomputer.
* **Tobias'** bash job scripts can be found at ``~/dev/codes/c/ExaHyPE/ExaHyPE-Engine/Miscellaneous/JobScripts/hamilton``.
* **Dominics'** bash job scripts can be found at ``~/dev/codes/c/ExaHyPE/ExaHyPE-Engine/Miscellaneous/JobScripts/scaling``.
* **Vasco's** python job scripts can be found at ``~/dev/codes/c/ExaHyPE/ExaHyPE-Engine/Miscellaneous/JobScripts/``.
### Performance analysis scripts
* **Analysing domain decomposition**: ...
* **Plotting speedups**: ...
### Benchmark March 2017
* Dominic's MPI and MPI+TBB job scripts for Hamilton (SLURM) and SuperMUC (LoadLeveler) [Benchmark_Mar2017.tar.gz](/uploads/1966ff2a9b7d28d12037444fca09e213/Benchmark_Mar2017.tar.gz)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/97Can we re-enable `rtti` with GCC?2018-06-15T15:13:43+02:00Ghost UserCan we re-enable `rtti` with GCC?In https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/2cc375a8 JM added the `-fno-rtti ` flag again for GCC. However, [adding no-rtti just saves some space of the binary while removing introspection/casting features](http://stackoverflo...In https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/2cc375a8 JM added the `-fno-rtti ` flag again for GCC. However, [adding no-rtti just saves some space of the binary while removing introspection/casting features](http://stackoverflow.com/a/4486715), and exactly this happens for me:
```
g++ -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -DAsserts -g3 -DTrackGridStatistics -D__assume_aligned=__builtin_assume_aligned -pipe -pedantic -Drestrict=__restrict__ -Wall -O3 -fno-rtti -march=native -DSharedTBB /usr/include/tbb -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ApplicationExamples/EulerFlow -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/sharedmemoryoracles/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/multiscalelinkedcell/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/tarch/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ExaHyPE -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ApplicationExamples/EulerFlow -c /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/utils/UserInterface.cpp -o /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/utils/UserInterface.o
In file included from /usr/include/tbb/parallel_for.h:28:0,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../tarch/multicore/tbb/Loop.h:2,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../tarch/multicore/Loop.h:4,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../peano/utils/Loop.h:16,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/peano.cpp:2:
/usr/include/tbb/tbb_exception.h: In constructor ‘tbb::movable_exception<ExceptionData>::movable_exception(const ExceptionData&)’:
/usr/include/tbb/tbb_exception.h:274:25: error: cannot use typeid with -fno-rtti
typeid(self_type).name()
^
```
when compiling with
```
COMPILER | GNU
MODE | Asserts
SHAREDMEM | TBB
DISTRIBUTEDMEM | None
```
Full build log at http://sprunge.us/NfCA
So do we keep `no-rtti` or not? With which settings have you tested it, @ga96nuv ?Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/95In asserts mode: "you may not take the indexth entry from a vector with only ...2018-06-15T15:13:43+02:00Ghost UserIn asserts mode: "you may not take the indexth entry from a vector with only Size components"ExaHyPe currently crashes with assertions:
```
2017-01-19 14:03:24 0.0104139 info exahype::runners::Runner::createGrid(...) memoryUsage =33 MB
2017-01-19 14:03:24 0.0104265 info exahype::runners:...ExaHyPe currently crashes with assertions:
```
2017-01-19 14:03:24 0.0104139 info exahype::runners::Runner::createGrid(...) memoryUsage =33 MB
2017-01-19 14:03:24 0.0104265 info exahype::runners::Runner::createGrid(Repository) finished grid setup after 4 iterations
2017-01-19 14:03:24 0.0104377 info exahype::runners::Runner::runAsMaster(...) start to initialise all data and to compute first time step size
2017-01-19 14:03:24 0.0117126 info exahype::runners::Runner::runAsMaster(...) initialised all data and computed first time step size
2017-01-19 14:03:24 assertion in file /home/sven/numrel/exahype/ExaHyPE-Engine/./Peano/mpibalancing/../tarch/la/Vector.h, line 100 failed: index < Size
2017-01-19 14:03:24 parameter index: 2
2017-01-19 14:03:24 parameter Size: 2
2017-01-19 14:03:24 parameter toString(): [0,0]
2017-01-19 14:03:24 parameter "you may not take the indexth entry from a vector with only Size components": you may not take the indexth entry from a vector with only Size components
2017-01-19 14:03:24 ExaHyPE-MHDSolver-p2: /home/sven/numrel/exahype/ExaHyPE-Engine/./Peano/mpibalancing/../tarch/la/Vector.h:100: const Scalar& tarch::la::Vector<Size, Scalar>::operator[](int) const [with int Size = 2; Scalar = double]: Assertion `false' failed.
2017-01-19 14:03:24 Command terminated by signal 6
```
Full log at http://sprunge.us/AHAT
Specfile at http://sprunge.us/SAKehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/94Seperate compiletime (ie. computing) and runtime (ie. physics) variables2018-06-15T15:13:43+02:00Ghost UserSeperate compiletime (ie. computing) and runtime (ie. physics) variablesRegarding the `SRMHD_{InitialData}.exahype` files (as in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/64fc9b9d035be5fc06c9a264ffe5261fefe94785), they only hold two informations:
1. Grid extends (ie. `x_min=..., x_max=...`)
2....Regarding the `SRMHD_{InitialData}.exahype` files (as in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/64fc9b9d035be5fc06c9a264ffe5261fefe94785), they only hold two informations:
1. Grid extends (ie. `x_min=..., x_max=...`)
2. Initial data to use (which *does not work due to broken parser*)
However, the files are highly redundant as they contain all the other information about how to compile, paths and plotters.
I really think there should be two files: One describing the application, compilation information, also the *number of dimensions*, *polynomial order*, as this are all compile time constants.
And one describing the physics, ie. *the grid extend*, arbitrary user constants, constants in exahype like the `CFL number`.
The grid definition is the only reason why users cannot proceed with their own files (we already had the discussion several times). Is there a way to decouple this?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/93Toolkit compilation fails with "TTokenCoupleSolvers.java:30: error: cannot fi...2018-06-15T15:13:43+02:00Ghost UserToolkit compilation fails with "TTokenCoupleSolvers.java:30: error: cannot find symbol"When invoking `make all` or `./build.sh` in the Toolkit directory, an error occurs, ie.
```
javac -sourcepath . eu/exahype/node/TTokenCoupleSolvers.java
eu/exahype/node/TTokenCoupleSolvers.java:30: error: cannot find symbol
((A...When invoking `make all` or `./build.sh` in the Toolkit directory, an error occurs, ie.
```
javac -sourcepath . eu/exahype/node/TTokenCoupleSolvers.java
eu/exahype/node/TTokenCoupleSolvers.java:30: error: cannot find symbol
((Analysis) sw).caseTTokenCoupleSolvers(this);
^
symbol: method caseTTokenCoupleSolvers(TTokenCoupleSolvers)
location: interface Analysis
```
cf.: [toolkit-build.log](/uploads/c8e2870a7b0d9adb8bbed50cc9490a71/toolkit-build.log)
Reported to Tobias at 2016-12-23:
> thanks for the present! Unfortunately, the toolkit no more compiles
> for me. Seems to be a problem with the code generated by SableCC. I'm
> compiling with OpenJDK javac 1.7.0.
Answer:
> probier mal ein make clean. Das ist kein Java-spezifischer Fehler. Das
> ist was Dependencies-meassiges. Kannst auch mal das nodes Verzeichnis
> loeschen. Das war bei mir mal ein Problem,
Make clean doesn't help.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/92Multi-solvers / Parameter Studies / Sensitivity Analysis2019-09-20T15:46:45+02:00Ghost UserMulti-solvers / Parameter Studies / Sensitivity Analysis### Progress:
* Multi-solver infrastructure is implemented for all solvers (ADER-DG,Godunov FV,Limiting ADER-DG).
Further tests and more debugging are necessary for MPI and TBB - especially with respect to the limiting ADER-DG so...### Progress:
* Multi-solver infrastructure is implemented for all solvers (ADER-DG,Godunov FV,Limiting ADER-DG).
Further tests and more debugging are necessary for MPI and TBB - especially with respect to the limiting ADER-DG solver.
### Issues/Features
* 30/12/16: Parameter studies require using the same solver with different initial conditions and/or source terms.
The problem and discretisation (order,variables,plotters,...) of the solver does not change in these studies.
I plan to enable such studies with an annotation {<studyNumber>}, e.g., "solver SolverType MySolver{10}". that is interpreted by the Toolkit
which then creates a constructor that passes the number of the study (0 to 9 in the above example), and
further adds the required number of solvers to the registry.
The current Plotter infrastructure does not support this idea yet because of its dependence on exahype::Parser.
* ~~30/12/16: Limiting-ADER-DG: Limiter domain seems to be required to often while the actual limiter domain does not change per solver.~~ Fixed.
* ~~30/12/16: MPI crashes for multiple ADER-DG/Limiting ADER-DG solvers (seg-fault.)~~ Fixed.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/91ExaHyPE binaries should tell about compile time flags2018-06-15T15:13:44+02:00Ghost UserExaHyPE binaries should tell about compile time flagsSometimes I have an ExaHyPE binary and don't remember with which options I compiled it. I would like to see as much information as possible, for instance:
```
$ ExaHyPE-Euler-p5 --version
This is ExaHyPE.
Compiled at Mon 19 Dec 15:43:36 ...Sometimes I have an ExaHyPE binary and don't remember with which options I compiled it. I would like to see as much information as possible, for instance:
```
$ ExaHyPE-Euler-p5 --version
This is ExaHyPE.
Compiled at Mon 19 Dec 15:43:36 CET 2016
Based on ExaHyPE repository git commit fbec392.
Created with md5sum(ExaHyPE.jar) = xxxxxxxxxx
Built with options:
COMPILER | GNU
MODE | Release
SHAREDMEM | None
DISTRIBUTEDMEM | None
Compiled with gcc v1.2.3.4
Compiled with MPI v2.3.4.5
Compiled with TBB v1.2.3.4
```
Especially the `Mode = Release|Debug|...` would be very helpful.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/90Fix convergence submission <-> reporting interface2018-06-15T15:13:44+02:00Ghost UserFix convergence submission <-> reporting interfaceIt's still broken:
```
...
INFO:ConvergenceTest(EulerShuVortex):Starting p=9, maxmeshsize=1.83333333333 with runTemplatedSpecfile.sh
INFO:ConvergenceTest(EulerShuVortex):Starting p=9, maxmeshsize=0.611111111111 with runTemplatedSpecfile...It's still broken:
```
...
INFO:ConvergenceTest(EulerShuVortex):Starting p=9, maxmeshsize=1.83333333333 with runTemplatedSpecfile.sh
INFO:ConvergenceTest(EulerShuVortex):Starting p=9, maxmeshsize=0.611111111111 with runTemplatedSpecfile.sh
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p7, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p7-meshsize0.203703703704/run-iboga31.log
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p7, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p7-meshsize0.611111111111/run-iboga31.log
INFO:ConvergenceTest(EulerShuVortex):34 processes have been started with PIDS:
INFO:ConvergenceTest(EulerShuVortex):143265 143266 143270 143275 143283 143295 143308 143325 143349 143373 143401 143425 143458 143487 143507 143532 143568 143596 143625 143661 143692 143729 143760 143795 143832 143866 143905 143941 143989 144028 144069 144109 144155 144194
Traceback (most recent call last):
File "./ShuVortexTest.py", line 71, in <module>
ConvergenceFrontend(test, description=__doc__)
File "../libconvergence/convergence_frontend.py", line 53, in __init__
self.actions.call(args.action, self)
File "../libconvergence/convergence_helpers.py", line 278, in call
return self.actions[action_key](selfRef, *args, **kwargs)
File "../libconvergence/convergence_frontend.py", line 109, in startConvergenceTestAndWaitAndReporter
exitcode = self.startConvergenceTestAndWait()
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p8, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p8-meshsize5.5/run-iboga31.log
File "../libconvergence/convergence_helpers.py", line 273, in _impl
method(self, *method_args, **method_kwargs)
File "../libconvergence/convergence_frontend.py", line 103, in startConvergenceTestAndWait
exitcode = self.waitForProcesses(processes)
NameError: global name 'processes' is not defined
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p8, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p8-meshsize1.83333333333/run-iboga31.log
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p8, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p8-meshsize0.611111111111/run-iboga31.log
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p9, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p9-meshsize5.5/run-iboga31.log
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p9, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p9-meshsize1.83333333333/run-iboga31.log
runTemplatedSpecfile.sh: Calling ExaHyPE-Euler-p9, redirecting output to /mnt/beegfs/koeppel/exahype-iboga/ExaHyPE-Engine/Miscellaneous/ConvergenceAnalysis/ShuVortex/simulations/p9-meshsize0.611111111111/run-iboga31.log
koeppel@iboga31 ShuVortex$
` ``https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/89exa compile log should contain everything2018-06-15T15:13:44+02:00Ghost Userexa compile log should contain everything```
Make failed!
Uploading the file extended.log, please send the following link to your collaborators:
http://sprunge.us/GSQA
```
But the link only contains the output of `make`, not the toolkit invocation which is also important somet...```
Make failed!
Uploading the file extended.log, please send the following link to your collaborators:
http://sprunge.us/GSQA
```
But the link only contains the output of `make`, not the toolkit invocation which is also important sometimes. Make sure it contains that, too.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/88Toolkit should fail when python code generator fails2018-06-15T15:13:44+02:00Ghost UserToolkit should fail when python code generator failsSee [toolkit.log](/uploads/ae5aac96264410fadd50bcdc997db2a7/toolkit.log): When invoking an external command fails, java should also fail.See [toolkit.log](/uploads/ae5aac96264410fadd50bcdc997db2a7/toolkit.log): When invoking an external command fails, java should also fail.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/87Let's get rid of the "Code" directory2018-06-15T15:13:43+02:00Ghost UserLet's get rid of the "Code" directoryIn accordance with #86 this proposal suggests that instead of having a repository layout as
```
ExaHyPE-Engine/
├── Code
│ ├── ApplicationExamples
│ ├── Applications
│ ├── CodeGenerator
│ ├── ExaHyPE
│ ├── ExternalLibraries
│ ...In accordance with #86 this proposal suggests that instead of having a repository layout as
```
ExaHyPE-Engine/
├── Code
│ ├── ApplicationExamples
│ ├── Applications
│ ├── CodeGenerator
│ ├── ExaHyPE
│ ├── ExternalLibraries
│ ├── Miscellaneous
│ ├── Peano
│ ├── Toolkit
│ └── UserCodes
├── LICENSE.txt
├── README.md
└── RUN.sh
```
we should have this simpler one:
```
ExaHyPE-Engine/
├── ApplicationExamples
├── CodeGenerator
├── ExaHyPE
├── ExternalLibraries
├── LICENSE.txt
├── Miscellaneous
├── Peano
├── README.md
├── RUN.sh
├── Toolkit
└── UserCodes
```
The idea is when having not a `Code` repository, people don't even plan to create something non-Code-ish in the repository. Which is a good idea.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/86Let's get rid of the "Applications" folder2018-06-15T15:13:43+02:00Ghost UserLet's get rid of the "Applications" folderThis message goes mostly to @di25cox and @ga96nuv as they have worked in folders in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/master/Code/Applications in the last seven days:
As Vasco and me figured out in the last days at ht...This message goes mostly to @di25cox and @ga96nuv as they have worked in folders in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/master/Code/Applications in the last seven days:
As Vasco and me figured out in the last days at https://gitlab.lrz.de/exahype/ExaHyPE-Engine/issues/67#note_38114,
> * `ApplicationExamples` currently holds the public applications
> * `Applications` currently holds the private applications
However, the only "private" applications so far (Z4) moved to an own repository. I would hence suggest to **merge the folders `Applications` and `ApplicationExamples`**.
Please let me know if you have any objectives against.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/85Peano broken once again2018-06-15T15:13:43+02:00Ghost UserPeano broken once againAnd since we only have the tarball in the repository, I cannot do anything else than posting the code that repairs it:
```
sven@nils:~/numrel/exahype/master/Code/Peano/peano/datatraversal/autotuning$ head -n100 OracleForOnePhase.cpp Me...And since we only have the tarball in the repository, I cannot do anything else than posting the code that repairs it:
```
sven@nils:~/numrel/exahype/master/Code/Peano/peano/datatraversal/autotuning$ head -n100 OracleForOnePhase.cpp MethodTrace.cpp
==> OracleForOnePhase.cpp <==
#include "peano/datatraversal/autotuning/OracleForOnePhase.h"
#include "tarch/Assertions.h"
std::string peano::datatraversal::autotuning::toString( const MethodTrace& methodTrace ) {
return "<error>";
}
==> MethodTrace.cpp <==
#include "peano/datatraversal/autotuning/MethodTrace.h"
#include "tarch/Assertions.h"
peano::datatraversal::autotuning::MethodTrace peano::datatraversal::autotuning::toMethodTrace(const std::string& identifier) {
return MethodTrace::NumberOfDifferentMethodsCalling;
}
peano::datatraversal::autotuning::MethodTrace peano::datatraversal::autotuning::toMethodTrace(int identifier) {
return MethodTrace::NumberOfDifferentMethodsCalling;
```
Then it compiles again. Refering to latest commit https://gitlab.lrz.de/gi26det/ExaHyPE/commit/5794462e9dfb71ec2375c95b1ba5ac369c5a8661