ExaHyPE-Engine issueshttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues2018-06-15T15:13:43+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/132MySolver::flux parameter F (double**) contiguous or not ?2018-06-15T15:13:43+02:00Jean-Matthieu GallardMySolver::flux parameter F (double**) contiguous or not ?Here is the signature of the flux function:
`void GRMHD::GRMHDSolver::flux(const double* const Q,double** F)`
When using Fortran user code, it is assumed by @svenk that F is a contiguous array. This is true with the generic kernel but...Here is the signature of the flux function:
`void GRMHD::GRMHDSolver::flux(const double* const Q,double** F)`
When using Fortran user code, it is assumed by @svenk that F is a contiguous array. This is true with the generic kernel but false with the optimized one due to changing the data layout of LFi from (t, z, y, x, nDim + 1 for Source, nVar) to (nDim + 1 for Source,t, z,y, x, , nVar_padded)
The assumption that F is contiguous was never explicitly given so my question:
Should F be assumed to be contiguous ?
If yes I need to adapt the optimized kernel, if not then the Fortran user code should at least explicitly mention this and if possible do the conversion himself.
Concerned: @svenk @ga96nuv @di25cox @gi26detJean-Matthieu GallardJean-Matthieu Gallardhttps://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/130Guidebook: Fix recommendation for MPI Tags for Reductions2019-03-07T19:24:19+01:00Ghost UserGuidebook: Fix recommendation for MPI Tags for ReductionsWhen implementing an own MPI Reductions plotter, the guidebook tells us we should write something like
```
void finishRow() {
#ifdef Parallel
// Question: Do we really reserve a free tag and release on each function call?
c...When implementing an own MPI Reductions plotter, the guidebook tells us we should write something like
```
void finishRow() {
#ifdef Parallel
// Question: Do we really reserve a free tag and release on each function call?
const int reductionTag = tarch::parallel::Node::getInstance().reserveFreeTag(
std::string("TimeSeriesReductions(") + filename + ")::finishRow()" );
if(master) {
double recieved[LEN];
for (int rank=1; rank<tarch::parallel::Node::getInstance().getNumberOfNodes(); rank++) {
if(!tarch::parallel::NodePool::getInstance().isIdleNode(rank)) {
MPI_Recv( &recieved[0], LEN, MPI_DOUBLE, rank, reductionTag, tarch::parallel::Node::getInstance().getCommunicator(), MPI_STATUS_IGNORE );
addValues(recieved);
}
}
} else {
for (int rank=1; rank<tarch::parallel::Node::getInstance().getNumberOfNodes(); rank++) {
if(!tarch::parallel::NodePool::getInstance().isIdleNode(rank)) {
MPI_Send( &data[0], LEN, MPI_DOUBLE, tarch::parallel::Node::getGlobalMasterRank(), reductionTag, tarch::parallel::Node::getInstance().getCommunicator());
}
}
}
tarch::parallel::Node::getInstance().releaseTag(reductionTag);
#endif
if(master) {
TimeSeriesReductions::finishRow();
writeRow();
}
}
```
However I assume this is not that good, looking at the output:
![mpi-reservefreetags](/uploads/de93f1e5c48d10c62101531611e044cd/mpi-reservefreetags.png)
*First question*: Does every plotter need it's own tag? In principal only if they would be called in parallel, isn't it?
In any case, I think the tags should'nt be created so frequently, isn't it? Instead, only once on startup time?
This should be fixed in the guidebook and my code :Dhttps://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/128Dynamic AMR race conditions possible2018-06-15T15:13:43+02:00Ghost UserDynamic AMR race conditions possibleGradient based refinement criteria can introduce a race condition
in my current dynamic AMR implementation.
The user has to make sure here that the fine grid cells are not requesting
erasing while the coarse grid cell requests refi...Gradient based refinement criteria can introduce a race condition
in my current dynamic AMR implementation.
The user has to make sure here that the fine grid cells are not requesting
erasing while the coarse grid cell requests refinement.
I properly have to introduce a flag/cell type that notifies the fine grid cells that the
parent has requested refinement during this grid setup.
I was able to implement stable refinement criteria solely based on the magnitude of the target quantity.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/127Revise time stepping notation2019-09-20T15:46:39+02:00Ghost UserRevise time stepping notationI have to write down carefully how I handle the time step sizes for
* fused time stepping
* standard time stepping
and what I do during mesh refinement for
* fused time stepping
* standard time stepping
This is getting a little comp...I have to write down carefully how I handle the time step sizes for
* fused time stepping
* standard time stepping
and what I do during mesh refinement for
* fused time stepping
* standard time stepping
This is getting a little complicated and the docu just gives an partial overview.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/125Compiling on the cluster, notes2018-06-15T15:13:43+02:00Ghost UserCompiling on the cluster, notesFirst: SVN is old and breaks generate-buildinfo.sh, almost fixed.
Second: MPI/TBB, all that, is ugly:
```
mpiicpc -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -restrict -xHost -O3 -no-ipo -ip...First: SVN is old and breaks generate-buildinfo.sh, almost fixed.
Second: MPI/TBB, all that, is ugly:
```
mpiicpc -DALIGNMENT=16 -DnoMultipleThreadsMayTriggerMPICalls -DDim2 -fstrict-aliasing -std=c++0x -restrict -xHost -O3 -no-ipo -ip -DSharedTBB -DParallel -DMPICH_IGNORE_CXX_SEEK /usr/include/tbb -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ApplicationExamples/EulerFlow -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/mpibalancing/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/sharedmemoryoracles/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/multiscalelinkedcell/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/tarch/.. -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ExaHyPE -I/home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./ApplicationExamples/EulerFlow -c /home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/grid/TraversalOrderOnTopLevel.cpp -o /home/astro/koeppel/ExaHyPE/Engine-ExaHyPE/./Peano/peano/grid/TraversalOrderOnTopLevel.o
icpc: error #10236: File not found: '/usr/include/tbb'
```
on LOEWE after
```
$ module list
Currently Loaded Modulefiles:
1) slurm/2.6.3 3) mpi/mvapich2/intel-17.0.1/2.2 5) intel-tbb-oss/intel64/40_20120613oss
2) intel/compiler/64/17.0.1 4) mpi/intel/4.1.0.024
```
I think the `tbb` path is in some `ENV` var, should not be assumed at `/usr/include/tbb`.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/124Toolkit - Move from replaceAll to true template engine2018-09-21T12:09:36+02:00Jean-Matthieu GallardToolkit - Move from replaceAll to true template engineThe templates used by the Toolkit start to require some logic. For example the NamingScheme tag requires to expand a Set to multiple lines.
Currently we put that logic in the java class and use a replaceAll but it would be better to put...The templates used by the Toolkit start to require some logic. For example the NamingScheme tag requires to expand a Set to multiple lines.
Currently we put that logic in the java class and use a replaceAll but it would be better to put that logic in the template itself using a true template engine. For example the NamingScheme tag would be replace with a foreach loop that expand the Set in the template. Also this would help factorizing the code by putting common tag and their value into a more global context set for the template engine
Switching should be simple as we are already using standard template tags for our variable.
Ofc the template engine needs to be light and fully available in a jar or any format requiring no installation to avoid adding new dependencies. For example https://github.com/HubSpot/jinjava or http://jtwig.org/
This is a "nice to have" feature so we should do it when we have more time.
Concerned: @di25cox , @gi26det , @svenk , @ga96nuvJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/123Derivative plotter, part 22018-06-15T15:13:43+02:00Ghost UserDerivative plotter, part 2We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is ...We wrote a plotter which access one cell ("patch") and computes the local derivatives, but it cannot plot to VTK but only reductions. We need to extend this to VTK, too.
Application context: Z4, we need to see the constraints.
This is something I can try to do.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/122FV kernels NCP / gradQ2018-06-15T15:13:43+02:00Ghost UserFV kernels NCP / gradQNote also that the Godunov kernels still lack support for NCP and gradQ and all that.
It's something I could try work on.Note also that the Godunov kernels still lack support for NCP and gradQ and all that.
It's something I could try work on.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/121Grid Setup takes forever for aspect-ratio<0.4 domains.2018-06-15T15:13:43+02:00Ghost UserGrid Setup takes forever for aspect-ratio<0.4 domains.This was confirmed for the Finite Volumes, ADER-DG and Limiting ADER-DG solver
**Update**: width=1.0,0.4 works but not width = 1.0,0.3 and smaller aspect ratios width_y/width_x.
This might be a Peano bug since the if-body in the sn...This was confirmed for the Finite Volumes, ADER-DG and Limiting ADER-DG solver
**Update**: width=1.0,0.4 works but not width = 1.0,0.3 and smaller aspect ratios width_y/width_x.
This might be a Peano bug since the if-body in the snippet below
is not entered anymore after the first grid setup iteration.
```
void exahype::mappings::MeshRefinement::refineVertexIfNecessary(
exahype::Vertex& fineGridVertex,
const tarch::la::Vector<DIMENSIONS, double>& fineGridH,
bool isCalledByCreationalEvent
) const {
for (const auto& p : exahype::solvers::RegisteredSolvers) {
if (
fineGridVertex.getRefinementControl() == Vertex::Records::Unrefined
&&
tarch::la::allGreater(fineGridH,p->getMaximumMeshSize())
) {
logInfo("refineVertexIfNecessary(...)",fineGridH);
#ifdef Parallel
if (isCalledByCreationalEvent) {
fineGridVertex.enforceRefine();
}
else {
fineGridVertex.refine();
}
#else
fineGridVertex.refine();
#endif
}
}
}
```
Output:
```
0.00654268 info peano::utils::UserInterface::writeHeader() Application based upon the PDE framework Peano - 3rd Generation
0.0065589 info peano::utils::UserInterface::writeHeader() revision: 2509
0.00657392 info peano::utils::UserInterface::writeHeader() build: dim=2
0.00658727 info peano::utils::UserInterface::writeHeader() optimisations: d-loop persistent-attributes packed opt-static-subtrees recursion-unrolling persistent-regular-subtrees
0.00660133 info peano::utils::UserInterface::writeHeader() (C) 2005 - 2016 www.peano-framework.org
0.00661516 info peano::utils::UserInterface::writeHeader() processes: 1, threads: 1
0.00667906 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [1,1]
0.00671291 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [1,1]
0.00695658 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.333333,0.333333]
0.00709009 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00744748 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.333333,0.333333]
0.00749516 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.333333,0.333333]
0.00753284 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.333333,0.333333]
0.00765061 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00768328 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00771189 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00837231 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00840974 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00844097 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00893974 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00898051 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.00901055 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0099957 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0106082 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0106461 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0106778 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0154214 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.015456 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0154729 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0201931 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0202355 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0202694 info exahype::mappings::MeshRefinement::refineVertexIfNecessary(...) [0.111111,0.111111]
0.0283382 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0284777 info exahype::runners::Runner::createGrid() grid setup iteration #1, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:208,numberOfBoundaryVertices:154,numberOfOuterVertices:352,numberOfInnerCells:144,numberOfOuterCells:306,numberOfInnerLeafVertices:104,numberOfBoundaryLeafVertices:64,numberOfOuterLeafVertices:176,numberOfInnerLeafCells:135,numberOfOuterLeafCells:266,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:1,hasErased:0,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:1,hasModifiedGridInPreviousIteration:1,isTraversalInverted:1)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.0285568 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.041122 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.04128 info exahype::runners::Runner::createGrid() grid setup iteration #2, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:208,numberOfBoundaryVertices:154,numberOfOuterVertices:1106,numberOfInnerCells:144,numberOfOuterCells:729,numberOfInnerLeafVertices:104,numberOfBoundaryLeafVertices:64,numberOfOuterLeafVertices:534,numberOfInnerLeafCells:135,numberOfOuterLeafCells:642,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:1,hasErased:0,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:0,hasModifiedGridInPreviousIteration:1,isTraversalInverted:0)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.041399 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.0546217 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0550416 info exahype::runners::Runner::createGrid() grid setup iteration #3, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:374,numberOfBoundaryVertices:150,numberOfOuterVertices:1550,numberOfInnerCells:225,numberOfOuterCells:972,numberOfInnerLeafVertices:187,numberOfBoundaryLeafVertices:62,numberOfOuterLeafVertices:744,numberOfInnerLeafCells:135,numberOfOuterLeafCells:858,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:0,hasErased:1,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:1,hasModifiedGridInPreviousIteration:1,isTraversalInverted:1)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.0551374 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.0675743 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0676742 info exahype::runners::Runner::createGrid() grid setup iteration #4, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:358,numberOfBoundaryVertices:94,numberOfOuterVertices:1026,numberOfInnerCells:225,numberOfOuterCells:702,numberOfInnerLeafVertices:179,numberOfBoundaryLeafVertices:34,numberOfOuterLeafVertices:498,numberOfInnerLeafCells:135,numberOfOuterLeafCells:618,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:1,hasErased:1,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:1,hasModifiedGridInPreviousIteration:1,isTraversalInverted:0)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.0677187 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.0781031 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0782623 info exahype::runners::Runner::createGrid() grid setup iteration #5, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:374,numberOfBoundaryVertices:150,numberOfOuterVertices:1106,numberOfInnerCells:225,numberOfOuterCells:729,numberOfInnerLeafVertices:187,numberOfBoundaryLeafVertices:62,numberOfOuterLeafVertices:534,numberOfInnerLeafCells:135,numberOfOuterLeafCells:642,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:1,hasErased:0,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:0,hasModifiedGridInPreviousIteration:1,isTraversalInverted:1)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.0783317 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.0897303 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0898073 info exahype::runners::Runner::createGrid() grid setup iteration #6, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:358,numberOfBoundaryVertices:94,numberOfOuterVertices:1550,numberOfInnerCells:225,numberOfOuterCells:972,numberOfInnerLeafVertices:179,numberOfBoundaryLeafVertices:34,numberOfOuterLeafVertices:744,numberOfInnerLeafCells:135,numberOfOuterLeafCells:858,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:0,hasErased:1,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:1,hasModifiedGridInPreviousIteration:1,isTraversalInverted:0)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
0.0898409 info exahype::runners::Runner::createGrid(...) memoryUsage =29 MB
0.098608 info exahype::mappings::LoadBalancing::endIteration(State) memoryUsage =29 MB
0.0987325 info exahype::runners::Runner::createGrid() grid setup iteration #7, max-level=4, state=(mergeMode:MergeNothing,sendMode:ReduceAndMergeTimeStepData,reinitTimeStepData:0,stabilityConditionOfOneSolverWasViolated:0,timeStepSizeWeightForPredictionRerun:0,limiterDomainHasChanged:0,minMeshWidth:[0.037037,0.037037],maxMeshWidth:[0.037037,0.037037],numberOfInnerVertices:374,numberOfBoundaryVertices:150,numberOfOuterVertices:1026,numberOfInnerCells:225,numberOfOuterCells:702,numberOfInnerLeafVertices:187,numberOfBoundaryLeafVertices:62,numberOfOuterLeafVertices:498,numberOfInnerLeafCells:135,numberOfOuterLeafCells:618,maxLevel:4,hasRefined:1,hasTriggeredRefinementForNextIteration:1,hasErased:1,hasTriggeredEraseForNextIteration:0,hasChangedVertexOrCellState:1,hasModifiedGridInPreviousIteration:1,isTraversalInverted:1)[smallest-regular-tree-that-is-held-persistently(currently/previous iteration)=0/0], idle-nodes=1
```https://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.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/119DummyK2018-06-15T15:13:43+02:00Ghost UserDummyKQuestions:
* Do we consider point sources here?
* If so, why do we need an additional isDummyK() boolean getter here?
* If so, why is a point source not related to normal sources and needs its extra memory (see mapping Prediction?)
...Questions:
* Do we consider point sources here?
* If so, why do we need an additional isDummyK() boolean getter here?
* If so, why is a point source not related to normal sources and needs its extra memory (see mapping Prediction?)
We already allocate memory for the source terms in the temporary variables for space-time and spatial fluxes.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/118Grid extends are wrong in 3D2018-06-15T15:13:43+02:00Ghost UserGrid extends are wrong in 3DLook at this screenshot, the Z range specified in the specfile is not correctly interpreted.
![exahype-grid-size](/uploads/fcc13d63a1b6e1fa14c54b72d27500e1/exahype-grid-size.png)Look at this screenshot, the Z range specified in the specfile is not correctly interpreted.
![exahype-grid-size](/uploads/fcc13d63a1b6e1fa14c54b72d27500e1/exahype-grid-size.png)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/117Support material parameters2019-09-20T15:46:49+02:00Ghost UserSupport material parametersTODO:
* ~~Make Generic C/C++ kernels support parameters x {FV,ADERDG}~~
* ~~Make Generic fortran kernels support parameters.
( solutionUpdate is here the problem.)~~
* ~~In all kernels using the solver template argument swit...TODO:
* ~~Make Generic C/C++ kernels support parameters x {FV,ADERDG}~~
* ~~Make Generic fortran kernels support parameters.
( solutionUpdate is here the problem.)~~
* ~~In all kernels using the solver template argument switch to the constexpr for variables,parameters,and
order/basisSize.~~
* ~~MyElasticWaveSolver: Realised that we have to rethink our material approach
a little. Material parameters are not available from Q during the space-time predictor
computation which uses the space-time predictor or predictor DoF.
We need either:~~
* store the material values in solution(+previousSolution),
predictor,and space-time predictor
* ~~or pass the material values as separate argument
to flux,eigenvalues,ncp,matrixb etc.
We should then also pass them as separate arguments
to adjustedSolutionValues.~~
~~Follow up:
It might wise then to split the material parameters from the variables.~~ We have chosen the first option.
* ~~The Nonlinear 2D ADER-DG C/C++ kernels do not support materials yet.~~
* ~~The Nonlinear 3D ADER-DG C/C++ kernels do not support materials yet.~~
* ~~The Linear 2D ADER-DG C/C++ kernels do not support materials yet.~~
* ~~ The Linear3D ADER-DG C/C++ kernels do not support materials yet.~~
* The Fortran ADER-DG kernels do not support materials yet.
* The 2D FV kernels do not support materials yet.
* The 3D FV kernels do not support materials yet.
* The Linear 2D+3D ADER-DG C/C++ kernels need to consider material parameters in the AMR operators.
* (Optional) Transform all generic kernels to templates and use constexpr for variables,parameters and order/basisSize.
Questions:
* What happens at the boundary for the Finite Volumes method? Currently, we hand no material parameters in at the boundary.
* Are there no time averaged source terms in the spaceTimePredictorLinear2d/3d? Yes, I consider them now at least in the striding.
* The linear ADER-DG kernels work with time derivatives. Does it make sense to let the user set the nodal values?
* Why wasn't tempPointForceSources merged into tempSpaceTimeUnknowns. The API change wasn't necessary.
Follow ups:
* Add a boolean to the AbstractMySolver class indicating if we consider Linear or Nonlinear kernels.
* Distinguish more clearly between temporary array sizes and dof array sizes.
* Add a boolean to the AbstractMySolver class indicating if we consider Linear or Nonlinear kernels.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/116Specfile Constants don't accept strings2018-06-15T15:13:43+02:00Ghost UserSpecfile Constants don't accept stringsWhen running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maxim...When running a toolkit with a specfile containing constants, ie.
```
...
solver Limiting-ADER-DG MHDSolver
variables const = rho:1,vel:3,E:1,B:3,constrDaming:1
order const = 3
maximum-mesh-size = 0.9
time-stepping = global
kernel const = generic::fluxes::nonlinear
language const = C
limiter-kernel const = generic::Godunov
limiter-language const = C
dmp-relaxation-parameter = 0.0001
dmp-difference-scaling = 0.001
constants = foo:bar
...
```
where I want the variable `foo` to set the String value `bar`, the parser complaints:
```
ERROR: eu.exahype.parser.ParserException: [70,42] expecting: float number
```
It also doesn't accept a string (`foo:"bar"`):
```
ERROR: eu.exahype.lexer.LexerException: [70,42] Unknown token: "
```
In our applications, the majority of parameters are strings, next to boolean values.
I rank this ticket *Minor* as constants have never worked for me (always issues with the parser #44) and I stick to environment variables and command line arguments.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/115Version string crashing2018-06-15T15:13:43+02:00Ghost UserVersion string crashingAt least with ADERDG Limiting applications, when calling `--version`, we get a crash:
```
$ ./ExaHyPE-MHD --version
0.000146866 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned ...At least with ADERDG Limiting applications, when calling `--version`, we get a crash:
```
$ ./ExaHyPE-MHD --version
0.000146866 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[vertex] the free tag 0
0.000248671 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[cell] the free tag 1
0.000282049 12:08:29 [sveinn]rank:0 info tarch::parallel::Node<static>::reserveFreeTag() assigned message JoinDataBufferPool[cell-marker] the free tag 2
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Abgebrochen
```
This is certainly because the Solver `toString()` methods print a lot of information and somewhere there is a nullpointer inbetween, probably the linked FV solver in the limiting scheme.
I don't like to have such a verbose `toString()` anyway, but we'll see. Maybe I put in a more decent `toString()` method.
The `toString`s also lack the name of the actual class, ie. the new output how Dominic created it is no more able to tell about the actual class names.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/113Generic and Optimised solvers use abstract base class handling the kernel calls2018-06-15T15:13:43+02:00Ghost UserGeneric and Optimised solvers use abstract base class handling the kernel calls