ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2017-08-16T20:03:29+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/167Grid cells are not erased properly2017-08-16T20:03:29+02:00Ghost UserGrid cells are not erased properly... only the cell description is deleted. Empty remains in the grid.
Furthermore, we do not erase all cells and cell descriptions at the end of the simulation.
We rely on the OS's process manager to free the application memory.... only the cell description is deleted. Empty remains in the grid.
Furthermore, we do not erase all cells and cell descriptions at the end of the simulation.
We rely on the OS's process manager to free the application memory.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/162Combine adapters SolutionUpdate and TimeStepSizeComputation2017-08-16T13:06:55+02:00Ghost UserCombine adapters SolutionUpdate and TimeStepSizeComputation......https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/165Minimise limiter status based halo refinement2017-08-15T16:59:19+02:00Ghost UserMinimise limiter status based halo refinementIf the a-posteriori troubled cell indicators indicate a troubled cell, we refine
this cell down to the finest mesh level specified by the user.
I further have to ensure that I can place helper cell layers around the troubled cell
also o...If the a-posteriori troubled cell indicators indicate a troubled cell, we refine
this cell down to the finest mesh level specified by the user.
I further have to ensure that I can place helper cell layers around the troubled cell
also on the finest mesh level. Thus, I need some halo refinement.
Currently, I refine all neighbours of a cell with limiter status 1 and 2 in order to ensure
that the diagonal neighbours are refined as well.
In principle, I could however refine the cells with have a limiter status of 1 and
the cells which have two neighbours with a limiter status 1.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/168Metadata-merging currently not done properly2017-08-14T12:53:04+02:00Ghost UserMetadata-merging currently not done properlyMy latest changes introduced a bug into codes using AMR or LimitingADERDGSolver:
There is only a merge of local metadata performed in the first iteration.My latest changes introduced a bug into codes using AMR or LimitingADERDGSolver:
There is only a merge of local metadata performed in the first iteration.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/161AMR+Limiting leads to dispersion errors2017-07-13T12:35:21+02:00Ghost UserAMR+Limiting leads to dispersion errors![amr_limiter_error](/uploads/4f1591cfd8d0db8a2fbc76675deec3a6/amr_limiter_error.png)
* Shock is not at the correct position.
* Problem appears for both, Godunov and MUSCL-Hancock methods.
* Problem affects MUSCL-Hancock more
P...![amr_limiter_error](/uploads/4f1591cfd8d0db8a2fbc76675deec3a6/amr_limiter_error.png)
* Shock is not at the correct position.
* Problem appears for both, Godunov and MUSCL-Hancock methods.
* Problem affects MUSCL-Hancock more
Problem is not solved yet
https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/164Extrapolate space-time polynomials and wrap boundary condition imposition in ...2017-07-12T20:24:40+02:00Ghost UserExtrapolate space-time polynomials and wrap boundary condition imposition in time-integralThis will further be a first step for local time steppingThis will further be a first step for local time steppinghttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/163Have a maximum-timestep-size in the spec file2017-07-12T17:49:05+02:00Ghost UserHave a maximum-timestep-size in the spec fileThis value can then be used to prescribe a time step size as long.
As the solver does not require a smaller one at least.This value can then be used to prescribe a time step size as long.
As the solver does not require a smaller one at least.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/47Peano FileWriter should create directories or quit program2017-01-27T12:28:32+01:00Ghost UserPeano FileWriter should create directories or quit programIn order to preserve a clean directory structure, my ExaHyPE specification files write the solutions into a **subdirectory**,
```
plot vtk::binary
time = 0.0
repeat = 0.004
output = ./output/solution
...In order to preserve a clean directory structure, my ExaHyPE specification files write the solutions into a **subdirectory**,
```
plot vtk::binary
time = 0.0
repeat = 0.004
output = ./output/solution
select = {all}
end plot
```
However, if this subdirectory `output/` does not exist, `tarch` (component of Peano) writes an error everytime it is supposed to write something out:
```
1265.35 error tarch::plotter::griddata::unstructured::vtk::VTKBinaryFileWriter::close() unable to write output file ./output/solution-49.vtk
```
However, the simulation does **not** stop but just runs until the end. Afterwards, there are no results anywhere, nothing has been written out. This is not helpful but wastes computing power if something went wront.
* Simple solution: An error of tarch should stop the simulation.
* Nicer solution: The code should create the directory structure for the output files. This is not complicated at all, eg. there is [Boosts `create_directories`](http://www.boost.org/doc/libs/1_57_0/libs/filesystem/doc/reference.html#create_directories). (Yes I know, Tobias does not want any dependency like boost... You know what? You could just copy the neccessary functions)Tobias WeinzierlTobias Weinzierlhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/49More control over initial data creation2017-01-27T12:27:52+01:00Ghost UserMore control over initial data creationThere are plenty of cases where I have the strong whish to break out of Peano's *Hollywood principle*. Another case is that I really need more control when setting up the initial data. I know some codes which work, in pseudo code, like
...There are plenty of cases where I have the strong whish to break out of Peano's *Hollywood principle*. Another case is that I really need more control when setting up the initial data. I know some codes which work, in pseudo code, like
```
Begin Program
Startup: Populate grid with initial data.
Load files, etc, then loop over grid and set data.
Evolution:
do loop over timesteps
WaveToyC: Evolution of 3D wave equation
t = t+dt
Do the online analysis part
Write out data if neccessary
enddo
End Program.
```
This allows typical use cases for the inital data as opening files where to read initial data from (for instance, data created with the [LORENE](http://www.lorene.obspm.fr/) code), or checking parameters and precomputing quantities how to compute the intitial data. For instance, in Astrophysics there are quite easy codes to create simple space times (TOV, discs) but they cannot *just return* the wanted quantities in a
```c++
void getInitialDataAt(const double* pointCenter, double* theQplease);
```
fashion. Instead, they precompute grid transformations, potentials, etc. There has to be a place where they can do that, naturally on a per-process but not per-thread basis.
Just to turn the tables, how idiotic the following pseudo code would be:
>
> FUNCTION getIntialDataAt(a point, returning the Q):
> * somehow retrieve the initial data properties from environment variables or open and parse another config file
> * 300 lines of code computing global derived quantities from the properties, solving several integrals and sums etc.
> * Interpolation of data on a rectangular grid with dx spacing (I have programs where this interpolation takes 40 minutes)
> * Throwing away everything and just returning the quantities for the requested point.
>
> END FUNCTION
>
We would never see ExaHyPE starting to evolve something well before we get retired.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.