ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2019-04-23T14:16:30+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/277FV Substeps / Particle Simulations2019-04-23T14:16:30+02:00Dominic Etienne CharrierFV Substeps / Particle SimulationsAdd possibility to choose FV patch time step size freely.
This should be done when we implement anarchic time stepping
for the limiting ADER-DG solver.
Furthermore, there should be the possibility to override
the generated Limiter solver...Add possibility to choose FV patch time step size freely.
This should be done when we implement anarchic time stepping
for the limiting ADER-DG solver.
Furthermore, there should be the possibility to override
the generated Limiter solver class in order to plug in
other projectors.
Rollbacks are difficult to implement with anarchic time stepping.
I have no clue how to do this yet.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/222Fix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpph2019-04-15T12:41:12+02:00Sven KöppelFix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpphFrom a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the tim...From a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the time since program start.
>
In ExaHyPE, the grid setup sometimes takes a considerable amount --
like 10 minutes. If you measure the M/h straight after the first
timesteps after these 10 minutes, you get of course totally wrong
numbers. However, if you measure after 1000 minutes runtime, the 10
minutes grid setup do not change the result so much.
>
It is not hard to substract the time the grid setup needs in order to
improve the correctness of the number. You can do this either by hand
(just look up when the first time step started) or we can do this in
code (CCZ4/Writers/TimingStatisticsWriter.cpph).Sven KöppelSven Köppelhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/244Toolkit2: Should have --pretend and --clean option2019-04-15T12:40:31+02:00Sven KöppelToolkit2: 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/209Toolkit should accept command line arguments for finetuning2019-04-15T12:40:31+02:00Sven KöppelToolkit 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/208Random initial conditions for LimitingADERDGSolver pose a problem2019-04-15T12:39:44+02:00Dominic Etienne CharrierRandom initial conditions for LimitingADERDGSolver pose a problemCurrently, random initial conditions likely lead to undefined
behaviour for the LimitingADERDGSolver.
Background
-----------
The LimitingADERDGSolver replaces the ADER-DG solution locally by a FV solution
if the former does not satisfy...Currently, random initial conditions likely lead to undefined
behaviour for the LimitingADERDGSolver.
Background
-----------
The LimitingADERDGSolver replaces the ADER-DG solution locally by a FV solution
if the former does not satisfy certain conditions (PAD, DMP).
During the imposition of initial conditions, we then allocate a new FV patch and
impose the initial conditions on its FV solution degrees of freedom.
Random initial conditions
-------------------------
We have to ensure that FV and ADER-DG solution are consistent.
This is currently only ensured if we have deterministic initial conditions.
In case of random initial conditions, the imposition of initial conditions
on the ADER-DG solution and on the FV solution might lead to two different
outcomes.
A cell might encounter rough initial conditions while imposing the initial conditions
on the ADER-DG solution but it then might encounter smooth initial conditions
for the FV solution.
But more severely, both differ from each other.
A solution?
-----------
In case a cell allocates an FV patch and has a limiter status such that it will
compute with Finite Volumes in the first iteration, we will then treat this FV solution as
the correct one and will project it back on the ADER-DG solution.
This way ADER-DG and FV solution are consistent.
On the other hand, if the limiter status of the cell is such that the cell
will compute with ADER-DG in the first iteration, we will treat the ADER-DG solution as the correct
one, we will project the ADER-DG solution onto the FV solution. We will not impose initial
conditions on the FV solution.
FV and ADER-DG solution are consistent in this case as well.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/37Precision issues2019-04-15T12:37:23+02:00Ghost UserPrecision issuesI observed that we can only apply the restriction and prolongation operations
a certain number of times until the projected constant values in my test are not equal anymore
to the reference values (with respect to a tolerance of 1e-12)....I observed that we can only apply the restriction and prolongation operations
a certain number of times until the projected constant values in my test are not equal anymore
to the reference values (with respect to a tolerance of 1e-12).
For more infos see the todos in 2D and 3D definitions of
GenericEulerKernelTest::testFaceUnknownsProjection(),
and
GenericEulerKernelTest::testVolumeUnknownsProjection()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/249Toolkit2: Proper handling of parameters to plotters2019-04-15T12:36:17+02:00Sven KöppelToolkit2: 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/215User Defined plotters API: Pass the information from the specfile2019-04-15T12:36:16+02:00Sven KöppelUser Defined plotters API: Pass the information from the specfileHow can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is so...How can we access:
* Name of output file
* Full information about cell (Limiting status, etc.)
I think the plotting API is hiding too much information. The UserDefinedADERDG plotter should pass more information to the user.
This is something I can do :)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/224Numerical details how to evolve CCZ4 with FD2019-04-15T12:34:55+02:00Sven KöppelNumerical details how to evolve CCZ4 with FDCollection of what was written by Dumbser in various E-Mails in order to proceed in the Runge Kutta - Finte Differencing code (Cactus/Antelope/Okapi):
### Dumbser, 3. April 2018 um 11:03: FO-CCZ4 with Finite differencing works
> since S...Collection of what was written by Dumbser in various E-Mails in order to proceed in the Runge Kutta - Finte Differencing code (Cactus/Antelope/Okapi):
### Dumbser, 3. April 2018 um 11:03: FO-CCZ4 with Finite differencing works
> since Sven has reported some difficulties with the implementation of FO-CCZ4 in the Einstein toolkit last week, and since I wanted to understand the potential problems in depth, I have simply written my own finite difference code for the Einstein equations, based on central finite differences in space and Runge-Kutta time integration. According to Sven's and Elias' description, this is exactly what you are also doing in Cactus, right? The implementation is straightforward, since FD schemes are extremely simple.
>
>
>
> To do my tests, I have just copy-pasted my Fortran subroutine PDEFusedSrcNCP into the finite difference code, and I then insert FD point values of Q and central FD approximations for the first spatial derivatives. To save CPU time, I have done all computations in 1D so far.
>
>
>
> Please find attached the results that I have obtained for the Gauge wave with amplitude A=0.01 and A=0.1 until a final time of t=1000. I have used sixth order central FD in space and a classical third order Runge-Kutta scheme in time. For FO-CCZ4, I have set all damping coefficients to zero (kappa1=kappa2=kappa3=0), and I use c=0 with e=2. Zero shift (sk=0) and harmonic lapse. CFL number based on e is set to CFL=0.5 at the moment. Now the important points:
>
>
>
> 1. Runge-Kutta O3 is for now preferrable over Runge-Kutta O4, since it is intrinsically dissipative. The reason is that the fourth order time derivative term in the Taylor series on the left hand side remains with RK3, while it cancels with RK4, and when moving the term q_tttt to the right hand side and after Cauchy-Kowalevsky procedure, it becomes a fourth order spatial derivative term with negative sign, which is good for stability (second spatial derivatives must have positive sign on the right hand side, fourth spatial derivatives must have negative sign for stability. this is easy to check via Fourier series and the dispersion relation of the PDE).
>
>
>
> 2. The RK3 alone is not enough to stabilize the scheme for the larger amplitude A=0.1 of the Gauge Wave, but it is sufficient for A=0.01. I therefore explicitly needed to subtract a term of the type - dt/dx*u_xxxx, which is essentially a fourth order Kreiss-Oliger-type dissipation with appropriately chosen viscosity coefficient.
>
>
>
> I will now replace the Kreiss-Oliger dissipation which I do not like with the numerical dissipation that you would have obtained with a Rusanov flux in a fourth order accurate finite volume scheme. In the end, the dissipation operator will again be written as a finite difference, but there I know at least exactly what is going on and we will exactly know the amount of dissipation to be put (it can only be a function of the largest eigenvalue). So there will be NO parameter to be tuned. I will keep you updated on this.
>
>
>
> From my own results I can conclude that everything is working as expected, i.e. you must have at least one bug in your implementation of FO-CCZ4 in Cactus; or you have run the tests with the wrong parameters (please use CFL=0.5 for the moment, Kreiss-Oliger dissipation with a viscosity factor so that you get -dt/dx*u_xxxx on the right hand side in the end, please set kappa1=kappa2=kappa3=0 and set e=2 and c=0 in FO-CCZ4). If your code still does not run, I can send you my finite difference Fortran code to help you with the debugging.
>
>
>
> While running and implementing my FD code for FO-CCZ4 I have also been working on the vectorization of FO-CCZ4 in ADER-DG. The interesting news: the finite difference code requires more than 20 microseconds per FD point update, and ADER-DG with the good new initial guess for the space-time polynomial and proper vectorization needs also about 20 microseconds per DOF update for FO-CCZ4, i.e. ADER-DG is indeed becoming competitive with FD, who would have every believed this last year :-) On the new 512bit vector machines of RSC in Moscow, we expect the PDE to run even twice as fast, since the vector registers are twice as large as the current state of the art. We are aiming at a time per DOF update of about 10 microseconds. I will keep you informed.
### Dumbser, 4. April 2018 um 10:51:
>
However, my latest experiments show that you can also use RK4 together with a finite-volume type dissipative operator, which is very simple to
implement and which does not require any parameters to be tuned. It will just replace the Kreiss-Oliger dissipation. And by the way: in this setting,
the scheme can be run with CFL=0.9, which is what we want. I will send around more details later.
### Dumbser, 4. April 2018 um 18:23
> there are again good news from the finite difference for FO-CCZ4 front. Instead of your classical Kreiss-Oliger dissipation, I suggest to use the following dissipation operator, which should simply be "added" to the time derivatives of
>
> all quantities on the right hand side, i.e.:
>
>
> ```
> dudt(:,i,j,k) = dudt(:,i,j,k) - 1.0/dx(1)* 3.0/256.0* smax * ( -15.0*u(:,i+1,j,k)-u(:,i+3,j,k)-15.0*u(:,i-1,j,k)+6.0*u(:,i+2,j,k)+20.0*u(:,i,j,k)+6.0*u(:,i-2,j,k)-u(:,i-3,j,k) )
> ```
>
>
> where dudt(:,i,j,k) is the time derivative of the discrete solution computed by the existing Fortran function PDEFusedSrcNCP and smax is the maximum eigenvalue in absolute value. This operator derives from
>
>
> ```
> - 1/dx(1)*( fp - fm ),
> ```
>
>
> where the dissipative flux fp is defined as
>
>
> ```
> fp = - 1/2 * smax * ( uR - uL ),
> ```
>
>
> and uR and uL are the central high order polynomial reconstructions of u evaluated at the cell interface x_i+1/2. The flux fm is the same, but on the left interface x_i-1/2.
>
>
>
> Please find attached the new results for the Gauge Wave with A=0.1 amplitude. Everything looks fine, i.e., the ADM constraints as well as the waveform at the final time. Note that this simulation was now run with the fourth order
> Runge-Kutta scheme in time and using a CFL number of CFL=0.9 based on the maximum eigenvalue.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/223Implement new Space time predictor without (variable number of) picard loops2019-04-15T12:34:30+02:00Sven KöppelImplement new Space time predictor without (variable number of) picard loopsThe task is relatively easy: Diff Dumbsers fortran prototype (in repository) and check out the changes in the generic kernels.
From Dumbser, 11. März 2018 um 11:20:
> Wäre natürlich super, wenn Du meinen Fortran Code in C übersetzen kö...The task is relatively easy: Diff Dumbsers fortran prototype (in repository) and check out the changes in the generic kernels.
From Dumbser, 11. März 2018 um 11:20:
> Wäre natürlich super, wenn Du meinen Fortran Code in C übersetzen könntest.
> Wenn es Probleme gibt,
> machen wir wieder eine Skype session.
> Das Format der Schleifen und der nötigen Berechnungen ist quasi dasselbe wie
> für alle anderen Rechnungen
> im space-time predictor, d.h. da kann man sehr viel übernehmen. Nur, dass
> man den Zeitindex nicht mehr
> mitschleppen muss, sondern nur im Raum arbeiten kann. Der einzige Kernel der
> geändert werden muss ist der
> space-time predictor (in 2D und 3D).
>
> Ich würde nur den second und third order initial guess implementieren, siehe
> den Code in
> SpaceTimePredictor.f90 unter
>
> #ifdef SECOND_ORDER_INITIAL_GUESS
>
> #ifdef THIRD_ORDER_INITIAL_GUESS
>
> Ich habe mich diese Woche auf Scaling und den Vergleich Runge-Kutta DG /
> ADER-DG konzentriert,
> d.h. an dem 2D FO-fCCZ4 habe ich nicht mehr weitergearbeitet. Ich will erst
> das GRMHD Paper vom
> Tisch haben.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/259TOV Perturbations2019-04-15T12:33:18+02:00Sven KöppelTOV Perturbations*This is an old textual note which I digitize here because I throw the textual one away. Has to be sorted in accordingly*
Plan from an old coding week:
* Trento: Artificial viscosity
* Frankfurt: Perturbed TOV, with THC, FIL
Perturb...*This is an old textual note which I digitize here because I throw the textual one away. Has to be sorted in accordingly*
Plan from an old coding week:
* Trento: Artificial viscosity
* Frankfurt: Perturbed TOV, with THC, FIL
Perturbations:
1. `p = alpha * p_0`
2. `rho = rho_0 * (1 + alpha * cos(2pi r/R))`
Trento codes:
* Tractor: AMR-3D (=all features, but slow)
* Ferrari: ADER-DG (=prototype, clean, vectorized, fast, but only unigrid and no limiter)Sven KöppelSven Köppelhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/276Fused Time Stepping for LimitingADERDGSolver crashes with MPI if recomputatio...2019-03-29T17:07:03+01:00Dominic Etienne CharrierFused Time Stepping for LimitingADERDGSolver crashes with MPI if recomputation is triggeredNonfused variants seem to work fine.
EDIT: A run with generic kernels and noarch did not crash.Nonfused variants seem to work fine.
EDIT: A run with generic kernels and noarch did not crash.Dominic Etienne CharrierDominic Etienne Charrierhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/175Symbolic flux calculations reduce speed significantly2019-03-21T10:56:35+01:00Ghost UserSymbolic flux calculations reduce speed significantlyI just completed some Likwid performance measurements for the generic and optimised kernels.
For the optimised kernels, I tested a variant using "symbolic variables" in the
flux and eigenvalue computation and another variant using
classi...I just completed some Likwid performance measurements for the generic and optimised kernels.
For the optimised kernels, I tested a variant using "symbolic variables" in the
flux and eigenvalue computation and another variant using
classic array indexing (optimised-nonsymbolic).
The files are suffixed by a ".likwid.csv".
I further attached measured Peano adapter times
The files are suffixed by a ".csv".
Setup
--------
* Compressible Euler equations (Euler_Flow)
* pure ADER-DG scheme (no limiter)
* polynomial orders p=3,5,7,9;
regular 27^3 grid (3D)
* TBB threads=1,12,24.
* Intel icpc17 (USE_IPO=on).
* nonfused (3 algorithmic phases) vs. fused (a single pipelined algorithmic phase) ADER-DG implementation
* no predictor reruns did occur for the fused implementation
Preliminary Results
----------------------------
* Optimised kernels are faster than the generic ones (I kind of expected this 😉)
* Raw array access (optimised-nonsymbolic) is significantly faster than using the "symbolic variables"(optimised).
* Fused scheme pays off (as long as number of reruns is low; very interesting for linear PDEs (no reruns here))
Files
-----
[Euler_ADERDG-no-output-generic.csv](/uploads/f671c93a33e70c9549853f1f51518c9d/Euler_ADERDG-no-output-generic.csv)
[Euler_ADERDG-no-output-generic.likwid.csv](/uploads/0d52ad214f0b1d6cfae4d658a9997cb5/Euler_ADERDG-no-output-generic.likwid.csv)
[Euler_ADERDG-no-output-optimised.csv](/uploads/422288cdc222b1b250b3aad9e2ad73a1/Euler_ADERDG-no-output-optimised.csv)
[Euler_ADERDG-no-output-optimised-nonsymbolic.csv](/uploads/0f84240941230d4bc9f06c76b154396b/Euler_ADERDG-no-output-optimised-nonsymbolic.csv)
[Euler_ADERDG-no-output-optimised.likwid.csv](/uploads/135bd71c668ca0c4c4ee5b7988ea2f17/Euler_ADERDG-no-output-optimised.likwid.csv)
[Euler_ADERDG-no-output-optimised-nonsymbolic.likwid.csv](/uploads/7606eefe559499a1f6de62b5f33905d0/Euler_ADERDG-no-output-optimised-nonsymbolic.likwid.csv)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/202Segfault in some VTK plotters if variables = 02019-03-21T10:48:34+01:00Ghost UserSegfault in some VTK plotters if variables = 0https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/233Begin and End iteration in Solver Class?2019-03-21T10:48:03+01:00Ghost UserBegin and End iteration in Solver Class?Hi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youHi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/245Toolkit2: Allow users to share binaries, move them accross computers, etc.2019-03-21T10:47:08+01:00Sven KöppelToolkit2: Allow users to share binaries, move them accross computers, etc.The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises p...The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises problems in certain use cases:
* The user shares his Executable to another user on the system/cluster but does not make the access permissions correctly for the Toolkit
* The user copies only the Executable to another machine but not the overall Code (especially not the Toolkit code)
* The user renames the path to his installation (probably when cleaning up his home directory) but wants to keep an ExaHyPE build working (obviously this is not possible)
We have no solution for all these use cases, but we should include checks in the C++ code to deal with them:
* Check whether `Path/to/Toolkit/toolkit.sh` exists, is readable and executablehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/242Toolkit2: Fix old merge2019-03-21T10:46:28+01:00Sven KöppelToolkit2: Fix old mergehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix though):
* Make sure you are using `ValueError` instead of `JSONDecodeError(ValueError)`.
Otherwise, the code requires python3 version>=3.5.0.
This is a typical error message you get:
```
controller.py:215(getSpec):ERROR Could not read specification file '../Euler_ADERDG.exahype': 'module' object has no attribute 'JSONDecodeError'
```
* Make sure `mexa.py` is python3.
I regex-replaced
`print (".+"\s*(%\s*\(.+\))?)$` with `print(\1)`https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/236Make mexa more friendly in ExaHyPE2019-03-21T10:45:51+01:00Sven KöppelMake mexa more friendly in ExaHyPECurrently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind...Currently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind of too noisy and should instead print something more human-readable (such as `foo = bar [ref]` instead `eq(foo, bar, ref)`), probably one `tarch:::logInfo` per line.
* In the current usage, `foo = mf[key].as_double()` where `mf` is a mexafile, if the key is in the wrong data type (in this example: not castable as double), it spills out an error message *without* any reference where the error occured, only way to find it is to start with `gdb` and to go up the stack trace. This is exactly against the philosophy of mexa where the parameter source should *always* be dragged along, also with the `mexa::value` type. This needs to be implemented and tested.Sven KöppelSven Köppelhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/266Write plotters which really plot limited DOF where the limiter is active2019-03-21T10:41:52+01:00Sven KöppelWrite 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.Sven KöppelSven Köppel