ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2018-06-15T15:13:43+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/109An idea to solve the double parsing and compile/runtime configuration problem2018-06-15T15:13:43+02:00Ghost UserAn idea to solve the double parsing and compile/runtime configuration problemSimilar to #107, this ticket proposes an idea which solves two problems we currently have in ExaHyPE.
## Problem 1: Double Parsing problem
The ExaHyPE specification files are described by the [exahype.grammar](https://gitlab.lrz.de/exa...Similar to #107, this ticket proposes an idea which solves two problems we currently have in ExaHyPE.
## Problem 1: Double Parsing problem
The ExaHyPE specification files are described by the [exahype.grammar](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/master/Toolkit/exahype.grammar). For the Java toolkit, there is a parser generator (SableCC) which allows a neat way to create the application *during* parsing the specification file. But since the specification file also holds runtime constants, the ExaHyPE binary expects a valid and compatible spec file as it's first argument, ie. call with
```cmd> ExaHyPE-Euler.exe ../EulerFlow.exahype```
In order to parse the specfile at (C++) runtime, there is that [Parser.h](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/master/ExaHyPE/exahype/Parser.h) code. It works with regular expressions and knows nothing about `exahype.grammar`. Thus we sometimes expect that the two parsers don't parse the same spec file similarly or with similar error messages when having problems.
## Problem 2: No clear seperation off compiletime (ie. computing) and runtime (ie. physics) parameters
The current specfile format combines two semantically different concepts of parameters:
* *Computing-related* parameters, ie. project names, source code paths, architecture and compiler specific stuff, optimization parameters, all the PDE properties, all the basic properties about generated code (ie. number and names of classes of plotters)
* *Run-related* parameters, ie. the grid extend, parallelization parameters (number of cores, hybrid setups), plotting properties (frequencies, slicing, ...), physics/application/user parameters (ie. Initial Data, Boundary Conditions)
The user has absolutely no idea which parameter is a compile time constant (and probably even needs a rerun of the toolkit after change) and which parameter is a runtime constant, ie. can be chosen freely when submitting a job at a HPC queue.
Actually this problem is even deeper: There are further constants which can be chosen when running `make`, ie. *after* code generation by the toolkit. These are especially options about the parallelization, ie. whether to build in TBB and MPI support or not. However, these options are also specified in the toolkit.
## A seperation approach
I suggest to keep the specification files for the toolkit runs. I will demonstrate it by splitting the [current EulerFlow.exahype](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/3c8a41ad41a55cab990b0b452fa3cc6e0369b8da/ApplicationExamples/EulerFlow.exahype) into two files. The toolkit specfile would look like:
```
exahype-project Euler
peano-kernel-path = ./Peano
exahype-path = ./ExaHyPE
output-directory = ./ApplicationExamples/EulerFlow
architecture = noarch
computational-domain
dimension = 2
end computational-domain
shared-memory
identifier = dummy
end shared-memory
distributed-memory
configure = {whatever-needs-to-be-generated-here?}
end distributed-memory
solver ADER-DG MyEulerSolver
variables = rho:1,j:3,E:1
order = 3
kernel = generic::fluxes::nonlinear
language = C
plot vtk::Cartesian::cells::ascii ConservedQuantitiesWriter
variables = 5
end plot
plot vtk::Cartesian::vertices::ascii ComputeGlobalIntegrals
variables = 0
end plot
plot vtk::Cartesian::vertices::ascii PrimitivesWriter
variables = 5
end plot
plot vtk::Cartesian::vertices::ascii ExactPrimitivesWriter
variables = 5
end plot
plot probe::ascii ProbeWriter
variables = 5
end plot
end solver
end exahype-project
```
In contrast, we could now introduce a very simple parameter file format where an accurate parser can be written in C++ very simply and which is handed as command line argument to the ExaHyPE runs:
```
# Only single line comments like this
log-file = mylogfile.log
computational-domain::width = 1.0, 1.0
computational-domain::offset = 0.0, 0.0
computational-domain::end-time = 0.12
shared-memory::identifier = dummy
shared-memory::cores = 1 # NB: This should REALLY be driven by an ENV parameter like OMP_NUM_THREADS
distributed-memory::buffer-size = 64
distributed-memory::timeout = 60
optimisation::fuse-algorithmic-steps = off
# 0.0 und 0.8 sind schon mal zwei Faktoren
optimisation::fuse-algorithmic-steps-factor = 0.99
optimisation::timestep-batch-factor = 0.0
optimisation::skip-reduction-in-batched-time-steps = on
optimisation::disable-amr-if-grid-has-been-stationary-in-previous-iteration = off
optimisation::double-compression = 0.0
optimisation::spawn-double-compression-as-background-thread = off
# when this is a runtime constant...
MyEulerSolver::order = 3
# I would love to specify the maximum-mesh-level = 3 instead
MyEulerSolver::maximum-mesh-size = 0.05
# Plotter example
ConservedQuantitiesWriter::time = 0.0
ConservedQuantitiesWriter::repeat = 0.05
ConservedQuantitiesWriter::output = ./conserved
ConservedQuantitiesWriter::select = x:0.0,y:0.0
ComputeGlobalIntegrals::time = 0.0
ComputeGlobalIntegrals::repeat = 0.05
ComputeGlobalIntegrals::output = ./output/these-files-should-not-be-there
ComputeGlobalIntegrals::select = x:0.0,y:0.0
# etc.
# own parameters simple as hell
ML_CCZ4::timelevels = 3
ML_CCZ4::harmonicN = 1.0 # 1+log
ML_CCZ4::harmonicF = 2.0 # 1+log
ML_CCZ4::BetaDriver = 0.4 # ~1/M (\eta)
ML_CCZ4::advectLapse = 1
ML_CCZ4::advectShift = 1
ML_CCZ4::evolveA = 0
ML_CCZ4::evolveB = 1
ML_CCZ4::shiftGammaCoeff = 0.75
ML_CCZ4::shiftFormulation = 0 # Gamma driver
ML_CCZ4::fixAdvectionTerms = 1
ML_CCZ4::dampk1 = 0.05
ML_CCZ4::dampk2 = 0.0
ML_CCZ4::GammaShift = 0.5
ML_CCZ4::MinimumLapse = 1.0e-8
ML_CCZ4::conformalMethod = 1 # 1 for W
ML_CCZ4::dt_lapse_shift_method = "noLapseShiftAdvection"
ML_CCZ4::initial_boundary_condition = "extrapolate-gammas"
ML_CCZ4::rhs_boundary_condition = "NewRad"
Boundary::radpower = 2
ML_CCZ4::ML_log_confac_bound = "none"
ML_CCZ4::ML_metric_bound = "none"
ML_CCZ4::ML_Gamma_bound = "none"
ML_CCZ4::ML_trace_curv_bound = "none"
ML_CCZ4::ML_curv_bound = "none"
ML_CCZ4::ML_lapse_bound = "none"
ML_CCZ4::ML_dtlapse_bound = "none"
ML_CCZ4::ML_shift_bound = "none"
ML_CCZ4::ML_dtshift_bound = "none"
AHFinderDirect::N_horizons = 1
AHFinderDirect::find_every = 64
AHFinderDirect::output_h_every = 0
AHFinderDirect::max_Newton_iterations__initial = 50
AHFinderDirect::max_Newton_iterations__subsequent = 50
AHFinderDirect::max_allowable_Theta_growth_iterations = 10
AHFinderDirect::max_allowable_Theta_nonshrink_iterations = 10
AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation"
AHFinderDirect::geometry_interpolator_pars = "order=4"
AHFinderDirect::surface_interpolator_name = "Lagrange polynomial interpolation"
AHFinderDirect::surface_interpolator_pars = "order=4"
AHFinderDirect::verbose_level = "physics details"
AHFinderDirect::move_origins = "yes"
AHFinderDirect::origin_x[1] = 0.0
AHFinderDirect::initial_guess__coord_sphere__x_center[1] = 0.0
AHFinderDirect::initial_guess__coord_sphere__y_center[1] = 0.0
AHFinderDirect::initial_guess__coord_sphere__z_center[1] = 0.0
AHFinderDirect::initial_guess__coord_sphere__radius[1] = 3.0
AHFinderDirect::which_surface_to_store_info[1] = 0
AHFinderDirect::set_mask_for_individual_horizon[1] = "no"
AHFinderDirect::reset_horizon_after_not_finding[1] = "no"
AHFinderDirect::find_after_individual_time[1] = 2000.0
AHFinderDirect::max_allowable_horizon_radius[1] = 5.0
# ...
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/177Batching required for LTS and ExaHyPE's limiter-based refinement2017-09-04T14:16:41+02:00Ghost UserBatching required for LTS and ExaHyPE's limiter-based refinementLimiting ADER-DG in ExaHyPE
---------------------------
In ExaHyPE, we do not consider adaptive refinement for the Finite Volumes (FV)
solver.
We thus only use FV on the finest level of the adaptive mesh
if we employ a limiting ADER-DG ...Limiting ADER-DG in ExaHyPE
---------------------------
In ExaHyPE, we do not consider adaptive refinement for the Finite Volumes (FV)
solver.
We thus only use FV on the finest level of the adaptive mesh
if we employ a limiting ADER-DG solver.
If a limiting ADER-DG solver detects a shock, i.e. a cell where we need to
limit non-physical oscillations, we refine it down to
the finest adaptive mesh level.
And we further refine its neighbours down to the finest mesh level.
Local Time Stepping
-------------------
TBC
Local Time Stepping plus limiting ADER-DG in ExaHyPE
-----------------------------------------------------
It is possible that a cell is marked as troubled during the
local time stepping. This will require potentially
more refinement around the cell, or to refine the cell itself.
The newly refined cells might not have done any time stepping
at all during the current LTS batch since
their parents stem from a coarser level.
They lag behind in time.
The question is what to do in those scenarios.
Batching
--------
One idea is to consider the number of local time steps to run as a batch.
We remember the solution before a batch starts.
In case (limiter-based) refinement is triggered, we memorise the cells to refine,
perform a rollback to the memorised solution.
Afterwards, we refine the memorised cells and run the batch again.
It can happen multiple times that we have to rerun a batch.
On the other hand, we ensure that our grid is always tracking a shock correctly.
Further techniques
------------------
On the expense of computational cost, we could refine the mesh generously (according to the restricted limiter status)
This would reduce the number of batch reruns.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/114BC: Right handed coordinate system in guidebook2018-06-15T15:13:43+02:00Ghost UserBC: Right handed coordinate system in guidebookCartesian coordinates are by definition *Rechtshändig*, ( https://de.wikipedia.org/wiki/Rechtssystem_(Mathematik) ):
![rechts](https://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Koordinatensysteme_L%2BR.svg/800px-Koordinatensyste...Cartesian coordinates are by definition *Rechtshändig*, ( https://de.wikipedia.org/wiki/Rechtssystem_(Mathematik) ):
![rechts](https://upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Koordinatensysteme_L%2BR.svg/800px-Koordinatensysteme_L%2BR.svg.png)
However, in the guidebook its not:
![dafuq](/uploads/4166e787580d36966833580132607419/dafuq.png)
Also the figure is extremely misleading. I interpret the convention as following:
```
! faces: 0-left, 1-right, 2-front, 3-back, 4-bottom, 5-top
! ie. 0 x=0 1 x=max, 2 y=0 3 y=max 4 z=0 5 z=max
```
As "left", "right", etc. is really not well defined.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/233Begin and End iteration in Solver Class?2019-03-21T10:48:03+01:00Ghost UserBegin and End iteration in Solver Class?Hi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youHi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/155Bounding Box Scaling (virtually-expand-domain) Does Not Work2017-11-02T18:15:15+01:00Ghost UserBounding Box Scaling (virtually-expand-domain) Does Not WorkVirtually expanding the bounding box around the computational domain
is a Peano trick to shut off neighbour communication with the global master (rank 0).
Virtually expanding the bounding box does currently lead to problems in ExaHyP...Virtually expanding the bounding box around the computational domain
is a Peano trick to shut off neighbour communication with the global master (rank 0).
Virtually expanding the bounding box does currently lead to problems in ExaHyPE:
* It enables scenarios where a coarse grid vertex is on the boundary/outside of the domain,
but a fine grid vertex (and its h environment) is inside of the domain.
* It confuses the isFaceInside function in class Cell.
# Virtually Expanding the Domain
Some background on the virtually expand domain flag:
* Peano does only consider inside and boundary vertices for the (MPI) neighbour
merging. Outside vertices are ignored for this purpose.
* Since rank 1 is placed into a centre of 3^d child cells belonging to rank 0,
it will perform neighbour merging with rank 0 as long as those vertices are
either inside or directly at the boundary of the domain.
* Switching off neighbour merging directly at the domain boundary (``vertex.isBoundary()``) does not
make sense. The reason is that refinement at the boundary will introduce hanging nodes.
Boundary nodes should however be persistent. (Tobias' reasoning. Have to ask further why this is bad.)
* Virtually expanding the domain does place the nodes located at the remote boundary to
rank 0 outside of the domain
* From the above points, it is clear that virtually expanding the boundary is mandatory for reasonable MPI
scalability especially in 3d. This is exactly what we have observed in our 3D MPI experiments.
* This will be a little inconvenient for people who prescribe initial conditions at certain boundaries by means of (x,t).
(Seismic people know about this. Leonhard knows how to deal with it.)
# Remarks
* Virtually expanding the bounding box usually leads to a shrinking of the actual computational domain since
only inside cells are considered as within the computational domain.
ExaHyPE should thus tell the user what the shrinked domain looks like.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/171Bug in LimitingADERDGSolver MPI implementation2018-03-20T16:14:23+01:00Ghost UserBug in LimitingADERDGSolver MPI implementationMin and max is not send correctly to neighbour if Heap neighbour comm. is
configured as non-blocking (CreateCopiesOfSentData=false).Min and max is not send correctly to neighbour if Heap neighbour comm. is
configured as non-blocking (CreateCopiesOfSentData=false).https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/176Bug in optimised kernel generation for limiting ader-dg solver2017-09-06T13:58:22+02:00Ghost UserBug in optimised kernel generation for limiting ader-dg solverInclude file is wrong. Is <MySolver>_ADERDG.h for Limiting-ADER-DG solver.
```
/ddn/home/jdmd33/dev/ExaHyPE-Engine/./Benchmarks/hamilton/Euler/kernels/EulerSolver/stableTimeStepSize.cpp(7): catastrophic error: cannot open source file "E...Include file is wrong. Is <MySolver>_ADERDG.h for Limiting-ADER-DG solver.
```
/ddn/home/jdmd33/dev/ExaHyPE-Engine/./Benchmarks/hamilton/Euler/kernels/EulerSolver/stableTimeStepSize.cpp(7): catastrophic error: cannot open source file "EulerSolver.h"
#include "EulerSolver.h"
^
```Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/189Bug in Solver mesh level computation if bounding box is virtually expanded2017-10-11T16:47:02+02:00Ghost UserBug in Solver mesh level computation if bounding box is virtually expandedThere is a bug in the mesh level computation if the boundy box is virtually expanded:
```
_coarsestMeshLevel =
exahype::solvers::Solver::computeMeshLevel(_maximumMeshSize,domainSize[0]);
```
Then, ``_domainSize != _boundingBoxSize``.There is a bug in the mesh level computation if the boundy box is virtually expanded:
```
_coarsestMeshLevel =
exahype::solvers::Solver::computeMeshLevel(_maximumMeshSize,domainSize[0]);
```
Then, ``_domainSize != _boundingBoxSize``.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/150Buildinfo infrastructure does not update always2017-11-02T18:15:16+01:00Ghost UserBuildinfo infrastructure does not update alwaysThe `buildinfo.h` file is generated at every make call, but the macros are evaluated in `main.cpp` only once, ie. the main file compilation is not retriggered.
To avoid this, we could must have the buildinfo an own compilation context, ...The `buildinfo.h` file is generated at every make call, but the macros are evaluated in `main.cpp` only once, ie. the main file compilation is not retriggered.
To avoid this, we could must have the buildinfo an own compilation context, ie some `buildinfo.cpp` going along with the `buildinfo.h`. That's the only option to get runtime build information.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/97Can we re-enable `rtti` with GCC?2018-06-15T15:13:43+02:00Ghost UserCan we re-enable `rtti` with GCC?In https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/2cc375a8 JM added the `-fno-rtti ` flag again for GCC. However, [adding no-rtti just saves some space of the binary while removing introspection/casting features](http://stackoverflo...In https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/2cc375a8 JM added the `-fno-rtti ` flag again for GCC. However, [adding no-rtti just saves some space of the binary while removing introspection/casting features](http://stackoverflow.com/a/4486715), and exactly this happens for me:
```
g++ -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -DAsserts -g3 -DTrackGridStatistics -D__assume_aligned=__builtin_assume_aligned -pipe -pedantic -Drestrict=__restrict__ -Wall -O3 -fno-rtti -march=native -DSharedTBB /usr/include/tbb -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ApplicationExamples/EulerFlow -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/sharedmemoryoracles/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/multiscalelinkedcell/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/tarch/.. -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ExaHyPE -I/dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./ApplicationExamples/EulerFlow -c /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/utils/UserInterface.cpp -o /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/utils/UserInterface.o
In file included from /usr/include/tbb/parallel_for.h:28:0,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../tarch/multicore/tbb/Loop.h:2,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../tarch/multicore/Loop.h:4,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/mpibalancing/../peano/utils/Loop.h:16,
from /dev/shm/exabuild-f6cb071ddf-Euler-euler-tbb-asserts/./Peano/peano/peano.cpp:2:
/usr/include/tbb/tbb_exception.h: In constructor ‘tbb::movable_exception<ExceptionData>::movable_exception(const ExceptionData&)’:
/usr/include/tbb/tbb_exception.h:274:25: error: cannot use typeid with -fno-rtti
typeid(self_type).name()
^
```
when compiling with
```
COMPILER | GNU
MODE | Asserts
SHAREDMEM | TBB
DISTRIBUTEDMEM | None
```
Full build log at http://sprunge.us/NfCA
So do we keep `no-rtti` or not? With which settings have you tested it, @ga96nuv ?Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/219Cancel all predictor background jobs when a predictor rerun is necessary2018-03-26T11:15:21+02:00Dominic Etienne CharrierCancel all predictor background jobs when a predictor rerun is necessaryhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/269Carpet Plotter Warnings in 2D2019-03-21T10:41:29+01:00Sven KöppelCarpet 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/256CarpetHDF5 Writer lacks Dataset support2018-11-01T17:30:43+01:00Sven KöppelCarpetHDF5 Writer lacks Dataset supportfrom rug:
```
realname = hfile["Parameters and Global Attributes/Datasets"].value.decode("ascii")[:-1]
```
lacks dataset name
```
sven@nils:/tmp/hdf5$ rug window -f 'log10(y)' whatever.h5 0
Traceback (most recent call last):
...from rug:
```
realname = hfile["Parameters and Global Attributes/Datasets"].value.decode("ascii")[:-1]
```
lacks dataset name
```
sven@nils:/tmp/hdf5$ rug window -f 'log10(y)' whatever.h5 0
Traceback (most recent call last):
File "/home/sven/bin/rug", line 265, in <module>
modules.call(args)
File "/home/sven/numrel/ET/rugutils/modules.py", line 68, in call
return function(**given_args)
File "/home/sven/numrel/ET/rugutils/window.py", line 173, in window
realname, struct = read_file_structure(hfile, name)
File "/home/sven/numrel/ET/rugutils/read_hdf5.py", line 165, in read_file_structure
realname = hfile["Parameters and Global "
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2847)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2805)
File "/usr/lib/python3/dist-packages/h5py/_hl/group.py", line 167, in __getitem__
oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2847)
File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper (/build/h5py-qzs83i/h5py-2.7.1/h5py/_objects.c:2805)
File "h5py/h5o.pyx", line 190, in h5py.h5o.open (/build/h5py-qzs83i/h5py-2.7.1/h5py/h5o.c:3738)
KeyError: "Unable to open object (object 'Datasets' doesn't exist)"
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/206CCZ4: Run BH until T=10002018-02-09T22:50:28+01:00Sven KöppelCCZ4: Run BH until T=1000We need some setup of ExaHyPE,CCZ4+Limiter on a reasonable grid (L>25, dx<0.1). This ticket shall report the progress. Just describe your runs in the comments.
*Explanation of notation: The unit "M/h" means "simulation time / physical t...We need some setup of ExaHyPE,CCZ4+Limiter on a reasonable grid (L>25, dx<0.1). This ticket shall report the progress. Just describe your runs in the comments.
*Explanation of notation: The unit "M/h" means "simulation time / physical time in hours". M means "Mass" and roughly indicates for us that we refer to the simulation time.*https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/205CCZ4: Run BH with2018-01-20T20:50:14+01:00Sven KöppelCCZ4: Run BH withhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/200Cell-wise plotter2017-11-29T17:45:59+01:00Ghost UserCell-wise plotterCreate a VTK plotter which only plots a single cell. Plot then:
* LimitingStatus
* Which MPI rank hosts the cell
This also should support VTU (for MPI).Create a VTK plotter which only plots a single cell. Plot then:
* LimitingStatus
* Which MPI rank hosts the cell
This also should support VTU (for MPI).https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/126CFL factor per solver as const int the specfile2019-04-15T12:37:03+02:00Ghost UserCFL factor per solver as const int the specfileThis reduces inconsistencies. Can now be easily generated as constexpr double into the AbstractMySolver class.This reduces inconsistencies. Can now be easily generated as constexpr double into the AbstractMySolver class.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/51Clean up Cell.cpp and mappings2016-12-21T16:01:26+01:00Ghost UserClean up Cell.cpp and mappingsExplicit separation ADER-DG and FV solvers. They are not distinguished by a CellDescription field "solverType" anymore.Explicit separation ADER-DG and FV solvers. They are not distinguished by a CellDescription field "solverType" anymore.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/201Clean up vertical MPI communication2019-09-20T15:46:26+02:00Dominic Etienne CharrierClean up vertical MPI communicationThere is too much data sent around.
I further use too many different structures and methods
(MeshUpdateFlags,SolverFlags,solver->sendDataToWorker/Master...).
This should be cleaned up.There is too much data sent around.
I further use too many different structures and methods
(MeshUpdateFlags,SolverFlags,solver->sendDataToWorker/Master...).
This should be cleaned up.Dominic Etienne CharrierDominic Etienne Charrierhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/120Cleanup generic kernels2018-06-15T15:13:43+02:00Ghost UserCleanup generic kernelsIts producing a lot of warnings, ie.
```
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels....Its producing a lot of warnings, ie.
```
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h:222:0,
from /media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:13:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/solutionAdjustment.cpph: In instantiation of ‘void kernels::aderdg::generic::c::solutionAdjustment(SolverType&, double*, const tarch::la::Vector<3, double>&, const tarch::la::Vector<3, double>&, double, double) [with SolverType = GRMHD::GRMHDSolver]’:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:84:115: required from here
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/solutionAdjustment.cpph:49:19: warning: unused variable ‘dofStartIndex’ [-Wunused-variable]
const int dofStartIndex = nodeIndex * numberOfVariables;
^
In file included from /media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h:227:0,
from /media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:13:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/dummyK_Kernel.cpph: In instantiation of ‘void kernels::aderdg::generic::c::dummyK_Kernel(SolverType&, double, double, const tarch::la::Vector<3, double>&, const tarch::la::Vector<3, double>&, int, int, int, double*) [with SolverType = GRMHD::GRMHDSolver]’:
/media/storage/numrel/exahype/ExaHyPE-Engine/./ApplicationExamples/GRMHD/AbstractGRMHDSolver.cpp:115:209: required from here
/media/storage/numrel/exahype/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/c/3d/dummyK_Kernel.cpph:30:10: warning: unused variable ‘x0’ [-Wunused-variable]
double x0[3];
```
also get rid of `malloc`, use stack.