ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2019-03-21T10:41:29+01:00https://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/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/258Minfy JSON (filter out comments and son) before deserialisation2018-11-13T18:10:26+01:00Ghost UserMinfy JSON (filter out comments and son) before deserialisationThe JSON parser allows specifying a callback for this purpose:
```
/** [...]
@param[in] i input to read from
@param[in] cb a parser callback function of type @ref parser_callback_t
which is used to control the deseriali...The JSON parser allows specifying a callback for this purpose:
```
/** [...]
@param[in] i input to read from
@param[in] cb a parser callback function of type @ref parser_callback_t
which is used to control the deserialization by filtering unwanted values
(optional)
*/
static basic_json parse(detail::input_adapter&& i,
const parser_callback_t cb = nullptr,
const bool allow_exceptions = true)
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/249Toolkit2: Proper handling of parameters to plotters2019-04-15T12:36:17+02:00Ghost UserToolkit2: 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/246Toolkit2: If it is configure, it should test the make system2018-09-01T15:54:55+02:00Ghost UserToolkit2: If it is configure, it should test the make systemCodes using the popular [Autotools/Autoconf ecosystem](https://www.gnu.org/software/autoconf/manual/autoconf.html) expect users to compile code by something like
```
wget http://example.com/code.tar.gz && unpack || git clone ...
./confi...Codes using the popular [Autotools/Autoconf ecosystem](https://www.gnu.org/software/autoconf/manual/autoconf.html) expect users to compile code by something like
```
wget http://example.com/code.tar.gz && unpack || git clone ...
./configure --with-MPI --with-TBB --without-lapack
make
```
Configure does several things, but typically it
* Checks whether the neccessary *compilers and libraries* are installed by doing test compilations and executions
* Generates a Makefile
We probably all dislike configure for doing these lengthy tests which always consume time.
In similarity to *configure*, some ExaHyPE users (notably Dominic) interpret the ExaHyPE toolkit as a *configure step*:
```
wget http://exahype.eu/obtain/exahype.tar.gz ...
./toolkit.sh PathToSpecfile.exahype
make
```
We know this analogy at least does not hold because some build decisions are made at making time, for instance the choice for MPI, TBB and Assertions. Our toolkit never executes any compiler, it only generates code. There is a clean distinction.
However, frequently compilation fails and users must find out why. What a real *configure* step would provide is a check for compiler capabilities. With tough problems, users have to debug these capabilities anyway, for instance by [compiling and running my compiler challanges](https://bitbucket.org/svek/compiler-challenges).
I suggest we add an option `--test` to the Toolkit which brings in some *configure* flavour. When enabled, after the invocation of the regular Toolkit it could compile and run some tests and test for
* A valid C++11 and Fortran (long lines + REAL=8 bytes) compiler (test programs)
* Presence of a modern and working TBB (test program)
* Presence of a working MPI (test program)
Of course, running these tests probably requires to have some flags such as `EXAHYPE_CC` already set.
As an alternative, I suggest we have another Makefile target for our make system: `make test`, which does not compile the code but instead compiles (and runs) these tests.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/244Toolkit2: Should have --pretend and --clean option2019-04-15T12:40:31+02:00Ghost UserToolkit2: 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/243Toolkit2: Create .gitignore2018-09-05T14:23:33+02:00Ghost UserToolkit2: Create .gitignoreWe could think about such an option to let the toolkit create a `.gitignore` in the output directory. That could hold something like
```
Abstract*
KernelCalls*
README_generated.md
```
However, these files are not solver-name-dependent ...We could think about such an option to let the toolkit create a `.gitignore` in the output directory. That could hold something like
```
Abstract*
KernelCalls*
README_generated.md
```
However, these files are not solver-name-dependent and easy to track in the global `.gitignore`, too.
Would a local `.gitignore` have any features beyond?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/241Improve Plotter infrastructure2018-09-04T20:38:44+02:00Ghost UserImprove Plotter infrastructureThis is a long term goal:
The plotters were growing features in a weird way with tons of code duplication and the fact that now some plotters have features which others don't and there is no obvious reason why (for instance: VTK Legendr...This is a long term goal:
The plotters were growing features in a weird way with tons of code duplication and the fact that now some plotters have features which others don't and there is no obvious reason why (for instance: VTK Legendre basis plotter cannot do patchwise mapping of quantities while VTK Cartesian basis plotter can).
The obvious answer to this problem is *abstraction*. I already started once when introducing a `Slicer` interface class to allow various kind of slicing operations without having to specify them in the individual plotters. They just pass the parameters given by the specfile.
In a similar way, we need more abstraction for the quantities mapping, for labeling of the written quantities (named instead of `Q0...QN`), interpolation on different subcell grids, Support of the *isTroubled* flag or in general bitmasks of patch statusses, etc. The following picture is a sketchy overview:
![plotters](/uploads/876457ebab375ee2e1a15bd32a43c1f3/plotters.png)
To be honest I made this ticket here only becaue I wanted to throw away that sketch paper. It is at least one year old.
Figure as PDF: [Sbizhub1318082520330.pdf](/uploads/d4279ca1621927df8155582c66726dd0/Sbizhub1318082520330.pdf)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/232EulerFV headers2018-07-25T12:41:20+02:00Ghost UserEulerFV headersHi,
in EulerFV there seems to be a mismatch/inconsistency between the MyEulerSolver.cpp and MyEulerSolver.h
on the repository this is the function used:
void EulerFV::MyEulerSolver::eigenvalues(const double* const Q, const int normalNo...Hi,
in EulerFV there seems to be a mismatch/inconsistency between the MyEulerSolver.cpp and MyEulerSolver.h
on the repository this is the function used:
void EulerFV::MyEulerSolver::eigenvalues(const double* const Q, const int normalNonZeroIndex, double* lambda)
but there is no such signature in the header generated by the toolkit. I assume const int normalNonZeroIndex, const int d and const int dIndex refer to the same variable.https://gitlab.lrz.de/exahype/ExaHyPE-Documentation/-/issues/3Peano linking2018-07-05T12:43:18+02:00Ghost UserPeano linkingHi,
is it possible to update the documentation on linking Peano to ExaHyPE. Chapter 1 doesn't seem to be valid anymore. Currently when a user clone exahype there are symbolic links already in place in the Peano folder. Does the user sim...Hi,
is it possible to update the documentation on linking Peano to ExaHyPE. Chapter 1 doesn't seem to be valid anymore. Currently when a user clone exahype there are symbolic links already in place in the Peano folder. Does the user simply need to clone peano in submodules folder or is there a script to run?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/230In-Code documentation of "adjustSolution" function2018-06-21T14:16:01+02:00Ghost UserIn-Code documentation of "adjustSolution" functionIs it possible to add a comment for adjustSolution() in the header.
/**
* @see FiniteVolumesSolver
*/
void adjustSolution(const double* const x,const double t,const double dt, double* Q) override;
Also is there a...Is it possible to add a comment for adjustSolution() in the header.
/**
* @see FiniteVolumesSolver
*/
void adjustSolution(const double* const x,const double t,const double dt, double* Q) override;
Also is there any advise on how to get the corner points of the cell. I guess there was a adjustPointSolution() in the past but not anymore.https://gitlab.lrz.de/exahype/ExaHyPE-Documentation/-/issues/2Guidebook and header comments2018-11-13T17:19:38+01:00Ghost UserGuidebook and header commentsGuidebook page 39, "There is a routine adjustPointSolution that allow us to setup the initial grid. Alternatively, we can also use adjustSolution". There is only one function named adjustSolution in the solver.
Also header of adjustSol...Guidebook page 39, "There is a routine adjustPointSolution that allow us to setup the initial grid. Alternatively, we can also use adjustSolution". There is only one function named adjustSolution in the solver.
Also header of adjustSolution() in mysolver.h says "@see FiniteVolumesSolver" which doesn't exist.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/229Add level as parameter to adjustSolution function2018-06-19T11:10:57+02:00Ghost UserAdd level as parameter to adjustSolution functionThe seismic applications need this for topology interpolation.The seismic applications need this for topology interpolation.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/228stableTimeStepSize kernels should return maximum eigenvalue for (classical) l...2018-06-14T16:10:38+02:00Ghost UserstableTimeStepSize kernels should return maximum eigenvalue for (classical) local time steppingIn general, we cannot associate the smallest time step size with the finest mesh
level as there might be larger eigenvalues present on coarser mesh levels.
This is an issue for local time stepping where you scale the smallest time
step ...In general, we cannot associate the smallest time step size with the finest mesh
level as there might be larger eigenvalues present on coarser mesh levels.
This is an issue for local time stepping where you scale the smallest time
step size by a factor k (k=3 in Peano) with decreasing mesh level.
The kernels should thus return the maximum eigenvalue, too, or only the maximum eigenvalue.
The minimum local time step size would then be computed according to:
```
dt_min = CFL * max_{over all cells} lambda / min_{over all cells} cellSize
```
which is different to what we are currently doing for global time stepping:
```
dt_min = CFL * min_{over all cells} ( lambda / cellSize )
```
The ADERDGSolver superclass would then decide which minimisation to
perform.