ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2018-02-12T15:25:32+01:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/207"error: Neighbours cannot communicate." (Minimal working example Application)2018-02-12T15:25:32+01:00Ghost User"error: Neighbours cannot communicate." (Minimal working example Application)In commit https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/baacbecadd7321cb25aec130707bd8b6dc08b11a I added the new LimitingADERDG application `ApplicationExamples/Experiments/GridDemonstrator` where I test different limiter criteria....In commit https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/baacbecadd7321cb25aec130707bd8b6dc08b11a I added the new LimitingADERDG application `ApplicationExamples/Experiments/GridDemonstrator` where I test different limiter criteria.
In the submitted example, the code crashes after the first timestep with **error: Neighbours cannot communicate**.
```
12.1608 info memoryUsage =333 MB
12.5276 info grid setup iteration #40, idle-nodes=1, vertical solver communication=0
12.5276 info memoryUsage =333 MB
12.8925 info grid setup iteration #41, idle-nodes=1, vertical solver communication=0
12.8925 info memoryUsage =333 MB
13.2603 info grid setup iteration #42, idle-nodes=1, vertical solver communication=0
13.2603 info memoryUsage =333 MB
13.2604 info finished grid setup after 42 iterations
13.2604 info finalise mesh refinement and compute first time step size
13.4246 info initialised all data and computed first time step size
13.7191 info plotted initial solution (if specified) and computed first predictor
13.7191 info step 0 t_min =0
13.7192 info dt_min =0.0125926
13.7192 info memoryUsage =333 MB
13.7192 info plot
13.78 error Neighbours cannot communicate.
cell1=(solverNumber:0,neighbourMergePerformed:[1,0,1,0],isInside:[1,1,1,1],parentIndex:920,isAugmented:0,newlyCreated:0,type:Cell,refinementEvent:None,level:6,offset:[12.428,8.47737],size:[0.164609,0.164609],previousCorrectorTimeStamp:0,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0.0125926,correctorTimeStamp:0,predictorTimeStepSize:0.0125926,predictorTimeStamp:0.0125926,solution:42627,solutionAverages:42630,solutionCompressed:-1,previousSolution:42626,previousSolutionAverages:42629,previousSolutionCompressed:-1,update:42628,updateAverages:42631,updateCompressed:-1,extrapolatedPredictor:42632,extrapolatedPredictorAverages:42634,extrapolatedPredictorCompressed:-1,fluctuation:42633,fluctuationAverages:42635,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[0,0,0,0],augmentationStatus:0,previousAugmentationStatus:0,facewiseHelperStatus:[1,0,1,0],helperStatus:2,facewiseLimiterStatus:[2,0,1,0],limiterStatus:2,previousLimiterStatus:0,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:36444784,bytesPerDoFInSolution:0,bytesPerDoFInUpdate:8015768,bytesPerDoFInExtrapolatedPredictor:0,bytesPerDoFInFluctuation:-1287913656)
.cell2=(solverNumber:0,neighbourMergePerformed:[0,0,1,0],isInside:[1,1,1,1],parentIndex:933,isAugmented:0,newlyCreated:0,type:Cell,refinementEvent:None,level:6,offset:[12.5926,8.47737],size:[0.164609,0.164609],previousCorrectorTimeStamp:0,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0.0125926,correctorTimeStamp:0,predictorTimeStepSize:0.0125926,predictorTimeStamp:0.0125926,solution:8218,solutionAverages:8221,solutionCompressed:-1,previousSolution:8217,previousSolutionAverages:8220,previousSolutionCompressed:-1,update:8219,updateAverages:8222,updateCompressed:-1,extrapolatedPredictor:8223,extrapolatedPredictorAverages:8225,extrapolatedPredictorCompressed:-1,fluctuation:8224,fluctuationAverages:42960,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[0,0,0,0],augmentationStatus:0,previousAugmentationStatus:0,facewiseHelperStatus:[0,0,1,0],helperStatus:2,facewiseLimiterStatus:[0,0,0,0],limiterStatus:0,previousLimiterStatus:0,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:36491056,bytesPerDoFInSolution:0,bytesPerDoFInUpdate:8015768,bytesPerDoFInExtrapolatedPredictor:0,bytesPerDoFInFluctuation:-1285749088) (file:/home/sven/numrel/exahype/Engine-ExaHyPE/ExaHyPE/exahype/solvers/LimitingADERDGSolver.cpp,line:1570)
terminate called without an active exception
Abgebrochen
```
The specfile describes a PDE with 1 scalar field (doing nothing), the setup runs on a notebook in <10 seconds.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/1362D / 3D build check is not performed correctly2019-03-18T21:55:01+01:00Ghost User2D / 3D build check is not performed correctlyWe have a startup check in the code that makes sure that the specfile has some same `const` build constants as for instance the ADERDG polynomial order. However, this test fails for checking that for instance a 2D build is also runned wi...We have a startup check in the code that makes sure that the specfile has some same `const` build constants as for instance the ADERDG polynomial order. However, this test fails for checking that for instance a 2D build is also runned with a 2D grid specification. Thus we get strange errors as in https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/10b1261b34e2e239f9a4fe1e2c42f0e38d85a207 :
```
0.0459649 error Invalid simulation end-time: notoken
(file:/home/koeppel/numrel/exahype/Engine-ExaHyPE/./ExaHyPE/exahype/Parser.cpp,line:377)
` ``
And that not after the beginning but after one timestep.
There should be a well-speaking check instead at the beginning.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/1313D Legendre Plotting fails2018-06-15T15:13:43+02:00Ghost User3D Legendre Plotting failsWhen I do a 3D simulation and plot with `vtk::Cartesian::vertices::ascii`, I clearly see the cube and all elements nicely with their 3D coordinate:
![plotters-vertex](/uploads/dc054456b5c6915882dfa3480aa91638/plotters-vertex.png)
Inste...When I do a 3D simulation and plot with `vtk::Cartesian::vertices::ascii`, I clearly see the cube and all elements nicely with their 3D coordinate:
![plotters-vertex](/uploads/dc054456b5c6915882dfa3480aa91638/plotters-vertex.png)
Instead, when I switch to `vtk::Legendre::vertices::ascii` to see the actual degree of fredom, all elements get **the same z value**:
![plot-legendre-3d](/uploads/37af4b51f820a020abe876b1c855f32c/plot-legendre-3d.png)
The elements are still there, the VTK files have the same size, but the z coordinate is missing.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/105[Design decision][CodeGenerator] Optimizing unused feature2018-06-15T15:13:43+02:00Jean-Matthieu Gallard[Design decision][CodeGenerator] Optimizing unused feature@di25cox @svenk @gi26det
I'm currently rewriting the SpaceTimePredictor Code Generator and have the following issue:
The source terms for the SpaceTimePredictor and VolumeIntegral (in memory: 4th block of tempFluxUnknowns = lFhi a...@di25cox @svenk @gi26det
I'm currently rewriting the SpaceTimePredictor Code Generator and have the following issue:
The source terms for the SpaceTimePredictor and VolumeIntegral (in memory: 4th block of tempFluxUnknowns = lFhi and tempSpaceTimeFluxUnknowns[0] = lFi in 3D, tempSpaceTimeFluxUnknowns[1] = gradQ and tempStateSizedVector = BgradQ) are totally unused in Euler and therefore weren't implemented at all in the optimized kernel.
I could implement them like the generic kernel do (always active) but it would be highly inefficient as a lot of tensor product and function call for nothing would be required, also the generic kernel should be optimized to be able to chose to disable this feature altogether if not required.
So I'll need to force the user to chose to activate the use of source term or not (at least for the optimized kernel, the generic ones can later be adapted the same way). I see 3 way of doing this efficiently:
* Write it somewhere in the spec file so that the Code Generator can generate code without source term if required
* Use preprocessor instruction and tell the user to modify the local makefile or a new compile configuration file to enable/disable it and then mark the source term related code with preprocessor branching
* Use templating and template metaprogramming to generate two or more version of the code, then let the user chose which one to use by changing a boolean that will be read in the MySolver_generated to choose the correct implementation
Example of solution 3:
```
template <boolean useSource>
void test() {
if(useSource) {
printf("Source term code used");
} else {
printf("No Source term code");
}
}
// [...] in Mysolver_generated
if(useSourceLocalBoolean) {
test<true>();
} else {
test<false>();
}
```
The advantage is that the branching optimization is done at compile time with 2 version of the code generated and the branching evaluation will be very cheap (once per cell per timestep). The drawback is that the code become more complex.
I would prefer solution 1 or 2 but we can discuss it as it is not urgent matter (I'm implementing without source at first).Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/192[Peano] Number of persistent subgrids is changing from iteration to iteration2017-10-16T11:09:26+02:00Ghost User[Peano] Number of persistent subgrids is changing from iteration to iterationWe observed that if a rank has distributed all its local work to workers,
the number of cells of this rank which are stored in regular subgrids
might change every second iteration.We observed that if a rank has distributed all its local work to workers,
the number of cells of this rank which are stored in regular subgrids
might change every second iteration.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/185[Toolkit] Makefile generation with template engine + remove ARCHITECTURE2017-10-06T16:28:14+02:00Jean-Matthieu Gallard[Toolkit] Makefile generation with template engine + remove ARCHITECTURETODO
* Generate the Makefile using the template engine
* Remove the ARCHITECTURE parameter export, use the one from the spec fileTODO
* Generate the Makefile using the template engine
* Remove the ARCHITECTURE parameter export, use the one from the spec fileJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/240Access to all patches of a peano cell from within user interface/code2018-08-24T11:55:39+02:00Ghost UserAccess to all patches of a peano cell from within user interface/codeHi,
I'm trying to access all patches within a peano cell from within the user code. I'm using the EulerFV example. Is it possible to document this?
I understand that one has to override the function adjustSolution in the Abstract class...Hi,
I'm trying to access all patches within a peano cell from within the user code. I'm using the EulerFV example. Is it possible to document this?
I understand that one has to override the function adjustSolution in the Abstract class (AbstractMyEulerSolver.cpp) as there kernels::finitevolumes::commons::c::solutionAdjustment() is called.
To my understanding kernels::finitevolumes::commons::c::solutionAdjustment() loops through all the patches within a peano cell.
I override the abstract function but there is a compiler error in commons.cpph that says "too few arguements in function call" - line 493. I suspect that the error is caused by the overriding.
Any help/documentation would be helpful.
thankshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/129Access to neighbours for which kernels?2018-06-15T15:13:07+02:00Ghost UserAccess to neighbours for which kernels?Finite Volumes Solver:
- source; ex: bathymetry in SWEFinite Volumes Solver:
- source; ex: bathymetry in SWEhttps://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/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/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/195Additional refinement along MPI boundaries2018-03-20T16:13:38+01:00Ghost UserAdditional refinement along MPI boundariesPeano's spacetree traversal is inverted every second iteration.
This poses a problem for ExaHyPE's master-worker communication
if the master rank has local subtrees.
Example:
--------
Imagine a uniform grid where a fork was performed on...Peano's spacetree traversal is inverted every second iteration.
This poses a problem for ExaHyPE's master-worker communication
if the master rank has local subtrees.
Example:
--------
Imagine a uniform grid where a fork was performed on Level 2. 3^d - 1 workers of our
master rank have been introduced. They and the master rank hold 1/3^d of the computational domain.
We call the portion belonging to the master rank, the local subtree of the master (rank).
In the first iteration, we correctly kick off all workers on the coarse grid before we descend into
the local subtree of the master.
In the second iteration, we start within the local subtree of the master and perform computations.
As soon as we reach the coarse grid, we kick off all workers.
The workers had to wait while we performed our computations on the master's local subtree.
Now finally, the workers will start their computations.
The whole tree traversal might take twice as long as assumed.
This becomes even worse if there are more Master-Worker boundaries.
The red bars in the plot below indicate such scenarios.
Tobias proposes to add additional refinement along the MPI boundary to prevent the need of vertical
communication. At least from the master to the worker. This might work.
I wonder however if it is really beneficial for ExaHyPE to change the traversal order in every second iteration.
In a MPI setting where we perform asynchronous communication, an inversion of the
traversal order is especially ill-suited since we then have to wait till the last message was received
by the neighbour. Instead, we would need to wait and (block) until all messages for the currently
touched vertex are received.
**Update:** The traversal order is hardwired into Peano. It is necessary to run it forward and backward.
![master_worker_synchronisation](/uploads/e1fc83f445841cb3763e0bfd7d8ec701/master_worker_synchronisation.jpg)
Additional Refinement along the MPI boundary
----------------------------------------------
This can be accomplished by continuously refining the top most parent patch (which is of type Cell) of every cell
of type Descendant which is at a Master-Worker boundary.
This has to be done until we end up with a patch of type Cell at the Master-Worker boundary.
At this point, we then need to send the solution values of the Master cell to the worker.
We further might need to impose initial conditions.
We further need to perform status flag merges in prepareSendToWorker.
**Problems with this approach:** It might introduce rippling refinings around
the artificially refined cell.
Introduce a no-operation traversal
----------------------------
We could further introduce a no-operation traversal before we perform
reductions and broadcasts which would rewind Peano's streams
but does not perform any computations and communication.
In this case, we would always follow the top-down traversal.
The observed Master-Worker synchronisation would not appear.
**Problems with this approach:**
- ~~Batching is currently not possible with~~
~~multiple adapters. We could maybe perform no operation in every second iteration.~~
~~However, we would then have still a Master Worker synchronisation. Or would we not?~~
We could have a single empty traversal in front of a batch. That would
work.
- The BoundaryDataExchanger of the heaps always assumes an inversion of the traversal in
every iteration.
To alter this behaviour, we would need to change the receive methods
in Peano's AbstractHeap,DoubleHeap, and BoundaryDataExchanger methods.
We are required to add a bool "assumeForwardTraversal" (defaults to false) to the signature.
We are further required to update ExaHyPE's solver implementations:
Whenever we receive boundary data after we have run the no-operation traversal,
we need to set this new flag to true when calling receiveData.
If we run of batch iteration, this must be done only
in the first iteration of the batch.
Have both
----------------------------
For optimal performance, it might be useful to employ both techniques.
We might use "loop padding", i.e. insert empty traversals, in order to end up with the forward traversal
any time we need to broadcast / reduce something.
In generally it might useful to handle broadcasts and reductions outside of the mapping.
Therefore, we would however need to plug into both, runAsMaster and runAsWorker.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/142ADERDG, inverseDX2018-06-19T11:17:55+02:00Jean-Matthieu GallardADERDG, inverseDX* Problem: most kernel use 1/dx instead of dx. Slow operation that could easily be optimized away.
* Solution:
- Peano implement a cellDescription.getInverseSize()
- ADERDGSolver use it
- ADERDG Kernel adapted
* Already done:
- Op...* Problem: most kernel use 1/dx instead of dx. Slow operation that could easily be optimized away.
* Solution:
- Peano implement a cellDescription.getInverseSize()
- ADERDGSolver use it
- ADERDG Kernel adapted
* Already done:
- Optimized kernel adapted, generate the inverseDx in the ADERDGSolver (code isolated with preprocessor)
@di25coxJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/99ADERDG2CartesianVTK vertices plotter refrains to work2018-06-15T15:13:43+02:00Ghost UserADERDG2CartesianVTK vertices plotter refrains to workWith assertions, EulerFlow, no TBB, no MPI, doesn't work any more:
```
0.0138609 info exahype::runners::Runner::createGrid(Repository) finished grid setup after 4 iterations
0.0138698 info exahype::runner...With assertions, EulerFlow, no TBB, no MPI, doesn't work any more:
```
0.0138609 info exahype::runners::Runner::createGrid(Repository) finished grid setup after 4 iterations
0.0138698 info exahype::runners::Runner::runAsMaster(...) start to initialise all data and to compute first time step size
0.0147572 info exahype::runners::Runner::runAsMaster(...) initialised all data and computed first time step size
assertion in file /dev/shm/exabuild-f6cb071ddf-Euler-euler-asserts/./ExaHyPE/exahype/plotters/ADERDG2CartesianVTK.cpp, line 350 failed: _writtenUnknowns==0 || _vertexTimeStampDataWriter!=nullptr
build-euler-asserts: /dev/shm/exabuild-f6cb071ddf-Euler-euler-asserts/./ExaHyPE/exahype/plotters/ADERDG2CartesianVTK.cpp:350: void exahype::plotters::ADERDG2CartesianVTK::plotPatch(const tarch::la::Vector<2, double>&, const tarch::la::Vector<2, double>&, double*, double): Assertion `false' failed.
```
Full run log:
[run-euler-asserts-shuvortex.log](/uploads/b7e9d8a86d4ce9827db9254e054c8f48/run-euler-asserts-shuvortex.log)
Specfile:
[ShuVortexConvergenceTpl.exahype](/uploads/f140d40aa2e3115d7bafdbb96782d989/ShuVortexConvergenceTpl.exahype)
Binary options:
[version.txt](/uploads/3f6358a7c0ba9aad6bbf38bcc6b8299a/version.txt)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/182Aligned heaps throw segmentation fault upon deleteData invocation2017-10-13T12:16:05+02:00Ghost UserAligned heaps throw segmentation fault upon deleteData invocation- This is especially an issue for adaptive simulations.
- Adaptive simulations are currently also not possible with the optimised kernels
since there are no optimised variants of the prolongation and restriction
kernels available yet...- This is especially an issue for adaptive simulations.
- Adaptive simulations are currently also not possible with the optimised kernels
since there are no optimised variants of the prolongation and restriction
kernels available yet.
TODO
- I will add a test for the heap allocation. Hopefully this will minimise the complexity
of the problem.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/290Allow periodic boundary conditions for single-node runs2019-07-23T16:34:47+02:00Ghost UserAllow periodic boundary conditions for single-node runsThis allows to simply realise periodic boundary conditions via a lookup table.
Step 0: Initial data is known, i.e. solution at boundary is known, too. Impose this data.
Start building up the lookup table.
Step 1: Have the looku...This allows to simply realise periodic boundary conditions via a lookup table.
Step 0: Initial data is known, i.e. solution at boundary is known, too. Impose this data.
Start building up the lookup table.
Step 1: Have the lookup table. Use it.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/158AMR+LimitingADERDGSolver crashes for certain limiter status changes2017-11-02T18:15:15+01:00Ghost UserAMR+LimitingADERDGSolver crashes for certain limiter status changes# 1. Issue:
There is another issue with the MUSCL-Hancock solver which crashes in the min and max
determination after a global recomputation.
```
147.062 info exahype::runners::Runner::updateMeshFusedTimeStepping(......# 1. Issue:
There is another issue with the MUSCL-Hancock solver which crashes in the min and max
determination after a global recomputation.
```
147.062 info exahype::runners::Runner::updateMeshFusedTimeStepping(...) recompute solution locally (if applicable) and compute new time step size
assertion in file /home/dominic/dev/codes/c/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/LimitingADERDGSolver.cpp, line 1111 failed: *(observablesMin+i)<std::numeric_limits<double>::max()
parameter i: 1
parameter solverPatch.toString(): (solverNumber:0,neighbourMergePerformed:[1,1,1,1],isInside:[1,1,0,1],parentIndex:69,isAugmented:0,newlyCreated:0,type:Cell,refinementEvent:None,level:5,offset:[0.518519,0],size:[0.0123457,0.0123457],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:1.79769e+308,correctorTimeStepSize:0.000497671,correctorTimeStamp:0.0909671,predictorTimeStepSize:0,predictorTimeStamp:0.0914648,solution:2838,solutionAverages:2843,solutionCompressed:-1,previousSolution:2839,previousSolutionAverages:2841,previousSolutionCompressed:-1,update:2840,updateAverages:2842,updateCompressed:-1,extrapolatedPredictor:2844,extrapolatedPredictorAverages:2846,extrapolatedPredictorCompressed:-1,fluctuation:2845,fluctuationAverages:2847,fluctuationCompressed:-1,solutionMin:2848,solutionMax:2849,facewiseAugmentationStatus:[0,0,0,0],augmentationStatus:0,facewiseHelperStatus:[2,2,2,2],helperStatus:2,facewiseLimiterStatus:[0,0,0,0],limiterStatus:0,previousLimiterStatus:3,iterationsToCureTroubledCell:10,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:305,bytesPerDoFInSolution:-296662368,bytesPerDoFInUpdate:32765,bytesPerDoFInExtrapolatedPredictor:0,bytesPerDoFInFluctuation:0)
ExaHyPE-Euler: /home/dominic/dev/codes/c/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/LimitingADERDGSolver.cpp:1111: void exahype::solvers::LimitingADERDGSolver::determineSolverMinAndMax(exahype::solvers::LimitingADERDGSolver::SolverPatch&): Assertion `false' failed.
```
I have to gather more information about this first.
# 2. Issue
Cell of type 3 or 4 (FV->DG) changes to Troubled.
Neighbour is of Type 1 or 2 (DG->FV).
Example:
Before:
![before](/uploads/0a30bada69ece5db04146246ff72c5c1/before.png)
After:
![after](/uploads/fcf89aaaa40453a52ead9622bd283033/after.png)
* Fix 1: Need to stop iterations if situation detected in neighbour merging
-> write stable values, i.e. own values to ghost layer
-> Perform rollback in affected cells (=>irregular
limiter domain chage; requires local recomputation)
* Fix 2: Use less dissipative FV methods or higher order
ADERDG => finer subcell resolution
Or set parameter steps to cure troubled cells to a higher value
# 3. Found bugs:
* The whole global recomputation thing is more sophisticated than previously thought. I
have to be careful how I go back in time. This is based on the previous limiter status.
I am only allowed to delete patches after the recomputation.
# 4. Ways to increase stability
* Do not change Local Recomputation to Global Recomputation if limiter based mesh refinement is also necessary.
# 5. Algorithms:
(Stuff above is outdated. Keep it for reference.)
## Local Recomputation
1. limiter status spreading
2. local reinitialisation
3. local recomputation + local predictor computation
## Global Recomputation
1. limiter status spreading
2. global rollback (keep new limiter status) <-ensures we adjust the previous solution during mesh refinement
3. mesh refinement according to new limiter status
4. overwrite new limiter status with previous values
5. recompute time step size
6. reinitialise fused time stepping and recompute predictor
Problems:
* TimeStepSizeComputation does update the time stamps (solved)
* Need additional adapter for global rollback (global reinitialisation)
* I am not allowed to deallocate limiter patches during limiter status spreading
* Have to keep in mind to overwrite the limiter status in finalise mesh refinement.
## Mesh Refinement
1. mesh refinement according to ref. crit.
4. recompute time step size
5. reinitialise fused time stepping and recompute predictorhttps://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/107An idea to solve both the toolkit overwriting and file location problem2018-06-15T15:13:43+02:00Ghost UserAn idea to solve both the toolkit overwriting and file location problemThe Java toolkit creates C++ files in the application directory ("output Directory"). This creates (amongst others) two problems:
1. In large applications, users cannot freely structure their code in subdirectories
2. Users cannot u...The Java toolkit creates C++ files in the application directory ("output Directory"). This creates (amongst others) two problems:
1. In large applications, users cannot freely structure their code in subdirectories
2. Users cannot understand which files are overwritten and which not
To address problem (1), I recently introduced an heuristic approach, [FileSearch.java](https://gitlab.lrz.de/exahype/ExaHyPE-Engine/blob/6e7e9552fb3d65b4c5feb5c70e36038be06499ad/Toolkit/src/eu/exahype/FileSearch.java). This allows to put a file *with a similar name* in any subdirectory in the output directory. Thus, for instance, we can have an application to be structured in folders like
```
SRMHD
├── C2P-MHD.f90
├── C2P-MHD.h
├── C2PRoutines.f90 -> ../SRHD/C2PRoutines.f90
├── ExaHyPE-MHDSolver-p2
├── extended.log
├── InitialDataAdapter.cpp
├── InitialDataAdapter.h
├── InitialData.f90
├── KernelCalls.cpp
├── Makefile
├── make-p2.log
├── MHDSolver.cpp
├── MHDSolver_generated.cpp
├── MHDSolver.h
├── Parameters.f90
├── parameters.mod
├── PDE.f90
├── PDE.h
├── run_withEnv.sh
└── Writers
├── ConservedWriter.cpp
├── ConservedWriter.h
├── ErrorWriter.cpp
├── ErrorWriter.h
├── ExactPrimitivesWriter.cpp
├── ExactPrimitivesWriter.h
├── IntegralsWriter.cpp
├── IntegralsWriter.h
├── PrimitivesWriter.cpp
├── PrimitivesWriter.h
├── RelativeErrorWriter.cpp
├── RelativeErrorWriter.h
└── TimeSeriesReductions.h -> ../../EulerFlow/TimeSeriesReductions.h
```
ie. note the `Writers` subdirectory.
Actually, this ticket shall propose an idea which solves the problems (1) and (2) altogether.
## Defining a header
My idea proposes to define a magic line at any place (ie. header or footer) of the generated `.h` or `.cpp` files, containing something like:
```
/** ExaHyPE.jar: autogenerated at Fr 3. Feb 19:08:51 CET 2017 **/
/** ExaHyPE.jar: File identifier: Plotter[i].HeaderCode **/ <- this is the identifier line
/** ExaHyPE.jar: Rebuild options: [x] Rebuild on every toolkit call [ ] Manually disable rebuild [ ] Rebuild on structural change **/ <- This can be changed by user
```
The identifier line solves the problem to find an appropriate file. It allows users to rename them as he wants. The toolkit has to inspect all possible files with a `grep` like search, but this is not too bad. We don't really expect too big applications...
The options line allows the user both to understand the default setting and to enforce his own rules. This is very helpful when working at ExaHyPE internals and to stop this long lasting conflict with the toolkit overwriting stuff. It also allows users to request an overwrite of a file. The specific syntax is open to discussion, ie. one could also choose something better machine readable here.