ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2018-11-13T18:01:05+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/251Ideas for new sweep features2018-11-13T18:01:05+01:00Ghost UserIdeas for new sweep features* The change to toolkit2 did change the set of compile-time parameters. I consider to
have a mandatory INI file parameter where the user specifies what parameter change requires a
rebuild of the application. This would however requi...* The change to toolkit2 did change the set of compile-time parameters. I consider to
have a mandatory INI file parameter where the user specifies what parameter change requires a
rebuild of the application. This would however require more care from the user's side.
* Have a plug-in point for parsers: The main functionality of sweep is spawning jobs for a parameter set and
then associating this parameter set with an output file. It then allows to parse the output file and
puts the result into CSV tables where the parameters are representing the key entries and the values parsed from
the output file the value entries of a row.
In theory, it should be easy to provide a plug-in point for user parsers.
Those parsers could be listed in the INI file.
* Have a validation procedure. Have a versioning system.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/252Toolkit validation shows non-deterministic behaviour2018-09-21T11:30:46+02:00Ghost UserToolkit validation shows non-deterministic behaviourI discovered that the toolkit validation shows non-deterministic behaviour.
I use a specification file where I remove the 'cores' option which is required
in the 'shared_memory' section.
The validation does not complain in some runs but...I discovered that the toolkit validation shows non-deterministic behaviour.
I use a specification file where I remove the 'cores' option which is required
in the 'shared_memory' section.
The validation does not complain in some runs but fails correctly in other
runs.
1. It works the first time (it shouldn't as the 'shared_memory/core' is missing.
```
17:14 $ ../../../Toolkit/toolkit.sh -v -format=any ../Euler_ADERDG.exahype
controller.py:77(__init__):INFO
______ __ __ ____ ______
/ ____/ ______ _/ / / /_ __/ __ \/ ____/ *************************
/ __/ | |/_/ __ `/ /_/ / / / / /_/ / __/ The ExaHyPE Toolkit v2
/ /____> </ /_/ / __ / /_/ / ____/ /___ www.exahype.eu
/_____/_/|_|\__,_/_/ /_/\__, /_/ /_____/ Commit: 77efa02
/____/ *************************
This project has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 671698 (ExaHyPE).
Copyright (c) 2018, All rights reserved
ExaHyPE is based on the PDE framework Peano (www.peano-framework.org).
Released under the BSD 3 Open Source License.
controller.py:85(__init__):INFO Read input file /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG.exahype.
omni_reader.py:46(__init__):INFO 4 file formats registered: json,hjson,exahype-v1,mexa
omni_reader.py:156(read):INFO No specific file format requested, trying all available file formats in order.
omni_reader.py:124(read_omni):INFO Trying to read file format json
omni_reader.py:136(read_omni):INFO The input file is certainly not written in the format json as a ParserError occured: Expecting value: line 1 column 1 (char 0)
omni_reader.py:124(read_omni):INFO Trying to read file format hjson
omni_reader.py:130(read_omni):INFO Cannot check file format hjson because neccessary library is not installed. The missing library is: No module named 'hjson'
omni_reader.py:131(read_omni):INFO Will silently ignore this problem
omni_reader.py:124(read_omni):INFO Trying to read file format exahype-v1
specfile1_reader.py:521(read_lines):INFO Converting legacy specification file (95 lines) to INI file...
specfile1_reader.py:523(read_lines):INFO OK
specfile1_reader.py:532(read_lines):INFO Mapping INI structure to JSON input object...
specfile1_reader.py:534(read_lines):INFO OK
omni_reader.py:126(read_omni):INFO Success reading file format exahype-v1
directories.py:37(check):INFO Peano kernel path: /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/Peano ... ok
directories.py:37(check):INFO Peano kernel path: /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/Peano holds tarch ... ok
[...]
/Euler_ADERDG/Makefile'
controller.py:152(run):INFO please change into directory /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/./ApplicationExamples/Euler/Euler_ADERDG and type make
ensure that you set all environment variables before:
export COMPILER=GNU Select GNU compiler
export COMPILER=Intel Select Intel compiler (default)
[...]
export USE_IPO=on Compile using IPO for the solvers and kernels (only with Intel compilers)
If USE_IPO is not specified, it falls back to "off" (compilation without IPO).
If you run CSH, please replace "export ARG=VALUE" with "setenv ARG VALUE".
```
2. It fails the second time which is the correct behaviour:
```
✔ ~/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG [master|✚ 16…1135⚑ 58]
17:18 $ ../../../Toolkit/toolkit.sh -v -format=any ../Euler_ADERDG.exahype
rm: cannot remove ‘*.o’: No such file or directory
rm: cannot remove ‘cipofiles.mk’: No such file or directory
rm: cannot remove ‘ffiles.mk’: No such file or directory
rm: cannot remove ‘cfiles.mk’: No such file or directory
rm: cannot remove ‘kernels’: No such file or directory
controller.py:77(__init__):INFO
______ __ __ ____ ______
/ ____/ ______ _/ / / /_ __/ __ \/ ____/ *************************
/ __/ | |/_/ __ `/ /_/ / / / / /_/ / __/ The ExaHyPE Toolkit v2
/ /____> </ /_/ / __ / /_/ / ____/ /___ www.exahype.eu
/_____/_/|_|\__,_/_/ /_/\__, /_/ /_____/ Commit: 77efa02
/____/ *************************
This project has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement No 671698 (ExaHyPE).
Copyright (c) 2018, All rights reserved
ExaHyPE is based on the PDE framework Peano (www.peano-framework.org).
Released under the BSD 3 Open Source License.
controller.py:85(__init__):INFO Read input file /home/dominic/dev/codes/c/upstream/ExaHyPE-Engine/ApplicationExamples/Euler/Euler_ADERDG.exahype.
omni_reader.py:46(__init__):INFO 4 file formats registered: json,hjson,exahype-v1,mexa
omni_reader.py:156(read):INFO No specific file format requested, trying all available file formats in order.
omni_reader.py:124(read_omni):INFO Trying to read file format json
omni_reader.py:136(read_omni):INFO The input file is certainly not written in the format json as a ParserError occured: Expecting value: line 1 column 1 (char 0)
omni_reader.py:124(read_omni):INFO Trying to read file format hjson
omni_reader.py:130(read_omni):INFO Cannot check file format hjson because neccessary library is not installed. The missing library is: No module named 'hjson'
omni_reader.py:131(read_omni):INFO Will silently ignore this problem
omni_reader.py:124(read_omni):INFO Trying to read file format exahype-v1
specfile1_reader.py:521(read_lines):INFO Converting legacy specification file (95 lines) to INI file...
specfile1_reader.py:523(read_lines):INFO OK
specfile1_reader.py:532(read_lines):INFO Mapping INI structure to JSON input object...
specfile1_reader.py:534(read_lines):INFO OK
omni_reader.py:126(read_omni):INFO Success reading file format exahype-v1
controller.py:218(validateAndSetDefaults):ERROR Specification file does not hold a valid ExaHyPE specification, it did not pass the schema validation step. The error message is: 'cores' is a required property
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/253Optimised kernels and AMR application do not work together2018-09-21T12:07:11+02:00Ghost UserOptimised kernels and AMR application do not work togetherWhen I run the Euler_ADERDG application with an adaptive grid and the optimised kernels,
I compute a time step size of approx. zero after the first time step. The simulation terminates.
The generic kernels do thousands of time steps with...When I run the Euler_ADERDG application with an adaptive grid and the optimised kernels,
I compute a time step size of approx. zero after the first time step. The simulation terminates.
The generic kernels do thousands of time steps without any complaints for the same problem.
The optimised kernels work without problems for the same application when uniform grids are used.
Files
* [specification file (text file)](/uploads/d25264d843ed7f543cf1a3b4e01a6d26/temp)
* [output generic kernels (text file)](/uploads/10715a9248f96b814909c75a5b333fbc/temp)
* [output optimised kernels (text file)](/uploads/a87857d5bf68669a97085bf8450db026/temp)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/254Finite Volumes Kernel Issues2019-09-20T15:43:37+02:00Ghost UserFinite Volumes Kernel IssuesA list of known issues with the FV kernels.
This list is open for extension. It may be split into separate issues
later on.
* MUSCL-Hancock implementation is second-order accurate but allows unlimited slopes
in the first ghost layer at ...A list of known issues with the FV kernels.
This list is open for extension. It may be split into separate issues
later on.
* MUSCL-Hancock implementation is second-order accurate but allows unlimited slopes
in the first ghost layer at corners and edges of the patch. This caused certain applications to crash.
* Stack allocation of multiple temporary arrays leads to Seg Faults for applications where these arrays
become huge (e.g. CCZ4). (This issue might be resolved after issue #255 has been resolved.)
* No (JM) optimisation has been performed yet. For most applications, the FV updates
are bandwith-bound indicating potential for speedups by vectorisation.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/255Add toolkit option for specifying thread stack size2019-09-20T15:46:25+02:00Ghost UserAdd toolkit option for specifying thread stack sizeChanges affect "shared_memory" section in JSON schema, the C++ Parser, and the Runner's "initSharedMem..."
routine.Changes affect "shared_memory" section in JSON schema, the C++ Parser, and the Runner's "initSharedMem..."
routine.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/256CarpetHDF5 Writer lacks Dataset support2018-11-01T17:30:43+01:00Ghost UserCarpetHDF5 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/257AMR_bug Test Case Crashes2019-09-20T15:42:20+02:00Ghost UserAMR_bug Test Case CrashesThe test case seems to crash now for all configurations.
I created pseudocode for the whole AMR program flow.
After I finished writing up, I will simplify the AMR program
flow another time.The test case seems to crash now for all configurations.
I created pseudocode for the whole AMR program flow.
After I finished writing up, I will simplify the AMR program
flow another time.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)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/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/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/282Multi-level Inheritance in Sweep2019-05-16T00:08:36+02:00Ghost UserMulti-level Inheritance in SweepCurrently, a config file can only inherit from one other file.
Just have to write a recursive function for this. Shouldn't be too hard.Currently, a config file can only inherit from one other file.
Just have to write a recursive function for this. Shouldn't be too hard.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/283Use ADER CFL Correction Factors When Determining FV Patch Resolution2019-07-09T15:18:48+02:00Ghost UserUse ADER CFL Correction Factors When Determining FV Patch ResolutionThe ADER-DG time step size does not only depend on the DG CFL number that
scales with ``1/(2*N+1)`` but by an additional order-dependent correction factor ``C_ADER(N)``.
For order 5, e.g., this factor is roughly 0.5.
We currently use 2*...The ADER-DG time step size does not only depend on the DG CFL number that
scales with ``1/(2*N+1)`` but by an additional order-dependent correction factor ``C_ADER(N)``.
For order 5, e.g., this factor is roughly 0.5.
We currently use 2*N+1 FV cells per FV patch in our implementation of the a posteriori
limiting ADER-DG method. The motivation is to match the time step size
of the coupled ADER-DG and the FV scheme.
This does not take the correction factor into account, i.e. we add unneccessary
numerical dissipation as we use unnecessary small time step sizes in the FV cells.
Using the same ADER-DG time step size, we can increase the FV cell sizes by
a factor ``1/C_ADER(N)``. For order 5, e.g., we can double the size of the FV patches.
The following table corrects the patch sizes. I round down to not go below the ADER-DG time step size with
the FV time step sizes.
| Order N | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
|-------------------------------------|---------|--------|--------|--------|--------|---------|---------|---------|---------|---------|
| C_ADER | 100.0 % | 99.0 % | 85.0 % | 70.0 % | 62.1 % | 49.5 % | 49.4 % | 45.0 % | 34.0 % | 28.5 % |
| Patch Scaling | 1.00 | 1.01 | 1.18 | 1.43 | 1.61 | 2.02 | 2.02 | 2.22 | 2.94 | 3.51 |
| Corr. Patch Size (Orig. Patch Size) | 1 | 3 | 5 | 10 (7) | 14 (9) | 22 (11) | 26 (13) | 33 (15) | 50 (17) | 66 (19) |
Tasks
-----
Proposed switch "Limiting-ADER-DG" solver specification:
``"patch_size" : ("original" | "max" | number)``
- ``max`` would look up the corrected patch size in a lookup table.
- ``original`` would use the original 2*order+1.
- ``number`` would use a user prescribed number. Control code must
check if the FV time step size is smaller or equal to the ADER-DG time step size.
Otherwise, an error must be printed out **OR** the ADER-DG method's CFL condition must be adjusted.
If a number is specified, then the ADER-DG to FV projectors have to be constructed manually.
For "max" and "original", they can be precomputed once.
* [x] Decide if a generic implementation of the patch size feasible or if the corrected patch sizes should be hardcoded?.
**A:** *Eventually both but first the hardcoded versions.*
* [x] Modify toolkit's solver controllers and templates:
* [x] ``exahype-specfile.schema.json``: Extend ``patch_size`` option in spec file schema
* [x] ``exahype/toolkit/solverController.py``: Take ``patch_size`` parameter into account.
Found issue: Defaults are not set.
* [x] Generic kernels:
* [x] Check that the CFL factor is picked up properly in the ADER-DG stableTimeStepSize kernel
* [x] ``GenericLimiterSolver(Header|Implementation).template``:
* [x] Update arguments passed to limiter kernels
* [x] Allocate Limiter projection matrices
* Dimensions:
* ``uh2lim[n] = new double[basisSize*basisSizeLim]();``
* ``uh2lob[n] = new double[basisSize*basisSize]();``
* ``lim2uh[n] = new double[basisSizeLim*basisSize]();``
* [x] Look up the FV to DG least-squares projection
* Main reference: M. Dumbser et al., *A posteriori subcell limiting of the discontinuous Galerkin finite element method for hyperbolic conservation laws*, Journal of Computational Physics, vol. 278, pp. 47–75, Dec. 2014.
* Least-squares reference: M. Dumbser and M. Käser, *Arbitrary high order non-oscillatory finite volume schemes on unstructured meshes for linear hyperbolic systems*, Journal of Computational Physics, vol. 221, no. 2, pp. 693–723, Feb. 2007.
* Objective function is
```math
\min_{u_h} \| u_h(x) - v_h(x) \|_{L^2(K)} = ([A] \{u\} - \{v\}) \cdot ([A] \{u\} - \{v\})
```
s.t. mass conservation constraint. $`[A]`$ is the DG to FV projection matrix. The objective function evaluates the DG solution $`u_h`$ at the FV cell centers $`v_h`$.
* Mass conservation constraint:
```math
\int_K u_h(x) dx = \int_K v_h(x)\,\text{d}x
```
```math
\sum_i u_i \int_{\bar K} \bar\phi_i (\bar x) \text{d}\bar x =
\sum_j v_j \cdot \frac{\bar V}{\bar K}
```
```math
\sum_i u_i w_i =
\sum_j v_j \cdot \frac{1}{\text{volumes per patch}}
```
```math
[C] \{u\} = [R] \{v\}
```
Above steps exploited properties of DG basis functions (Gauss-Legendre support points).
* Constraint coupled via Lagrange multiplier. Updated objective function:
```math
f = ([A] \{u\} - \{v\}) \cdot ([A] \{u\} - \{v\}) + \lambda \cdot ([C] \{u\} - [R] \{v\})
```
*
* Optimality condition (degrees of freedom/parameters: $`\{u\}`$ and $`\lambda`$):
```math
\begin{pmatrix}
2 [A] [A] & -[C]\\
[C] & 0
\end{pmatrix}
\cdot
\begin{pmatrix}
\{u\}\\
\lambda
\end{pmatrix}
=
\begin{pmatrix}
2\,[A]\,\{v\}\\
[R]\,\{v\}
\end{pmatrix}
```
To obtain solution $`\{u\}`$ and Lagrange multipliers $`\lambda`$, the
equations must be inverted. $`C`$ is sparse due to the tensor product structure.
$`[A]`$ is dense. As each nodal DG DOF is associated with a basis functions,
the above procedure yields a FV to DG projector.
* I can reuse JM's existing code. Essential is that I replace $`[A]`$, which I do anyway.
Convenient.
* [x] ``kernels/limiter/generic/Limiter.(h|cpp)``: Update signatures to take limiter patch size into account
* [x] ``LimiterProjectionMatrices.(h|cpp)``: Do not use original functions anymore
* [x] Optimised kernels:
* [x] Check if changes are necessary in ``OptimisedLimiterSolver(Header|Implementation).template``
* [x] Make sure ``dg2fv``, ``fv2dg`` and ``nDofLim``, ``nDofLimPad``, ``getBasisSizeLimiter()`,
and ``getBasisSizeLimiterPadded()`` are defined and used correctly:
* [x] Usage:
* [x] CodeGenerator/codegenerator/templates/configurationParameters_cpph.template (20 matches)
* [x] CodeGenerator/codegenerator/templates/limiter_cpp.template (51 matches)
* [x] CodeGenerator/codegenerator/templates/Quadrature_cpp.template (2 matches)
* [x] Definition:
* [x] CodeGenerator/codegenerator/templates/controller.py (5 matches)
* [x] CodeGenerator/codegenerator/models/limiterModel.py (29 matches)
* [x] CodeGenerator/codegenerator/models/quadratureModel.py (4 matches)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/287Add Limiter Recomputation Background Jobs2019-07-24T15:23:13+02:00Ghost UserAdd Limiter Recomputation Background JobsIn simulations where there are many FV recomputations,
the respective phases can become a bottleneck.In simulations where there are many FV recomputations,
the respective phases can become a bottleneck.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/294Halo Refinement Threshold2019-09-05T17:49:25+02:00Ghost UserHalo Refinement ThresholdAim:
Prevent that the mesh refinement iterations are triggered to often.
Background:
During the mesh refinement iterations, we refine the Leaf cell parents of those Virtual cells
that carry a refinement status greater than zero.
Cur...Aim:
Prevent that the mesh refinement iterations are triggered to often.
Background:
During the mesh refinement iterations, we refine the Leaf cell parents of those Virtual cells
that carry a refinement status greater than zero.
Currently, the time stepping iterations trigger refinement
as soon as a Virtual cell carries positive refinement status.
Especially with low order ADER-DG plus Limiter, mesh refinement is triggered quite often,
which seems to be related to the CFL time step size: "Shock does not stay "long" in the same cell".
Approach:
During the time stepping iterations, allow Virtual cells to carry
a refinement status smaller some positive threshold value.
Only if this threshold value is reached, trigger that
the mesh is adapted.
Additional, we could think about allowing erasing only every $k$ mesh adaptions (=set of mesh refinement iterations).https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/297FiniteVolumeSolver error about time step2020-11-20T17:30:31+01:00Duo Lid.li@lmu.deFiniteVolumeSolver error about time stepWhen running FV, there is this error. I use CFL=0.7. How to fix the warning or how does it matter to the code.
```cpp
if ( !tarch::la::equals(cellDescription.getTimeStepSize(), 0.0) && tarch::la::smaller(admissibleTimeStepSize,cellDesc...When running FV, there is this error. I use CFL=0.7. How to fix the warning or how does it matter to the code.
```cpp
if ( !tarch::la::equals(cellDescription.getTimeStepSize(), 0.0) && tarch::la::smaller(admissibleTimeStepSize,cellDescription.getTimeStepSize()) ) {
logWarning("updateSolution(...)","Finite volumes solver time step size harmed CFL condition. dt="<<
cellDescription.getTimeStepSize()<<", dt_adm=" << admissibleTimeStepSize << ". cell=" <<cellDescription.toString());
}
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/298Compilation error in peano::heap2019-09-17T12:34:46+02:00Duo Lid.li@lmu.deCompilation error in peano::heap/exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDro.../exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDropReceivedBoundaryData"
peano::heap::AbstractHeap::allHeapsDropReceivedBoundaryData();
^
compilation aborted for /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp (code 2)
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.o' failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/299Compilation error2019-10-16T10:05:11+02:00Duo Lid.li@lmu.deCompilation errorI compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument...I compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lQhbnd, _MM_HINT_NTA);
^
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(43): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lFhbnd, _MM_HINT_NTA);
^
compilation aborted for /import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp (code 2)
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.o’ failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/303error in compilation2019-10-15T09:38:50+02:00Duo Lid.li@lmu.deerror in compilationwhen compiling master Exahype, i have a bunch of errors with GaussLobattoBasis.hsnippet:
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from ...when compiling master Exahype, i have a bunch of errors with GaussLobattoBasis.hsnippet:
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(1): error: expected a declaration
namespace kernels {
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(22): warning #12: parsing restarts here after previous syntax error
extern double nodes_1[1+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(23): error: invalid storage class for a class member
extern double nodes_2[2+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(24): error: invalid storage class for a class member
extern double nodes_3[3+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(25): error: invalid storage class for a class member
extern double nodes_4[4+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(26): error: invalid storage class for a class member
extern double nodes_5[5+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(27): error: invalid storage class for a class member
extern double nodes_6[6+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(28): error: invalid storage class for a class member
extern double nodes_7[7+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(29): error: invalid storage class for a class member
extern double nodes_8[8+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(30): error: invalid storage class for a class member
extern double nodes_9[9+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(31): error: invalid storage class for a class member
extern double nodes_10[10+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(32): error: invalid storage class for a class member
extern double nodes_11[11+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(33): error: invalid storage class for a class member
extern double nodes_12[12+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(34): error: invalid storage class for a class member
extern double nodes_13[13+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(35): error: invalid storage class for a class member
extern double nodes_14[14+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(36): error: invalid storage class for a class member
extern double nodes_15[15+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(37): error: invalid storage class for a class member
extern double* nodes[15+1];
does any one have any idea?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 Weinzierl