ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2017-01-27T12:28:32+01:00https://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.