ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2017-11-21T13:40:26+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/170Clear out the private member variables in the solvers2017-11-21T13:40:26+01:00Ghost UserClear out the private member variables in the solversMany of the private member variables in in the ADERDGSolver,FiniteVolumesSolver,
LimitingADERDGSolver can be computed. This includes cardinalities.
Only store the order of approximation, number of variables and number of parameters.
Comp...Many of the private member variables in in the ADERDGSolver,FiniteVolumesSolver,
LimitingADERDGSolver can be computed. This includes cardinalities.
Only store the order of approximation, number of variables and number of parameters.
Compute all other cardinalities; provide getter functions.
- It would be better if the optimised solver would dismiss the "getBnd.." functions and would
overwrite the existing, now virtual, "getUnknowns..." and "getData.." functions.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/162Combine adapters SolutionUpdate and TimeStepSizeComputation2017-08-16T13:06:55+02:00Ghost UserCombine adapters SolutionUpdate and TimeStepSizeComputation......https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/299Compilation error2019-10-16T10:05:11+02:00Duo Lid.li@lmu.deCompilation errorI compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument...I compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lQhbnd, _MM_HINT_NTA);
^
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(43): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lFhbnd, _MM_HINT_NTA);
^
compilation aborted for /import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp (code 2)
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.o’ failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/298Compilation error in peano::heap2019-09-17T12:34:46+02:00Duo Lid.li@lmu.deCompilation error in peano::heap/exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDro.../exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDropReceivedBoundaryData"
peano::heap::AbstractHeap::allHeapsDropReceivedBoundaryData();
^
compilation aborted for /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp (code 2)
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.o' failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/61Compile time constants should be available as static const2018-06-15T15:13:43+02:00Ghost UserCompile time constants should be available as static constCurrently, we do have
```c
int exahype::solvers::Solver::getNumberOfVariables() const {
return _numberOfVariables;
}
```
as a method in the Solvers. However, this is not accessible at user kernels as the Solver object is no more acce...Currently, we do have
```c
int exahype::solvers::Solver::getNumberOfVariables() const {
return _numberOfVariables;
}
```
as a method in the Solvers. However, this is not accessible at user kernels as the Solver object is no more accessible. As these are compile time constants, they should be generated by the code, ie. in a file like [GeneratedConstants.h](https://gitlab.lrz.de/gi26det/ExaHyPE/blob/85cc9213e8fa71aea55e7063067285d68fae965d/Code/ApplicationExamples/SRHD/GeneratedConstants.h):
```c
#ifndef __MY_GENERATED_CONSTANTS__
#define __MY_GENERATED_CONSTANTS__
/**
* These constants should be created by the toolkit instead
* of scattering numbers around in the code. The practice to
* write naked numbers somewhere, as in
* ADERDGSolver("SRHDSolver", 3, 2, ...)
* is called "magic numbers" and they are accepted as bad
* coding practice.
*
* As we currently cannot run the toolkit for SRHD,
* these constants have to be always kept equal to the
* toolkit.
*
**/
static const int MY_POLYNOMIAL_DEGREE = 1;
static const int MY_NUMBER_OF_VARIABLES = 5;
static const int MY_NUMBER_OF_PARAMETERS = 0;
#endif /* __MY_GENERATED_CONSTANTS__ */
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/125Compiling on the cluster, notes2018-06-15T15:13:43+02:00Ghost UserCompiling on the cluster, notesFirst: SVN is old and breaks generate-buildinfo.sh, almost fixed.
Second: MPI/TBB, all that, is ugly:
```
mpiicpc -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -restrict -xHost -O3 -no-ipo -ip...First: SVN is old and breaks generate-buildinfo.sh, almost fixed.
Second: MPI/TBB, all that, is ugly:
```
mpiicpc -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -restrict -xHost -O3 -no-ipo -ip -DSharedTBB -DParallel -DMPICH_IGNORE_CXX_SEEK /usr/include/tbb -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ApplicationExamples/EulerFlow -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/mpibalancing/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/sharedmemoryoracles/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/multiscalelinkedcell/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/tarch/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ExaHyPE -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ApplicationExamples/EulerFlow -c /home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/grid/TraversalOrderOnTopLevel.cpp -o /home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/grid/TraversalOrderOnTopLevel.o
icpc: error #10236: File not found: '/usr/include/tbb'
```
on LOEWE after
```
$ module list
Currently Loaded Modulefiles:
1) slurm/2.6.3 3) mpi/mvapich2/intel-17.0.1/2.2 5) intel-tbb-oss/intel64/40_20120613oss
2) intel/compiler/64/17.0.1 4) mpi/intel/4.1.0.024
```
I think the `tbb` path is in some `ENV` var, should not be assumed at `/usr/include/tbb`.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/110Compression2018-06-15T15:13:07+02:00Ghost UserCompression## TODO
* ~~add "hint-size" to the relevant compression fields.~~
* support the Finite Volumes solver degrees of freedom## TODO
* ~~add "hint-size" to the relevant compression fields.~~
* support the Finite Volumes solver degrees of freedomhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/180Compression - take ghostLayers and padding into account2017-09-26T10:19:58+02:00Ghost UserCompression - take ghostLayers and padding into account- FiniteVolumesSolver - Compression should take ghostLayers+padding (alignment) into account
- ADERDGSolver - Compression should take padding (alignment) into account- FiniteVolumesSolver - Compression should take ghostLayers+padding (alignment) into account
- ADERDGSolver - Compression should take padding (alignment) into accounthttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/153Constants in specfiles2018-09-10T19:42:06+02:00Ghost UserConstants in specfilesI have too much constants that a specfile syntax
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size...I have too much constants that a specfile syntax
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = initial_data:tovstar,boundary_x_lower:reflective,boundary_y_lower:reflective,boundary_z_upper:outgoing,tovstar-mass:1.234,tovstar-rl-ratio:2.345
```
would make sense. Tobias thinks in such a case a user would do something like
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = configuration-file:foobar.txt
```
and outsource the configuration in a language the user likes. However, this breaks with the idea of a single specfile for a single run. Therefore, I see two options
## Add a DATA section after the specfile
This is what many script languages do, for instance perl ([the DATA syntax in perl](https://stackoverflow.com/questions/13463509/the-data-syntax-in-perl)). The idea is just that the parsers ignore what goes after the end of the specfile (ie. the line containing `end exahype-project`). Users could dump there any content in their favourite language. I would vote for this as it is super easy to implement, allows file concatenation and flexibility.
## Allow user constant section
We could also just allow users to do something like
```
solver Limiting-ADER-DG GRMHDSolver
variables const = rho:1,vel:3,E:1,B:3,psi:1,lapse:1,shift:3,gij:6
order const = 4
maximum-mesh-size = 6.0009
maximum-mesh-depth = 0
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
constants = parameters:appended
limiter-kernel const = generic::musclhancock
limiter-language const = C
dmp-observables = 2
dmp-relaxation-parameter = 1e-2
dmp-difference-scaling = 1e-3
steps-till-cured = 0
simulation-parameters
foo = bar
baz = bar
blo = bar
blu = bar
etc.
end simulation-parameters
plot vtk::Cartesian::vertices::limited::binary ConservedWriter
variables const = 19
time = 0.0
repeat = 0.00166667
output = ./vtk-output/conserved
end plot
...
```
This would go well with the specfile syntax. In order to implement, we need
* Such a section with any key-value pairs added to the grammar, so the toolkit does not complain
* Support in the `Parser.cpp` (which is not too hard to add)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/66Correctness of Finite Volume SRHD Shocktube2018-06-15T15:13:43+02:00Ghost UserCorrectness of Finite Volume SRHD ShocktubeThe `SRHD_FV` application currently holds the SRHD shocktube. Jean-Matthieu asks
>
Well the question was if the result is correct or not. It looks nice but since we are no expert we didn't knew if it was also correct.
and indeed he is...The `SRHD_FV` application currently holds the SRHD shocktube. Jean-Matthieu asks
>
Well the question was if the result is correct or not. It looks nice but since we are no expert we didn't knew if it was also correct.
and indeed he is right. We had a conversation at https://exahype-dev.slack.com/messages/@jm/ which brought me to commits https://gitlab.lrz.de/gi26det/ExaHyPE/commit/9a01da27c2282c6fbd3273f8e5dfc54abc6a4ca1 (+ following ones) to implement primitive output at SRHD(_FV). We do have values significantly nonzero:
![visit0002](/uploads/2c7cd59243d003aeaf3b12ea5d8916cb/visit0002.png)
This ticket shall track the progress here.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/184Decompose mapping Merging into two mappings2017-11-21T13:39:29+01:00Ghost UserDecompose mapping Merging into two mappingsMapping merging does currently perform neighbour merges (touchVertexFirstTime etc.) as well as the
merging of the time step data from the master with the worker.
Often only a merging of time step data is necessary. The touchVertexFirstTi...Mapping merging does currently perform neighbour merges (touchVertexFirstTime etc.) as well as the
merging of the time step data from the master with the worker.
Often only a merging of time step data is necessary. The touchVertexFirstTime merges
then reduce to a nop. In a shared memory context, this means that we add unnecessary overhead.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/221Deeply check the public repository for CCZ42019-03-07T19:41:06+01:00Ghost UserDeeply check the public repository for CCZ4It is at https://github.com/exahype/exahype and we don't want to have the CCZ4 system in the code or any old commits. Make this sure by inspecting the code.
Cannot do it now since the repo is 70MB in size and I'm in a train with a bad w...It is at https://github.com/exahype/exahype and we don't want to have the CCZ4 system in the code or any old commits. Make this sure by inspecting the code.
Cannot do it now since the repo is 70MB in size and I'm in a train with a bad wifi.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/261Delete branch sven/ccz4-testcase from Engine repository again2019-02-27T18:12:37+01:00Ghost UserDelete branch sven/ccz4-testcase from Engine repository againhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/sven/ccz4-testcase
This is only for Jenkins testing. Should never be merged in master.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/tree/sven/ccz4-testcase
This is only for Jenkins testing. Should never be merged in master.https://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/123Derivative plotter, part 22018-06-15T15:13:43+02:00Ghost UserDerivative plotter, part 2We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is ...We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is something I can try to do.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/70Discussion topics for a discussion ("Coding") day at Oct 23., 2016 in Munich2018-06-15T15:13:43+02:00Ghost UserDiscussion topics for a discussion ("Coding") day at Oct 23., 2016 in Munich* Kernel situation
* Trento will not be able to implement new numerics into C++ "nested loop" kernels
* We invested two weeks of finding bugs porting Fortran Z4 to ExaHyPE -- this is a dead end!
* We either need modern Fortran kern...* Kernel situation
* Trento will not be able to implement new numerics into C++ "nested loop" kernels
* We invested two weeks of finding bugs porting Fortran Z4 to ExaHyPE -- this is a dead end!
* We either need modern Fortran kernels or a good C++ linear algebra library (there are plenty of them)
* (Generic) research kernels might be in a different shape than optimized kernels!
* What is ExaHyPE?
* If it shall be a standalone *application*, then it should provide the best support for parameters, etc. as possible
* If it shall serve as a "utility", end users have to come up with individual solutions on theirselves. Both is fine, but there should be a common idea everybody is aware of.
* Workflow
* Durham cannot provide implementation support (code monkeying) for ExaHyPE applications in this intensity anymore
* Frankfurt cannot provide support for running benchmarks and (parameter) test in this intensity anymore
* Fortran situation in Applications
* MHD was converted to C++ with surprising results in stability and speed
* What's the joint aim for the team? There is more and more Fortran code (Applications get bigger), cf. the `Z4` application
* API and Code Generation
* Kernel calls should be method calls instead of templated static function calls
* Toolkit only needs to provide initial "scaffold" code. In 90% of applications, generated code is now in the repo, edited after generation and gets overwritten regularly.
* Toolkit should not distribute constants in the generated code but collect them in a unique file (`GeneratedConstants.h`). Paradigm: Generate maintainable code.
* Specification file format
* There is a lot to say here. We should aggree on a whishlist of features
* We could also agree to keep the spec files small and let the problem be solved by the users
* Treatment of external libraries and the build system
* Today is already tomorrow -- I have secretly introduced dependencies on GSL, BLAS due to the Astrophysics Initial Data codes.
* A decision should also affect the treatment of Peano.
* IO
* VTK Fileformat (alternatives)
* Does it make sense to define a tailored ExaHyPE output format ourselves?
* Efficient batch processing 3D VTK to movie plotting
* Unit tests
* Mathematically/Physically, there is little point in testing the numerical scheme with random data at every ExyHyPE `DEBUG or Asserts` run.
* Instead, simple but well understood tests with analytic solutions should be run (ie. via Jenkins). We should come up with a list of these tests (ie: Advection, ShuVortex, MHD Wave, Gauge Wave, etc.)
*Please just add points to this list as you whish*
# Assignments in Discussion at 25. Oct 2016
At Oct 25, in Garching there were Tobias, Vasco, Dominik, Alejandro and Sven. We discussed these points and even more and concluded these assignments:
* Fortran support (VV)
* Call linear kernels with temp arrays (DC)
* Non-conservative parts (SK) - done, cf. https://gitlab.lrz.de/gi26det/ExaHyPE/commit/1723512d16acbf118f43465d78d252cda55e9bc6 and similar
* Split of the repositories (SK) - tracked at gi26det/ExaHyPE#55
* Start the release page & remove binaries from GIT (VV) - as followup for gi26det/ExaHyPE#55, right?
* Find new Jour Fix time (incl. Dominic and Trento) (VV)
* Nightly convergence tests (SK+VV) - tracked at gi26det/ExaHyPE#74
* Period BCs: Organise small coding week in Durham (VV+TW)
* Replace static function + templates with std::function (SK+TW) - tracked at gi26det/ExaHyPE#75
* Extend Solver::solutionAdjustment to handle point sources (DC+VV)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/159DMP is illegally called for ordinary ADERDG-Solver2017-11-02T18:15:15+01:00Ghost UserDMP is illegally called for ordinary ADERDG-SolverThis are actually two problems:
1. For an ordinary ADERDG-Solver (not Limiter) where the variable `dmp-observables` is not given, the default value is **not** `0` but instead just a random number (NaN or MaX or whatever for int). ...This are actually two problems:
1. For an ordinary ADERDG-Solver (not Limiter) where the variable `dmp-observables` is not given, the default value is **not** `0` but instead just a random number (NaN or MaX or whatever for int). This is very bad but solvable in the Parser for me.
2. The method `mapDiscreteMaximumPrincipleObservables` in the abstract ADERDG solver is called. This should not happen at all! Why does it happen?
![dmp](/uploads/fd5837af72fe6f92e871426712399023/dmp.png)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/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/169Do not impose initial conditions in every mesh refinement iteration2017-11-21T13:42:50+01:00Ghost UserDo not impose initial conditions in every mesh refinement iterationIt turned out that this is quite costly.
It might be responsible for time outs encountered during the
initial grid setup.
Min and max search:
--------------------
- This should be done once in FinaliseMeshRefinement
since we have a lar...It turned out that this is quite costly.
It might be responsible for time outs encountered during the
initial grid setup.
Min and max search:
--------------------
- This should be done once in FinaliseMeshRefinement
since we have a larger concurrency level here.
- We further should move around some of the behaviour of LocalRecomputation
into FinaliseMeshRefinement.