ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2018-09-21T11:30:46+02:00https://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/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/250Issue with Limiting ADER-DG combined with Material Parameters2018-09-13T12:31:58+02:00Ghost UserIssue with Limiting ADER-DG combined with Material ParametersMaurizio's observations
-----------------------
1. If I use the linear kernerl for the "linear elastic part", the NCP term is called sometime with Q==0, so since one component contains the density it divide by 0 at a certain time and th...Maurizio's observations
-----------------------
1. If I use the linear kernerl for the "linear elastic part", the NCP term is called sometime with Q==0, so since one component contains the density it divide by 0 at a certain time and this destroy the solution. In this case if I simply add a check on Q, like if(max(|Q|)<1.e-13) return zero, then it seems to work fine. Also this is strange but maybe we have to better undestand exactly where the wrong call take place.
2. If I use parameters for the material and the linear kernel it seems to work fine.
3. If I use parameters for the material in combination with the limiter, godunov limiter-type, I get a completelly wrong (and unstable) solution, even if I simply add the parameters in the spec file but I don't really use them in the PDE system. In this case if I use musclhancock I simply does not get the solution due to an error in the first time step.
TODOs:
--------------
We currently do not know if it is a problem of the coupling or of the
FV solvers.
1. ~~Does the pure FV solver work correctly with parameters?~~ Yes. It appears so.
2. Does the nonlinear limiting ADER-DG solver work correctly with parameters? No, as shown below.
An error appears at the interface of ADER-DG and FV cells in an experiment where a local recomputation
is performed.
![image](/uploads/549ee942b71bf6adc4640a8555147257/image.png)
~~This might indicate that the DG->FV projectors are still wrong. Sometimes I wish someone wrote some proper unit tests ;-)~~
Apparently, the error does not appear if the limiter domain is static. This would imply
that projectors are correct ~~but something goes wrong in the recomputation.~~
![image](/uploads/c13830aa15de648ff5b73d2d0edbbb3c/image.png)
![image](/uploads/e9b97157968bff16a69f2f2096400a5e/image.png)
The recomputation algorithm was correct. The issue was in the ``updateSolution`` function where
the backup of the previous solution did not take parameters into account.
https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/248Dynamic AMR Infinite Loop Scenario2019-09-20T15:46:24+02:00Ghost UserDynamic AMR Infinite Loop ScenarioFound a situation where Ancestors are not able to erase their children and the mesh refinement ends up
in an infinite loop.
A few affected cells
--------------------
```
47.8326 info (solverNumber:0,neighbourMergePerform...Found a situation where Ancestors are not able to erase their children and the mesh refinement ends up
in an infinite loop.
A few affected cells
--------------------
```
47.8326 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:41,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.481481],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,0,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8328 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:41,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.222222,0.481481],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,0,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.833 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:41,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.222222,0.518519],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,0,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8332 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:41,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.518519],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,0,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.857 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:36,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.222222,0.407407],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,1,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8572 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:36,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.407407],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,0,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8575 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:36,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.37037],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[1,0,1,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8577 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:36,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.222222,0.37037],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,3,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[0,0,2,0],communicationStatus:1,facewiseRefinementStatus:[-2,-2,-1,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.858 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:36,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.333333],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[2,0,1,0],communicationStatus:1,facewiseRefinementStatus:[-1,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8736 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:9,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.37037,0.222222],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,3,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[2,0,0,0],communicationStatus:1,facewiseRefinementStatus:[-1,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8739 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:9,parentCellLevel:-1,parentOffset:[-1,-1],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.333333,0.259259],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,3,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[1,0,2,0],communicationStatus:1,facewiseRefinementStatus:[-2,-2,-1,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8747 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:62,parentCellLevel:3,parentOffset:[0.222222,0.222222],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.296296,0.296296],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[4,4,4,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[1,0,1,0],communicationStatus:0,facewiseRefinementStatus:[-2,-2,-2,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8748 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:62,parentCellLevel:3,parentOffset:[0.222222,0.222222],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.259259,0.296296],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,3,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[2,0,2,1],communicationStatus:1,facewiseRefinementStatus:[-1,-2,-1,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
47.8752 info (solverNumber:0,neighbourMergePerformed:[0,0,0,0],hasCompletedTimeStep:1,parentIndex:62,parentCellLevel:3,parentOffset:[0.222222,0.222222],hasVirtualChildren:0,type:Ancestor,refinementEvent:ErasingChildrenRequested,level:4,offset:[0.296296,0.259259],size:[0.037037,0.037037],previousCorrectorTimeStamp:1.79769e+308,previousCorrectorTimeStepSize:0,correctorTimeStepSize:0,correctorTimeStamp:0.140328,predictorTimeStepSize:0,predictorTimeStamp:0.140328,solution:-1,solutionAverages:-1,solutionCompressed:-1,previousSolution:-1,previousSolutionAverages:-1,previousSolutionCompressed:-1,update:-1,updateAverages:-1,updateCompressed:-1,extrapolatedPredictor:-1,extrapolatedPredictorAverages:-1,extrapolatedPredictorCompressed:-1,fluctuation:-1,fluctuationAverages:-1,fluctuationCompressed:-1,solutionMin:-1,solutionMax:-1,facewiseAugmentationStatus:[3,4,3,4],augmentationStatus:4,previousAugmentationStatus:4,facewiseCommunicationStatus:[2,1,2,0],communicationStatus:1,facewiseRefinementStatus:[-1,-2,-1,-2],refinementFlag:0,refinementStatus:-2,previousRefinementStatus:-1,iterationsToCureTroubledCell:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1)
```
Spec file for reproducing the error
-----------------------------------
```
exahype-project Euler
peano-kernel-path const = ./Peano
exahype-path const = ./ExaHyPE
output-directory const = ./ApplicationExamples/Euler/Euler_ADERDG
architecture const = noarch
computational-domain
dimension const = 2
width = 1.0, 1.0, 1.0
offset = 0.0, 0.0, 0.0
end-time = 1.001
end computational-domain
shared-memory
identifier = dummy
configure = {background-tasks:4}
cores = 8
properties-file = sharedmemory.properties
end shared-memory
distributed-memory
identifier = static_load_balancing
configure = {hotspot,fair,ranks_per_node:4}
buffer-size = 64
timeout = 240
end distributed-memory
global-optimisation
fuse-algorithmic-steps = on
fuse-algorithmic-steps-factor = 0.99
spawn-predictor-as-background-thread = on
spawn-amr-background-threads = off
/* 0.0 und 0.8 sind schon mal zwei Faktoren */
disable-vertex-exchange-in-time-steps = on
time-step-batch-factor = 1.0
disable-metadata-exchange-in-batched-time-steps = on
double-compression = 0.0
spawn-double-compression-as-background-thread = off
end global-optimisation
solver ADER-DG EulerSolver_ADERDG
variables const = rho:1,j:3,E:1
order const = 3
/* 27 points: 0.05, 9 points: 0.15 */
maximum-mesh-size = 0.4
maximum-mesh-depth = 3
halo-cells = 1
time-stepping = globalfixed
type const = nonlinear
terms const = flux
optimisation const = generic,usestack
language const = C
constants = reference:entropywave
plot vtu::Cartesian::vertices::ascii ErrorPlotter
// abserrorl1percell[nvar],q[nvar],qanalytical[nvar]
variables const = 15
time = 0.0
repeat = 1e-2
output = ./errors
end plot
end solver
end exahype-project
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/247Toolkit2: Make subprocess invocation of ExaHyPE main code optional2018-09-06T15:37:41+02:00Ghost UserToolkit2: Make subprocess invocation of ExaHyPE main code optionalSome people might not like the idea that the ExaHyPE code calls the Toolkit in order to (pre)parse specification files.
We should offer a specfile option within the specfiles to allow to generate code which does not calls a subprocess b...Some people might not like the idea that the ExaHyPE code calls the Toolkit in order to (pre)parse specification files.
We should offer a specfile option within the specfiles to allow to generate code which does not calls a subprocess but instead expects the input to be JSON.
This could be seen as advance hotfix when people report problems in complex MPI environments.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/245Toolkit2: Allow users to share binaries, move them accross computers, etc.2019-03-21T10:47:08+01:00Ghost UserToolkit2: Allow users to share binaries, move them accross computers, etc.The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises p...The new ExaHyPE Parser C++ infrastructure currently does a `suprocess` to call the Toolkit in order to convert old-fashioned specification files. To do so, the call to `Toolkit/toolkit.sh` is hardcoded, including the path.
This raises problems in certain use cases:
* The user shares his Executable to another user on the system/cluster but does not make the access permissions correctly for the Toolkit
* The user copies only the Executable to another machine but not the overall Code (especially not the Toolkit code)
* The user renames the path to his installation (probably when cleaning up his home directory) but wants to keep an ExaHyPE build working (obviously this is not possible)
We have no solution for all these use cases, but we should include checks in the C++ code to deal with them:
* Check whether `Path/to/Toolkit/toolkit.sh` exists, is readable and executablehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/242Toolkit2: Fix old merge2019-03-21T10:46:28+01:00Ghost UserToolkit2: Fix old mergehttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix...https://gitlab.lrz.de/exahype/ExaHyPE-Engine/commit/d92031f56b4bf6b6ba92f1d774cc9271ec6d13c5#note_215226
@Sven: Check whether this is done or not.
Two changes I did and you unfortunately undid with your merge (should be easy to fix though):
* Make sure you are using `ValueError` instead of `JSONDecodeError(ValueError)`.
Otherwise, the code requires python3 version>=3.5.0.
This is a typical error message you get:
```
controller.py:215(getSpec):ERROR Could not read specification file '../Euler_ADERDG.exahype': 'module' object has no attribute 'JSONDecodeError'
```
* Make sure `mexa.py` is python3.
I regex-replaced
`print (".+"\s*(%\s*\(.+\))?)$` with `print(\1)`https://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/238Toolkit2: OmniReader needs fix2018-08-14T15:56:04+02:00Ghost UserToolkit2: OmniReader needs fixThe current "Omni" specfile reader fails more or less silently if no reader had success. Instead, it should then choose one mandatory reader by the filename extension of the read-in-file. Otherwise users won't be able to debug broken spe...The current "Omni" specfile reader fails more or less silently if no reader had success. Instead, it should then choose one mandatory reader by the filename extension of the read-in-file. Otherwise users won't be able to debug broken specfiles.
Easy task, will do so today.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/237Toolkit extensibility threatened by java method size limit2018-09-10T19:37:48+02:00Ghost UserToolkit extensibility threatened by java method size limitProblem description
-------------------
When adding a few more tokens to the `exahype.grammar` file, the ExaHyPE Toolkit does not compile
anymore. The compilation stops with the following error:
```
javac -cp ../lib/commons-cli.jar -sou...Problem description
-------------------
When adding a few more tokens to the `exahype.grammar` file, the ExaHyPE Toolkit does not compile
anymore. The compilation stops with the following error:
```
javac -cp ../lib/commons-cli.jar -sourcepath . eu/exahype/GenerateSolverRegistration.java
eu/exahype/parser/Parser.java:104: error: code too large
public Start parse() throws ParserException, LexerException, IOException
^
1 error
```
Function `parse()` in file `eu/exahype/parser/Parser.java` contains a large `switch`-`case` statement
considering nearly 3000 cases and has more than 17000 lines of code.
`Parser.java` is unfortunately autogenerated by SableCC.
Further reading:
* https://dzone.com/articles/method-size-limit-java
* https://stackoverflow.com/a/17422590
The Typical *Let's rewrite everything!* Proposal
------------------------------------------------
From my point of view, above issue is just another reason why we should abandon SableCC grammars and switch to a proper data serialisation
format like JSON or YAML (internally). Validation can be performed via JSON schemata. It would be still possible
to keep our current specification file format. We would just introduce a precompilation step.
Additionally, we could consider to rewrite the toolkit in python. A lot is realised via template files anyway and
the code generator for the optimised kernels is written in python, too.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/236Make mexa more friendly in ExaHyPE2019-03-21T10:45:51+01:00Ghost UserMake mexa more friendly in ExaHyPECurrently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind...Currently the applications which use the [meta-specfile parameter system](https://bitbucket.org/svek/mexa) (i.e. CCZ4 and GRMHD) have small childhood diseases:
* They are very verbose in output at startup. `mexafile::toString()` is kind of too noisy and should instead print something more human-readable (such as `foo = bar [ref]` instead `eq(foo, bar, ref)`), probably one `tarch:::logInfo` per line.
* In the current usage, `foo = mf[key].as_double()` where `mf` is a mexafile, if the key is in the wrong data type (in this example: not castable as double), it spills out an error message *without* any reference where the error occured, only way to find it is to start with `gdb` and to go up the stack trace. This is exactly against the philosophy of mexa where the parameter source should *always* be dragged along, also with the `mexa::value` type. This needs to be implemented and tested.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/233Begin and End iteration in Solver Class?2019-03-21T10:48:03+01:00Ghost UserBegin and End iteration in Solver Class?Hi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youHi,
is it possible to have a begin and end iteration in user solver class in order to couple other codes to the solver?
thank youhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/231linking peano2018-08-01T16:03:47+02:00Ghost Userlinking peanoHi,
it seems Run.sh is outdated.Hi,
it seems Run.sh is outdated.https://gitlab.lrz.de/exahype/ExaHyPE-Documentation/-/issues/1Guidebook and header comments2018-06-18T22:44:53+02:00Ghost UserGuidebook and header commentsGuidebook page 39, "There is a routine adjustPointSolution that allow us to setup the initial grid. Alternatively, we can also use adjustSolution". There is only one function named adjustSolution in the solver.
Also header of adjustSol...Guidebook page 39, "There is a routine adjustPointSolution that allow us to setup the initial grid. Alternatively, we can also use adjustSolution". There is only one function named adjustSolution in the solver.
Also header of adjustSolution() in mysolver.h says "@see FiniteVolumesSolver" which doesn't exist.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/227Reflection for the parameter system2019-03-07T20:43:51+01:00Ghost UserReflection for the parameter systemCurrently, using runtime parameters requires to parse them somewhere, leading to code like
```c++
void GeometricBallLimiting::readParameters(const mexa::mexafile& para) {
radius = para["radius"].as_double();
std::string where = para...Currently, using runtime parameters requires to parse them somewhere, leading to code like
```c++
void GeometricBallLimiting::readParameters(const mexa::mexafile& para) {
radius = para["radius"].as_double();
std::string where = para["where"].as_string();
toLower(where);
if(where == "inside") limit_inside = true;
else if(where == "outside") limit_inside = false;
else {
logError("readParameters()", "Valid values for where are 'inside' and 'outside'. Keeping default.");
}
logInfo("readParameters()", "Limiting " << (limit_inside ? "within" : "outside of") << " a ball with radius=" << radius);
}
```
associated to a structure where the parameters are stored,
```c++
struct GeometricBallLimiting : public LimitingCriterionCode {
double radius; ///< Radius of the ball (default -1 = no limiting)
bool limit_inside; ///< Whether to limit inside or outside (default inside)
GeometricBallLimiting() : radius(-1), limit_inside(true) {}
bool isPhysicallyAdmissible(IS_PHYSICALLY_ADMISSIBLE_SIGNATURE) const override;
void readParameters(const mexa::mexafile& parameters) override;
};
```
This is lot's of overhead and really redundant.
In Cactus, the user can declare parameters *including their description/meaning and valid values* in a nice language, they are then made available as a structure by the glue code, all the parsing is abstracted away. Example of a Cactus parameter file (CCL file):
```
real eta "Damping coefficient for the Gamma Driver" STEERABLE=always
{
0:* :: "should be 1-2/M"
}0.2
KEYWORD evol_type "Which set of equations to evolve"
{
"BSSN" :: "traditional BSSN"
"Z4c" :: "Z4c"
"CCZ4" :: "(Covariant) and conformal Z4"
"FOCCZ4" :: "First order formulation of the CCZ4"
}"Z4c"
boolean include_theta_source "Only FO-CCZ4: set to false to remove the algebraic source terms of the type -2*Theta" STEERABLE=always
{
} yes
```
In the code, one then just has something like
```c++
struct parameters {
double eta;
std::string evol_type;
boolean include_theta_source;
}
```
which is already filled nicely with values.
While at least I certainly don't want to code such a glue code for ExaHyPE, in contrast with minimal effort we can get much better then the current MEXA system. In fact, it would be nice to use *OOP reflection* to automatically register class attributes for common data types (int/double/bool/string). That means I would be fine with writing
```c++
struct GeometricBallLimiting {
double radius;
enum class limit_at { inside, outside };
REGISTER_PARAM(radius, DEFAULT(-1), "Radius of the ball");
REGISTER_PARAM(limit_at, DEFAULT(limit_at::inside), "Where to limit");
}
```
In fact, something like this is possible some macro magic.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/225Provide vectorized user functions in the optimized kernels2019-03-07T19:41:41+01:00Ghost UserProvide vectorized user functions in the optimized kernelsThis is something Jean Matthieu should do.
Then we can immediately test a couple of PDEs, such as Euler, GRMHD or CCZ4. Dumbser shared his vectorized code also somewhere.This is something Jean Matthieu should do.
Then we can immediately test a couple of PDEs, such as Euler, GRMHD or CCZ4. Dumbser shared his vectorized code also somewhere.Jean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/224Numerical details how to evolve CCZ4 with FD2019-04-15T12:34:55+02:00Ghost UserNumerical details how to evolve CCZ4 with FDCollection of what was written by Dumbser in various E-Mails in order to proceed in the Runge Kutta - Finte Differencing code (Cactus/Antelope/Okapi):
### Dumbser, 3. April 2018 um 11:03: FO-CCZ4 with Finite differencing works
> since S...Collection of what was written by Dumbser in various E-Mails in order to proceed in the Runge Kutta - Finte Differencing code (Cactus/Antelope/Okapi):
### Dumbser, 3. April 2018 um 11:03: FO-CCZ4 with Finite differencing works
> since Sven has reported some difficulties with the implementation of FO-CCZ4 in the Einstein toolkit last week, and since I wanted to understand the potential problems in depth, I have simply written my own finite difference code for the Einstein equations, based on central finite differences in space and Runge-Kutta time integration. According to Sven's and Elias' description, this is exactly what you are also doing in Cactus, right? The implementation is straightforward, since FD schemes are extremely simple.
>
>
>
> To do my tests, I have just copy-pasted my Fortran subroutine PDEFusedSrcNCP into the finite difference code, and I then insert FD point values of Q and central FD approximations for the first spatial derivatives. To save CPU time, I have done all computations in 1D so far.
>
>
>
> Please find attached the results that I have obtained for the Gauge wave with amplitude A=0.01 and A=0.1 until a final time of t=1000. I have used sixth order central FD in space and a classical third order Runge-Kutta scheme in time. For FO-CCZ4, I have set all damping coefficients to zero (kappa1=kappa2=kappa3=0), and I use c=0 with e=2. Zero shift (sk=0) and harmonic lapse. CFL number based on e is set to CFL=0.5 at the moment. Now the important points:
>
>
>
> 1. Runge-Kutta O3 is for now preferrable over Runge-Kutta O4, since it is intrinsically dissipative. The reason is that the fourth order time derivative term in the Taylor series on the left hand side remains with RK3, while it cancels with RK4, and when moving the term q_tttt to the right hand side and after Cauchy-Kowalevsky procedure, it becomes a fourth order spatial derivative term with negative sign, which is good for stability (second spatial derivatives must have positive sign on the right hand side, fourth spatial derivatives must have negative sign for stability. this is easy to check via Fourier series and the dispersion relation of the PDE).
>
>
>
> 2. The RK3 alone is not enough to stabilize the scheme for the larger amplitude A=0.1 of the Gauge Wave, but it is sufficient for A=0.01. I therefore explicitly needed to subtract a term of the type - dt/dx*u_xxxx, which is essentially a fourth order Kreiss-Oliger-type dissipation with appropriately chosen viscosity coefficient.
>
>
>
> I will now replace the Kreiss-Oliger dissipation which I do not like with the numerical dissipation that you would have obtained with a Rusanov flux in a fourth order accurate finite volume scheme. In the end, the dissipation operator will again be written as a finite difference, but there I know at least exactly what is going on and we will exactly know the amount of dissipation to be put (it can only be a function of the largest eigenvalue). So there will be NO parameter to be tuned. I will keep you updated on this.
>
>
>
> From my own results I can conclude that everything is working as expected, i.e. you must have at least one bug in your implementation of FO-CCZ4 in Cactus; or you have run the tests with the wrong parameters (please use CFL=0.5 for the moment, Kreiss-Oliger dissipation with a viscosity factor so that you get -dt/dx*u_xxxx on the right hand side in the end, please set kappa1=kappa2=kappa3=0 and set e=2 and c=0 in FO-CCZ4). If your code still does not run, I can send you my finite difference Fortran code to help you with the debugging.
>
>
>
> While running and implementing my FD code for FO-CCZ4 I have also been working on the vectorization of FO-CCZ4 in ADER-DG. The interesting news: the finite difference code requires more than 20 microseconds per FD point update, and ADER-DG with the good new initial guess for the space-time polynomial and proper vectorization needs also about 20 microseconds per DOF update for FO-CCZ4, i.e. ADER-DG is indeed becoming competitive with FD, who would have every believed this last year :-) On the new 512bit vector machines of RSC in Moscow, we expect the PDE to run even twice as fast, since the vector registers are twice as large as the current state of the art. We are aiming at a time per DOF update of about 10 microseconds. I will keep you informed.
### Dumbser, 4. April 2018 um 10:51:
>
However, my latest experiments show that you can also use RK4 together with a finite-volume type dissipative operator, which is very simple to
implement and which does not require any parameters to be tuned. It will just replace the Kreiss-Oliger dissipation. And by the way: in this setting,
the scheme can be run with CFL=0.9, which is what we want. I will send around more details later.
### Dumbser, 4. April 2018 um 18:23
> there are again good news from the finite difference for FO-CCZ4 front. Instead of your classical Kreiss-Oliger dissipation, I suggest to use the following dissipation operator, which should simply be "added" to the time derivatives of
>
> all quantities on the right hand side, i.e.:
>
>
> ```
> dudt(:,i,j,k) = dudt(:,i,j,k) - 1.0/dx(1)* 3.0/256.0* smax * ( -15.0*u(:,i+1,j,k)-u(:,i+3,j,k)-15.0*u(:,i-1,j,k)+6.0*u(:,i+2,j,k)+20.0*u(:,i,j,k)+6.0*u(:,i-2,j,k)-u(:,i-3,j,k) )
> ```
>
>
> where dudt(:,i,j,k) is the time derivative of the discrete solution computed by the existing Fortran function PDEFusedSrcNCP and smax is the maximum eigenvalue in absolute value. This operator derives from
>
>
> ```
> - 1/dx(1)*( fp - fm ),
> ```
>
>
> where the dissipative flux fp is defined as
>
>
> ```
> fp = - 1/2 * smax * ( uR - uL ),
> ```
>
>
> and uR and uL are the central high order polynomial reconstructions of u evaluated at the cell interface x_i+1/2. The flux fm is the same, but on the left interface x_i-1/2.
>
>
>
> Please find attached the new results for the Gauge Wave with A=0.1 amplitude. Everything looks fine, i.e., the ADM constraints as well as the waveform at the final time. Note that this simulation was now run with the fourth order
> Runge-Kutta scheme in time and using a CFL number of CFL=0.9 based on the maximum eigenvalue.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/223Implement new Space time predictor without (variable number of) picard loops2019-04-15T12:34:30+02:00Ghost UserImplement new Space time predictor without (variable number of) picard loopsThe task is relatively easy: Diff Dumbsers fortran prototype (in repository) and check out the changes in the generic kernels.
From Dumbser, 11. März 2018 um 11:20:
> Wäre natürlich super, wenn Du meinen Fortran Code in C übersetzen kö...The task is relatively easy: Diff Dumbsers fortran prototype (in repository) and check out the changes in the generic kernels.
From Dumbser, 11. März 2018 um 11:20:
> Wäre natürlich super, wenn Du meinen Fortran Code in C übersetzen könntest.
> Wenn es Probleme gibt,
> machen wir wieder eine Skype session.
> Das Format der Schleifen und der nötigen Berechnungen ist quasi dasselbe wie
> für alle anderen Rechnungen
> im space-time predictor, d.h. da kann man sehr viel übernehmen. Nur, dass
> man den Zeitindex nicht mehr
> mitschleppen muss, sondern nur im Raum arbeiten kann. Der einzige Kernel der
> geändert werden muss ist der
> space-time predictor (in 2D und 3D).
>
> Ich würde nur den second und third order initial guess implementieren, siehe
> den Code in
> SpaceTimePredictor.f90 unter
>
> #ifdef SECOND_ORDER_INITIAL_GUESS
>
> #ifdef THIRD_ORDER_INITIAL_GUESS
>
> Ich habe mich diese Woche auf Scaling und den Vergleich Runge-Kutta DG /
> ADER-DG konzentriert,
> d.h. an dem 2D FO-fCCZ4 habe ich nicht mehr weitergearbeitet. Ich will erst
> das GRMHD Paper vom
> Tisch haben.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/222Fix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpph2019-04-15T12:41:12+02:00Ghost UserFix the M/h computation in the CCZ4/Writers/TimingStatisticsWriter.cpphFrom a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the tim...From a mail at Luke:
>
I just noticed there is something wrong in the M/h determination:
>
As explained in my last mail to Tobias and you, I just divide these
two numbers. However, the time in the first column of stdout measures
the time since program start.
>
In ExaHyPE, the grid setup sometimes takes a considerable amount --
like 10 minutes. If you measure the M/h straight after the first
timesteps after these 10 minutes, you get of course totally wrong
numbers. However, if you measure after 1000 minutes runtime, the 10
minutes grid setup do not change the result so much.
>
It is not hard to substract the time the grid setup needs in order to
improve the correctness of the number. You can do this either by hand
(just look up when the first time step started) or we can do this in
code (CCZ4/Writers/TimingStatisticsWriter.cpph).https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/221Deeply check the public repository for CCZ42019-03-07T19:41:06+01:00Ghost UserDeeply check the public repository for CCZ4It is at https://github.com/exahype/exahype and we don't want to have the CCZ4 system in the code or any old commits. Make this sure by inspecting the code.
Cannot do it now since the repo is 70MB in size and I'm in a train with a bad w...It is at https://github.com/exahype/exahype and we don't want to have the CCZ4 system in the code or any old commits. Make this sure by inspecting the code.
Cannot do it now since the repo is 70MB in size and I'm in a train with a bad wifi.