ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2019-04-24T23:40:18+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/279Plot NaNs2019-04-24T23:40:18+02:00Ghost UserPlot NaNsVTK is able to visualise NaNs.
Currently, the plotters omit NaNs. This is not necessary.VTK is able to visualise NaNs.
Currently, the plotters omit NaNs. This is not necessary.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/277FV Substeps / Particle Simulations2019-04-23T14:16:30+02:00Ghost UserFV 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/276Fused Time Stepping for LimitingADERDGSolver crashes with MPI if recomputatio...2019-03-29T17:07:03+01:00Ghost UserFused 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.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/275User-friendly API, use AbstractSolver as Adapter2019-07-23T10:40:16+02:00Ghost UserUser-friendly API, use AbstractSolver as AdapterIn order to make the code more easy to use, we could reestablish the MySolver_Variables
data access classes.
We could implement the user hooks that take a raw pointer in the AbstractSolver,
and would then call the user solver's implemen...In order to make the code more easy to use, we could reestablish the MySolver_Variables
data access classes.
We could implement the user hooks that take a raw pointer in the AbstractSolver,
and would then call the user solver's implementation which takes the
data access object as argument.
**Example:**
```
void MyAbstractSolver::adjustPointSolution(double* const Q,...) {
Variables vars(Q);
static_cast<MyUserSolver*>(this)->adjustPointSolution(vars,...);
}
```
We could then have additional data access classes for the full solution array, e.g. ``Solution`` and ``ReadOnlySolution``.
Potentially, we could then introduce dimension-aware iterators with appropriate typecast to
a ``Variables`` or ``ReadOnlyVariables`` object.
This would allow writing code like the following.
**Example:**
```
void MyAbstractSolver::refinementCriterion(ReadOnlySolution solution,...) {
double rhoMax = 0;
for ( ReadOnlyVariables& Q : solution ) {
rhoMax = std::max( Q.rho(), rhoMax );
}
}
```
Remarks
-------
``(ReadOnly)Variables`` and ``Variables`` must be split or declared in such a way that
it is clear that there is not necessarily a contiguous array storing
and variables and parameters. We should get rid of the index operator and
have separate functions ``double`` parameter(int i), ``double& variable(int i)`` instead.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/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/271Specification File Defaults in C++ Parser2019-05-08T13:41:02+02:00Ghost UserSpecification File Defaults in C++ ParserWe have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema....We have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema.
**Edit 2:**
There is now also a C/C++ header-only library for
JSON file validation.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/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/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/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/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/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/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.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/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/260Some nonlinear behavior with MPI2019-01-18T10:27:26+01:00Ghost UserSome nonlinear behavior with MPII got some strange behavior when I try to run GPR on the new skylake i9 here in Trento. The application is the GPR one used with the GPR_2D.exahype spec file. The test is a travelling smooth shock and it runs with non static limiter and ...I got some strange behavior when I try to run GPR on the new skylake i9 here in Trento. The application is the GPR one used with the GPR_2D.exahype spec file. The test is a travelling smooth shock and it runs with non static limiter and AMR. I report some results we got:
2D 4 TBB 1MPI 1 AMR NoOpt ok in 177,54s
2D 4 TBB 1MPI 1 AMR Opt ok in 170,85s
2D 8 TBB 1MPI 1 AMR Opt ok in 145,24
2D 2 TBB 1MPI 1 AMR Opt ok in 292,18
2D 2 TBB 4MPI 1 AMR Opt do not work (issue in musclhancock)
2D 1 and 2 TBB 4MPI 1 AMR Opt using Godunov, do not work, it frozen in initialization and doesn't do anything
2D 1 TBB 4MPI 0 AMR NoOpt using Godunov, it explode
2D 1 TBB 1MPI 0 AMR NoOpt ok in 37,42s (every spawn optimization disabled)
2D 1 TBB 1MPI 1 AMR NoOpt ok in 219.433s (every spawn optimization disabled)
In summary it seems to work all the times we use 1 MPI, more than one seems to be in trouble.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/259TOV Perturbations2019-04-15T12:33:18+02:00Ghost UserTOV 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)