ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2019-03-21T10:41:52+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/266Write plotters which really plot limited DOF where the limiter is active2019-03-21T10:41:52+01:00Ghost UserWrite 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.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/269Carpet Plotter Warnings in 2D2019-03-21T10:41:29+01:00Ghost UserCarpet Plotter Warnings in 2D> In 2D, I get the following warnings all the time. Can you take a look at it:
```
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:202:8: warning: unused variable ‘isNotInAny...> In 2D, I get the following warnings all the time. Can you take a look at it:
```
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:202:8: warning: unused variable ‘isNotInAnyGhostLayer’ [-Wunused-variable]
> bool isNotInAnyGhostLayer = tarch::la::allSmaller(icell,numberOfCellsPerAxis+ghostLayerWidth) && tarch::la::allGreater(icell,ghostLayerWidth-1);
> ^~~~~~~~~~~~~~~~~~~~
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:205:8: warning: unused variable ‘isNotInCornerGhostLayer’ [-Wunused-variable]
> bool isNotInCornerGhostLayer = !(tarch::la::allSmaller(icell, ghostLayerWidth) || tarch::la::allGreater(icell, numberOfCellsPerAxis+ghostLayerWidth));
> ^~~~~~~~~~~~~~~~~~~~~~~
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:207:8: warning: unused variable ‘justIgnoreTheCornerProblem’ [-Wunused-variable]
> bool justIgnoreTheCornerProblem = true;
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.h:177:0,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/parser/Parser.h:33,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Plotter.h:21,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.h:19,
> from /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp:16:
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph: In member function ‘void exahype::plotters::FiniteVolume2Carpet::interpolateCartesianSlicedVertexPatch(const tarch::la::Vector<2, double>&, const tarch::la::Vector<2, double>&, double*, double*, double, const exahype::plotters::CartesianSlicer&)’:
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
> /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./Peano/peano/../tarch/la/Vector.cpph:31:10: warning: array subscript is above array bounds [-Warray-bounds]
> _values[2] = value2;
> ~~~~~~~^
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/265Implement VTU support for Python VTK offline slicer2019-03-21T10:40:44+01:00Ghost UserImplement VTU support for Python VTK offline slicerSven, debug the old python VTK slicer, available at `Miscellenaeowtfusous/PostProcessing/`.
@lbovard please provide some exemplaric VTK/VTU files :-)Sven, debug the old python VTK slicer, available at `Miscellenaeowtfusous/PostProcessing/`.
@lbovard please provide some exemplaric VTK/VTU files :-)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/270Plotting: Obtain number of elements hold by an MPI rank before plotting grid ...2019-03-19T10:00:24+01:00Francesco FambriPlotting: Obtain number of elements hold by an MPI rank before plotting grid sweepI was looking for any strategy able to give me, for every MPI rank, the total number of cells (if possible, distinguishing between limited and non-limited cells).
A possibility was to use the plotpatches of ADERDG, counting unlimited cel...I was looking for any strategy able to give me, for every MPI rank, the total number of cells (if possible, distinguishing between limited and non-limited cells).
A possibility was to use the plotpatches of ADERDG, counting unlimited cells, and of FV, counting limited cells, but the problem is that...
I need this info for the startPlotting of the userdefined Writer, because for my plotter I need to allocate a very big array that, a-priori, should be able to contain all the info that has to be plotted for a given MPI rank.
besthttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/1362D / 3D build check is not performed correctly2019-03-18T21:55:01+01:00Ghost User2D / 3D build check is not performed correctlyWe have a startup check in the code that makes sure that the specfile has some same `const` build constants as for instance the ADERDG polynomial order. However, this test fails for checking that for instance a 2D build is also runned wi...We have a startup check in the code that makes sure that the specfile has some same `const` build constants as for instance the ADERDG polynomial order. However, this test fails for checking that for instance a 2D build is also runned with a 2D grid specification. Thus we get strange errors as in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/10b1261b34e2e239f9a4fe1e2c42f0e38d85a207 :
```
0.0459649 error Invalid simulation end-time: notoken
(file:/home/koeppel/numrel/exahype/Engine-ExaHyPE/./ExaHyPE/exahype/Parser.cpp,line:377)
` ``
And that not after the beginning but after one timestep.
There should be a well-speaking check instead at the beginning.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/273Replace libc assertions by Peano assertions2019-03-18T17:49:44+01:00Ghost UserReplace libc assertions by Peano assertions[LibC assertions](http://www.cplusplus.com/reference/cassert/assert/) are always checked, unless `NDEBUG` is set (we never do that). Instead, we have [Peano assertions](https://gitlab.lrz.de/gi26det/Peano/blob/master/src/tarch/Assertions...[LibC assertions](http://www.cplusplus.com/reference/cassert/assert/) are always checked, unless `NDEBUG` is set (we never do that). Instead, we have [Peano assertions](https://gitlab.lrz.de/gi26det/Peano/blob/master/src/tarch/Assertions.h). `tarch/Assertions.h` also defines the `assert` macro (so one cannot exactly know which one is called, if one is not picky about the include file ordering). **For safety, always use Peanos `assert1` in a one-parametric assertion**.
An instance for a *wrong* use is the current master `minmod` function: https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/master/ExaHyPE/kernels/finitevolumes/musclhancock/c/3d/musclhancock.cpph#L28
It is easy to search other occurances of *wrong* assertion uses.
The overall idea is that in Release mode, such assertions are not checked, especially not on hot paths such as the scalar `minmod` function in the given example.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/272Find out exact properties of the Cactus schemes2019-03-18T14:04:53+01:00Ghost UserFind out exact properties of the Cactus schemes* WhiskyTHC: Find details; probably in papers; maybe find comparisons with other codes
* FIL/IllinoisGRMHD: Run a 2nd order FV Cowling star, in order to compare different codes and see how they compare* WhiskyTHC: Find details; probably in papers; maybe find comparisons with other codes
* FIL/IllinoisGRMHD: Run a 2nd order FV Cowling star, in order to compare different codes and see how they comparehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/264User-defined mesh spacing2019-03-08T21:29:52+01:00Ghost UserUser-defined mesh spacingThe bounding box scaling mechanism introduced to improve the MPI performance of Peano 3 can
be used to move arbitrary numbers of cells out of the domain.
This way we can have arbitrary meshes on the coarse grid.
We could realise familie...The bounding box scaling mechanism introduced to improve the MPI performance of Peano 3 can
be used to move arbitrary numbers of cells out of the domain.
This way we can have arbitrary meshes on the coarse grid.
We could realise families of bipartitioned meshes which is quite useful for
convergence tests.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/227Reflection for the parameter system2019-03-07T20:43:51+01:00Ghost UserReflection for the parameter systemCurrently, using runtime parameters requires to parse them somewhere, leading to code like
```c++
void GeometricBallLimiting::readParameters(const mexa::mexafile& para) {
radius = para["radius"].as_double();
std::string where = para...Currently, using runtime parameters requires to parse them somewhere, leading to code like
```c++
void GeometricBallLimiting::readParameters(const mexa::mexafile& para) {
radius = para["radius"].as_double();
std::string where = para["where"].as_string();
toLower(where);
if(where == "inside") limit_inside = true;
else if(where == "outside") limit_inside = false;
else {
logError("readParameters()", "Valid values for where are 'inside' and 'outside'. Keeping default.");
}
logInfo("readParameters()", "Limiting " << (limit_inside ? "within" : "outside of") << " a ball with radius=" << radius);
}
```
associated to a structure where the parameters are stored,
```c++
struct GeometricBallLimiting : public LimitingCriterionCode {
double radius; ///< Radius of the ball (default -1 = no limiting)
bool limit_inside; ///< Whether to limit inside or outside (default inside)
GeometricBallLimiting() : radius(-1), limit_inside(true) {}
bool isPhysicallyAdmissible(IS_PHYSICALLY_ADMISSIBLE_SIGNATURE) const override;
void readParameters(const mexa::mexafile& parameters) override;
};
```
This is lot's of overhead and really redundant.
In Cactus, the user can declare parameters *including their description/meaning and valid values* in a nice language, they are then made available as a structure by the glue code, all the parsing is abstracted away. Example of a Cactus parameter file (CCL file):
```
real eta "Damping coefficient for the Gamma Driver" STEERABLE=always
{
0:* :: "should be 1-2/M"
}0.2
KEYWORD evol_type "Which set of equations to evolve"
{
"BSSN" :: "traditional BSSN"
"Z4c" :: "Z4c"
"CCZ4" :: "(Covariant) and conformal Z4"
"FOCCZ4" :: "First order formulation of the CCZ4"
}"Z4c"
boolean include_theta_source "Only FO-CCZ4: set to false to remove the algebraic source terms of the type -2*Theta" STEERABLE=always
{
} yes
```
In the code, one then just has something like
```c++
struct parameters {
double eta;
std::string evol_type;
boolean include_theta_source;
}
```
which is already filled nicely with values.
While at least I certainly don't want to code such a glue code for ExaHyPE, in contrast with minimal effort we can get much better then the current MEXA system. In fact, it would be nice to use *OOP reflection* to automatically register class attributes for common data types (int/double/bool/string). That means I would be fine with writing
```c++
struct GeometricBallLimiting {
double radius;
enum class limit_at { inside, outside };
REGISTER_PARAM(radius, DEFAULT(-1), "Radius of the ball");
REGISTER_PARAM(limit_at, DEFAULT(limit_at::inside), "Where to limit");
}
```
In fact, something like this is possible some macro magic.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/225Provide vectorized user functions in the optimized kernels2019-03-07T19:41:41+01:00Ghost UserProvide vectorized user functions in the optimized kernelsThis is something Jean Matthieu should do.
Then we can immediately test a couple of PDEs, such as Euler, GRMHD or CCZ4. Dumbser shared his vectorized code also somewhere.This is something Jean Matthieu should do.
Then we can immediately test a couple of PDEs, such as Euler, GRMHD or CCZ4. Dumbser shared his vectorized code also somewhere.Jean-Matthieu GallardJean-Matthieu Gallardhttps://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/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/130Guidebook: Fix recommendation for MPI Tags for Reductions2019-03-07T19:24:19+01:00Ghost UserGuidebook: Fix recommendation for MPI Tags for ReductionsWhen implementing an own MPI Reductions plotter, the guidebook tells us we should write something like
```
void finishRow() {
#ifdef Parallel
// Question: Do we really reserve a free tag and release on each function call?
c...When implementing an own MPI Reductions plotter, the guidebook tells us we should write something like
```
void finishRow() {
#ifdef Parallel
// Question: Do we really reserve a free tag and release on each function call?
const int reductionTag = tarch::parallel::Node::getInstance().reserveFreeTag(
std::string("TimeSeriesReductions(") + filename + ")::finishRow()" );
if(master) {
double recieved[LEN];
for (int rank=1; rank<tarch::parallel::Node::getInstance().getNumberOfNodes(); rank++) {
if(!tarch::parallel::NodePool::getInstance().isIdleNode(rank)) {
MPI_Recv( &recieved[0], LEN, MPI_DOUBLE, rank, reductionTag, tarch::parallel::Node::getInstance().getCommunicator(), MPI_STATUS_IGNORE );
addValues(recieved);
}
}
} else {
for (int rank=1; rank<tarch::parallel::Node::getInstance().getNumberOfNodes(); rank++) {
if(!tarch::parallel::NodePool::getInstance().isIdleNode(rank)) {
MPI_Send( &data[0], LEN, MPI_DOUBLE, tarch::parallel::Node::getGlobalMasterRank(), reductionTag, tarch::parallel::Node::getInstance().getCommunicator());
}
}
}
tarch::parallel::Node::getInstance().releaseTag(reductionTag);
#endif
if(master) {
TimeSeriesReductions::finishRow();
writeRow();
}
}
```
However I assume this is not that good, looking at the output:
![mpi-reservefreetags](/uploads/de93f1e5c48d10c62101531611e044cd/mpi-reservefreetags.png)
*First question*: Does every plotter need it's own tag? In principal only if they would be called in parallel, isn't it?
In any case, I think the tags should'nt be created so frequently, isn't it? Instead, only once on startup time?
This should be fixed in the guidebook and my code :Dhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/143New template-less pure virtual API2019-03-07T19:23:41+01:00Ghost UserNew template-less pure virtual APITODO: Implement this new API.
![usersolver_layout](/uploads/b314b4b3a6196966cec01c80918fb0c9/usersolver_layout.png)
Tobias favours it. Don't know how it goes with optimized kernels. SMall patch for the piucture from Tobias:
```
/* N...TODO: Implement this new API.
![usersolver_layout](/uploads/b314b4b3a6196966cec01c80918fb0c9/usersolver_layout.png)
Tobias favours it. Don't know how it goes with optimized kernels. SMall patch for the piucture from Tobias:
```
/* NEW: */
kernels::aderdg::generic::c::spaceTimePredictorLinear(BasisSolverAPI& solver, other parameters ... );
```
In textual form [Sketch.h](/uploads/8bcfc8c2920e7532f73e1dac5f8f5a07/Sketch.h)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/268Lucianos tasks as of meeting Thu 2019-03-07, 7pm2019-03-07T17:27:57+01:00Ghost UserLucianos tasks as of meeting Thu 2019-03-07, 7pm![WhatsApp_Image_2019-03-07_at_17.23.40](/uploads/965440c582658dcf300fa06544a0e637/WhatsApp_Image_2019-03-07_at_17.23.40.jpeg)![WhatsApp_Image_2019-03-07_at_17.23.40](/uploads/965440c582658dcf300fa06544a0e637/WhatsApp_Image_2019-03-07_at_17.23.40.jpeg)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/267Domain sizes of TOV star2019-03-07T17:26:15+01:00Ghost UserDomain sizes of TOV starInterior: `[-3,+3]`, `maximum-mesh-size = 0.23`, DG order 3
Plotting repeat: `integrals=0.1, volumetric=0.5`Interior: `[-3,+3]`, `maximum-mesh-size = 0.23`, DG order 3
Plotting repeat: `integrals=0.1, volumetric=0.5`https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/262Get CarpetASCII 1d cut working on different machines such as hazelhen2019-03-06T18:27:47+01:00Ghost UserGet CarpetASCII 1d cut working on different machines such as hazelhenLuke reported that it did not work for him.
But it does no more depend on HDF5 so we should get this working...
@lbovardLuke reported that it did not work for him.
But it does no more depend on HDF5 so we should get this working...
@lbovardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/263Optimised kernels won't compile if Architecture is noarch2019-03-05T22:06:05+01:00Ghost UserOptimised kernels won't compile if Architecture is noarchThe toolkit should stop processing if `Architecture=="noarch" but optimisation="optimised"` is selected and raise an error, instead of building nonworking code which won't compile. Otherwise, users will be confronted with C compiler erro...The toolkit should stop processing if `Architecture=="noarch" but optimisation="optimised"` is selected and raise an error, instead of building nonworking code which won't compile. Otherwise, users will be confronted with C compiler errors like
```
/zhome/academic/HLRS/xfp/xfpskoep/ExaHyPE/Engine/./AstroApplications/CCZ4GRMHD/AbstractCCZ4GRMHDSolver_ADERDG.h(257): error: identifier "ALIGNMENT" is undefined
inline double* allocateArray(const int size) {return ((double* ) _mm_malloc(sizeof(double)*size, ALIGNMENT));}
^
/zhome/academic/HLRS/xfp/xfpskoep/ExaHyPE/Engine/./AstroApplications/CCZ4GRMHD/AbstractCCZ4GRMHDSolver_ADERDG.cpp(89): error: identifier "ALIGNMENT" is undefined
double tempUpdate[CCZ4GRMHD::CCZ4GRMHDSolver_ADERDG_kernels::aderdg::getUpdateSize()] __attribute__((aligned(ALIGNMENT))); // TODO no heap variant implemented
^
```
which are hard to understand.