ExaHyPE issueshttps://gitlab.lrz.de/groups/exahype/-/issues2019-05-08T13:41:02+02:00https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/271Specification File Defaults in C++ Parser2019-05-08T13:41:02+02:00Ghost UserSpecification File Defaults in C++ ParserWe have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema....We have a C++ JSON file parser.
The specification file schema is a JSON file itself.
Hence, we could read default values also directly from the schema.
**Edit:**
We could generate most of the C/C++ parser directly from the JSON schema.
**Edit 2:**
There is now also a C/C++ header-only library for
JSON file validation.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/239Toolkit2: Be consistent with interactivity2018-09-10T19:38:15+02:00Ghost UserToolkit2: Be consistent with interactivityThe toolkit.sh is blocking for user input if dependency problems occur. Will be fatal when called from Engine. Simple solution: Take --interactive etc flags into account.
Can fix that.The toolkit.sh is blocking for user input if dependency problems occur. Will be fatal when called from Engine. Simple solution: Take --interactive etc flags into account.
Can fix that.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/206CCZ4: Run BH until T=10002018-02-09T22:50:28+01:00Ghost UserCCZ4: Run BH until T=1000We need some setup of ExaHyPE,CCZ4+Limiter on a reasonable grid (L>25, dx<0.1). This ticket shall report the progress. Just describe your runs in the comments.
*Explanation of notation: The unit "M/h" means "simulation time / physical t...We need some setup of ExaHyPE,CCZ4+Limiter on a reasonable grid (L>25, dx<0.1). This ticket shall report the progress. Just describe your runs in the comments.
*Explanation of notation: The unit "M/h" means "simulation time / physical time in hours". M means "Mass" and roughly indicates for us that we refer to the simulation time.*https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/203Peano: Geometrical comparisons must always use relative tolerance2018-02-02T14:12:26+01:00Ghost UserPeano: Geometrical comparisons must always use relative toleranceThe tarch::la:: routines use usually an absolute tolerance (default: machine precision)
for comparing floating point numbers.
This is problematic for numbers with large absolute values.
Fix: These numbers must be normalised and scaled t...The tarch::la:: routines use usually an absolute tolerance (default: machine precision)
for comparing floating point numbers.
This is problematic for numbers with large absolute values.
Fix: These numbers must be normalised and scaled to range [-1,1] before
comparing with respect to the tolerance.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/70Discussion topics for a discussion ("Coding") day at Oct 23., 2016 in Munich2018-06-15T15:13:43+02:00Ghost UserDiscussion topics for a discussion ("Coding") day at Oct 23., 2016 in Munich* Kernel situation
* Trento will not be able to implement new numerics into C++ "nested loop" kernels
* We invested two weeks of finding bugs porting Fortran Z4 to ExaHyPE -- this is a dead end!
* We either need modern Fortran kern...* Kernel situation
* Trento will not be able to implement new numerics into C++ "nested loop" kernels
* We invested two weeks of finding bugs porting Fortran Z4 to ExaHyPE -- this is a dead end!
* We either need modern Fortran kernels or a good C++ linear algebra library (there are plenty of them)
* (Generic) research kernels might be in a different shape than optimized kernels!
* What is ExaHyPE?
* If it shall be a standalone *application*, then it should provide the best support for parameters, etc. as possible
* If it shall serve as a "utility", end users have to come up with individual solutions on theirselves. Both is fine, but there should be a common idea everybody is aware of.
* Workflow
* Durham cannot provide implementation support (code monkeying) for ExaHyPE applications in this intensity anymore
* Frankfurt cannot provide support for running benchmarks and (parameter) test in this intensity anymore
* Fortran situation in Applications
* MHD was converted to C++ with surprising results in stability and speed
* What's the joint aim for the team? There is more and more Fortran code (Applications get bigger), cf. the `Z4` application
* API and Code Generation
* Kernel calls should be method calls instead of templated static function calls
* Toolkit only needs to provide initial "scaffold" code. In 90% of applications, generated code is now in the repo, edited after generation and gets overwritten regularly.
* Toolkit should not distribute constants in the generated code but collect them in a unique file (`GeneratedConstants.h`). Paradigm: Generate maintainable code.
* Specification file format
* There is a lot to say here. We should aggree on a whishlist of features
* We could also agree to keep the spec files small and let the problem be solved by the users
* Treatment of external libraries and the build system
* Today is already tomorrow -- I have secretly introduced dependencies on GSL, BLAS due to the Astrophysics Initial Data codes.
* A decision should also affect the treatment of Peano.
* IO
* VTK Fileformat (alternatives)
* Does it make sense to define a tailored ExaHyPE output format ourselves?
* Efficient batch processing 3D VTK to movie plotting
* Unit tests
* Mathematically/Physically, there is little point in testing the numerical scheme with random data at every ExyHyPE `DEBUG or Asserts` run.
* Instead, simple but well understood tests with analytic solutions should be run (ie. via Jenkins). We should come up with a list of these tests (ie: Advection, ShuVortex, MHD Wave, Gauge Wave, etc.)
*Please just add points to this list as you whish*
# Assignments in Discussion at 25. Oct 2016
At Oct 25, in Garching there were Tobias, Vasco, Dominik, Alejandro and Sven. We discussed these points and even more and concluded these assignments:
* Fortran support (VV)
* Call linear kernels with temp arrays (DC)
* Non-conservative parts (SK) - done, cf. https://gitlab.lrz.de/gi26det/ExaHyPE/commit/1723512d16acbf118f43465d78d252cda55e9bc6 and similar
* Split of the repositories (SK) - tracked at gi26det/ExaHyPE#55
* Start the release page & remove binaries from GIT (VV) - as followup for gi26det/ExaHyPE#55, right?
* Find new Jour Fix time (incl. Dominic and Trento) (VV)
* Nightly convergence tests (SK+VV) - tracked at gi26det/ExaHyPE#74
* Period BCs: Organise small coding week in Durham (VV+TW)
* Replace static function + templates with std::function (SK+TW) - tracked at gi26det/ExaHyPE#75
* Extend Solver::solutionAdjustment to handle point sources (DC+VV)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/304Merge with Latest Peano to resolve debug logging errors2020-01-15T11:36:58+01:00Samuel TootleMerge with Latest Peano to resolve debug logging errorsWhen compiling with MODE=Debug, various errors arise related to Peano logging. I checked the Peano master repo and discovered that this issue has been resolved, however, this version has not yet been synched with Exahype sub-modules. T...When compiling with MODE=Debug, various errors arise related to Peano logging. I checked the Peano master repo and discovered that this issue has been resolved, however, this version has not yet been synched with Exahype sub-modules. This was tested using updateSubmodules.sh which results in reverting to the old git hash even after manually pulling Peano/master.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/303error in compilation2019-10-15T09:38:50+02:00Duo Lid.li@lmu.deerror in compilationwhen compiling master Exahype, i have a bunch of errors with GaussLobattoBasis.hsnippet:
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from ...when compiling master Exahype, i have a bunch of errors with GaussLobattoBasis.hsnippet:
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(1): error: expected a declaration
namespace kernels {
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(22): warning #12: parsing restarts here after previous syntax error
extern double nodes_1[1+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(23): error: invalid storage class for a class member
extern double nodes_2[2+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(24): error: invalid storage class for a class member
extern double nodes_3[3+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(25): error: invalid storage class for a class member
extern double nodes_4[4+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(26): error: invalid storage class for a class member
extern double nodes_5[5+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(27): error: invalid storage class for a class member
extern double nodes_6[6+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(28): error: invalid storage class for a class member
extern double nodes_7[7+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(29): error: invalid storage class for a class member
extern double nodes_8[8+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(30): error: invalid storage class for a class member
extern double nodes_9[9+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(31): error: invalid storage class for a class member
extern double nodes_10[10+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(32): error: invalid storage class for a class member
extern double nodes_11[11+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(33): error: invalid storage class for a class member
extern double nodes_12[12+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(34): error: invalid storage class for a class member
extern double nodes_13[13+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(35): error: invalid storage class for a class member
extern double nodes_14[14+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(36): error: invalid storage class for a class member
extern double nodes_15[15+1];
^
In file included from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/GaussLobattoBasis.h(20),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/aderdg/generic/Kernels.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/../Curvilinear/CurvilinearTransformation.h(6),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/include/Context/ContextCurvilinear.h(11),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.h(28),
from /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ApplicationExamples/ExaSeis/DynamicRupture/TPV29/SlipWeakeningSolver.cpp(9):
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/kernels/generated/GaussLobattoBasis.hsnippet(37): error: invalid storage class for a class member
extern double* nodes[15+1];
does any one have any idea?https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/302error when use dynamic AMR in LimitedADERDG2020-11-20T15:10:48+01:00Duo Lid.li@lmu.deerror when use dynamic AMR in LimitedADERDGparameter tarch::parallel::Node::getInstance().getRank(): 17
parameter "if the neighbour data buffer is empty, you have perhaps forgotten to call releaseMessages() on the heap in the traversal before": if the neighbour data buffer is emp...parameter tarch::parallel::Node::getInstance().getRank(): 17
parameter "if the neighbour data buffer is empty, you have perhaps forgotten to call releaseMessages() on the heap in the traversal before": if the neighbour data buffer is empty, you have perhaps forgotten to call releaseMessages() on the heap in the traversal before
ExaHyPE-Diffuse: /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./Peano/peano/../peano/heap/BoundaryDataExchanger.cpph:282: void peano::heap::BoundaryDataExchanger<Data, SendReceiveTaskType, VectorContainer>::freeAllMessagesInDeployBuffer() [with Data = char, SendReceiveTaskType = peano::heap::SendReceiveTask<char>, VectorContainer = std::vector<char, std::allocator<char>>]: Assertion `false' failed.https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/300Job failed with nodes=82019-09-20T15:30:57+02:00Duo Lid.li@lmu.deJob failed with nodes=8The same job works with nodes=2 on NG but failed with more nodes e.g. nodes=8.
OMP=8 and --ntasks-per-node=6
60.199790 [i01r01c04s06.sng.lrz.de],rank:40, core:16, tid:6 error exahype::solvers::ADERDGSolver::surfaceIntegral(......The same job works with nodes=2 on NG but failed with more nodes e.g. nodes=8.
OMP=8 and --ntasks-per-node=6
60.199790 [i01r01c04s06.sng.lrz.de],rank:40, core:16, tid:6 error exahype::solvers::ADERDGSolver::surfaceIntegral(...) Riemann solve was not performed on all faces of cell= (solverNumber:0,neighbourMergePerformed:[^A,^A,^A,^A,^@,^A],parentIndex:-1,type:Leaf,parentType:undefined,level:4,offset:[4,14,14],size:[1,1,1],previousTimeStamp:0,previousTimeStepSize:0.002805,timeStepSize:0.002805,timeStamp:0.002805,solutionIndex:288,solutionAveragesIndex:291,solutionCompressedIndex:-1,solution:0x7f2c50061600,solutionAverages:0x7f2c500d0e00,solutionCompressed:0,previousSolutionIndex:289,previousSolutionAveragesIndex:290,previousSolutionCompressedIndex:-1,previousSolution:0x7f2c50060100,previousSolutionAverages:0x7f2c500d0f00,previousSolutionCompressed:0,updateIndex:292,updateAveragesIndex:293,updateCompressedIndex:-1,update:0x7f2c50066080,updateAverages:0x7f2c500d7380,updateCompressed:0,extrapolatedPredictorIndex:294,extrapolatedPredictorAveragesIndex:295,extrapolatedPredictorCompressedIndex:-1,extrapolatedPredictor:0x7f2c4f9b7300,extrapolatedPredictorAverages:0x7f2c5008d800,extrapolatedPredictorCompressed:0,extrapolatedPredictorGradientIndex:-1,extrapolatedPredictorGradient:0,fluctuationIndex:296,fluctuationAveragesIndex:297,fluctuationCompressedIndex:-1,fluctuation:0x7f2c4f9bbb00,fluctuationAverages:0x7f2c5006b400,fluctuationCompressed:0,solutionMinIndex:298,solutionMaxIndex:299,solutionMin:0x7f2c50081c00,solutionMax:0x7f2c50081a00,facewiseAugmentationStatus:[2,2,2,1,3,1],augmentationStatus:2,facewiseCommunicationStatus:[2,2,2,2,1,2],communicationStatus:2,facewiseRefinementStatus:[0,0,0,0,0,0],refinementStatus:0,previousRefinementStatus:0,refinementFlag:0,compressionState:Uncompressed,bytesPerDoFInPreviousSolution:-1,bytesPerDoFInSolution:-1,bytesPerDoFInUpdate:-1,bytesPerDoFInExtrapolatedPredictor:-1,bytesPerDoFInFluctuation:-1,creation:UniformRefinement) (file:/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver.cpp,line:1188)https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/299Compilation error2019-10-16T10:05:11+02:00Duo Lid.li@lmu.deCompilation errorI compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument...I compiled with mpi.intel/2017 and tbb/2017, after update Exahype and submodules.
Here attached the errors:
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(42): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lQhbnd, _MM_HINT_NTA);
^
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp(43): error: argument of type "double *" is incompatible with parameter of type "const char *"
_mm_prefetch(lFhbnd, _MM_HINT_NTA);
^
compilation aborted for /import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.cpp (code 2)
/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/import/deadlock-data/dli/ExaHyPE/ExaHyPE-Engine/./ExaHyPE/exahype/solvers/ADERDGSolver_ProlongationJob.o’ failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/298Compilation error in peano::heap2019-09-17T12:34:46+02:00Duo Lid.li@lmu.deCompilation error in peano::heap/exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDro.../exahype/mappings/PredictionOrLocalRecomputation.o
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp(228): error: class "peano::heap::AbstractHeap" has no member "allHeapsDropReceivedBoundaryData"
peano::heap::AbstractHeap::allHeapsDropReceivedBoundaryData();
^
compilation aborted for /hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.cpp (code 2)
/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/Makefile:626: recipe for target '/hppfs/work/pr63qo/di52lak2/ExaHyPE_deadlock/ExaHyPE-Engine/./ExaHyPE/exahype/mappings/DropNeighbourMessages.o' failedhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/297FiniteVolumeSolver error about time step2020-11-20T17:30:31+01:00Duo Lid.li@lmu.deFiniteVolumeSolver error about time stepWhen running FV, there is this error. I use CFL=0.7. How to fix the warning or how does it matter to the code.
```cpp
if ( !tarch::la::equals(cellDescription.getTimeStepSize(), 0.0) && tarch::la::smaller(admissibleTimeStepSize,cellDesc...When running FV, there is this error. I use CFL=0.7. How to fix the warning or how does it matter to the code.
```cpp
if ( !tarch::la::equals(cellDescription.getTimeStepSize(), 0.0) && tarch::la::smaller(admissibleTimeStepSize,cellDescription.getTimeStepSize()) ) {
logWarning("updateSolution(...)","Finite volumes solver time step size harmed CFL condition. dt="<<
cellDescription.getTimeStepSize()<<", dt_adm=" << admissibleTimeStepSize << ". cell=" <<cellDescription.toString());
}
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/296GradQ format2019-09-21T15:09:46+02:00Jean-Matthieu GallardGradQ formatThe format of gradQ (used by NCP and ViscousFlux) is not consistent
* Linear => like F for the flux PDE so gradQ[nDim][nVar]
* Nonlinear => all in one dimension gradQ[nDim\*nVar]
* FV => all in one dimension but with param gradQ[nDim\*...The format of gradQ (used by NCP and ViscousFlux) is not consistent
* Linear => like F for the flux PDE so gradQ[nDim][nVar]
* Nonlinear => all in one dimension gradQ[nDim\*nVar]
* FV => all in one dimension but with param gradQ[nDim\*nData]
Changing this will change the user API and break some application, however a simple adapter could allow them to run until a more in depth correction is done.
Do we need the parameter in FV?
This would also be a good time to maybe change BgradQ similarly if possible (I don't know it it would make sense) so that linear and nonlinear have the same API, even if it introduce a slight inefficiency in nonlinear/FV
@reinarz @domcha @ga24dib @leo.rannabauerJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/295Local Time Stepping Plan2019-09-06T14:51:45+02:00Ghost UserLocal Time Stepping PlanWe could rather quickly implement a local time steppging version a la SeisSol
where we store the full space-time face data only for faces of coarse grid cells
along mesh resolution transitions.
Steps (in German):
* [ ] Aufbrechen des ...We could rather quickly implement a local time steppging version a la SeisSol
where we store the full space-time face data only for faces of coarse grid cells
along mesh resolution transitions.
Steps (in German):
* [ ] Aufbrechen des Extrapolations-Operators (Cell Boundary -> Single Face)
* [ ] Aufbrechen der Face Data Felder. We need one pointer/index per face.
* [ ] Mithilfe meiner Marker fuer gewisse Faces space-time Face Data speichern
* [ ] Den space Prolongationsoperator mit einem space-time Operator ersetzen (Face Prolongation -> "Volume" Prolongation (vorhanden))
* [ ] Counter im State einfuehren und dann entsprechend des Wertes nur bestimmte Levels an* [ ] und ausschalten, ginge
mit Hilfe Deiner level Information in den MappingSpecifications
* [ ] Nur am Anfang eines Batches die alte Loesung sichern (implementiert)
* [ ] Batchgroesse entsprechend des aktuellen tiefsten Verfeinerungslevels berechnen
* [ ] Rollback zu Anfang des Batches, falls das Gitter nicht gepasst hat.
Some implementational aspects
-----------------------------
Some preparational work has already been done.
* No changes to the current faceIntegral procedure need to be performed
as we already skip the integral where a Leaf cell shares an interface with a Refined ("Parent") cell.
```
const int dofsPerFace = getBndFluxSize();
for (int direction=0; direction<DIMENSIONS; direction++) {
for (int orientation=0; orientation<2; orientation++) {
const int faceIndex=2*direction+orientation;
if ( cellDescription.getFacewiseAugmentationStatus(faceIndex)<MaximumAugmentationStatus ) { // ignore Ancestors
double* const lFhbnd = static_cast<double*>(cellDescription.getFluctuation()) + dofsPerFace * faceIndex;
faceIntegral(output,lFhbnd,direction,orientation,0/*implicit conversion*/,0,cellDescription.getSize(),
cellDescription.getTimeStepSize(),addToUpdate);
}
}
}
```
https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/294Halo Refinement Threshold2019-09-05T17:49:25+02:00Ghost UserHalo Refinement ThresholdAim:
Prevent that the mesh refinement iterations are triggered to often.
Background:
During the mesh refinement iterations, we refine the Leaf cell parents of those Virtual cells
that carry a refinement status greater than zero.
Cur...Aim:
Prevent that the mesh refinement iterations are triggered to often.
Background:
During the mesh refinement iterations, we refine the Leaf cell parents of those Virtual cells
that carry a refinement status greater than zero.
Currently, the time stepping iterations trigger refinement
as soon as a Virtual cell carries positive refinement status.
Especially with low order ADER-DG plus Limiter, mesh refinement is triggered quite often,
which seems to be related to the CFL time step size: "Shock does not stay "long" in the same cell".
Approach:
During the time stepping iterations, allow Virtual cells to carry
a refinement status smaller some positive threshold value.
Only if this threshold value is reached, trigger that
the mesh is adapted.
Additional, we could think about allowing erasing only every $k$ mesh adaptions (=set of mesh refinement iterations).https://gitlab.lrz.de/exahype/ExaHyPE-Documentation/-/issues/4Update list of available plotters2019-08-16T17:12:29+02:00Ghost UserUpdate list of available plottersWe should update the list of the available plotters we are supporting,
categorise them and explain them.
I used the following commands
```
#!/usr/bin/bash
files=$(find ExaHyPE/exahype/plotters/ -name "*.cpp")
for f in $files; do grep -...We should update the list of the available plotters we are supporting,
categorise them and explain them.
I used the following commands
```
#!/usr/bin/bash
files=$(find ExaHyPE/exahype/plotters/ -name "*.cpp")
for f in $files; do grep -A 1 "getIdentifier()" $f; done | grep return | grep --color=never -o -E "\".+\"" | tr -d '"'
```
to find the IDs of all existing plotters:
```
probe::ascii
Tecplot::Binary
Carpet::Cartesian::Vertices::HDF5
Carpet::Cartesian::Vertices::ASCII
Carpet::Cartesian::Vertices::HDF5
Carpet::Cartesian::Vertices::ASCII
user::defined
user::defined
Flash::hdf5
user::defined
probe::ascii
Peano::Cartesian::vertices::ascii
Peano::Cartesian::cells::ascii
Peano::Cartesian::vertices::hdf5
Peano::Cartesian::cells::hdf5
Peano::Cartesian::cells::ascii
Peano::Cartesian::cells::hdf5
Peano::Legendre::vertices::ascii
Peano::Legendre::cells::ascii
Peano::Legendre::vertices::hdf5
Peano::Legendre::cells::hdf5
csv::Legendre::vertices::ascii
csv::patches::ascii
vtk::Cartesian::vertices::ascii
vtk::Cartesian::vertices::binary
vtk::Cartesian::cells::ascii
vtk::Cartesian::cells::binary
vtu::Cartesian::vertices::ascii
vtu::Cartesian::vertices::binary
vtu::Cartesian::cells::ascii
vtu::Cartesian::cells::binary
vtk::Cartesian::vertices::limited::ascii
vtk::Cartesian::vertices::limited::binary
vtk::Cartesian::cells::limited::ascii
vtk::Cartesian::cells::limited::binary
vtu::Cartesian::vertices::limited::ascii
vtu::Cartesian::vertices::limited::binary
vtu::Cartesian::cells::limited::ascii
vtu::Cartesian::cells::limited::binary
vtk::Lobatto::vertices::ascii
vtk::Lobatto::vertices::binary
vtk::Lobatto::cells::ascii
vtk::Lobatto::cells::binary
vtu::Lobatto::vertices::ascii
vtu::Lobatto::vertices::binary
vtu::Lobatto::cells::ascii
vtu::Lobatto::cells::binary
vtk::Cartesian::subcells::limited::ascii
vtk::Cartesian::subcells::limited::binary
vtu::Cartesian::subcells::limited::ascii
vtu::Cartesian::subcells::limited::binary
vtk::Legendre::vertices::div::ascii
vtk::Legendre::vertices::div::binary
vtu::Legendre::vertices::div::ascii
vtu::Legendre::vertices::div::binary
vtk::patches::boxes::ascii
vtk::patches::boxes::binary
vtu::patches::boxes::ascii
vtk::patches::boxes::binary
vtk::patches::gaps::ascii
vtk::patches::gaps::binary
vtu::patches::gaps::ascii
vtk::patches::gaps::binary
vtk::Legendre::vertices::ascii
vtk::Legendre::vertices::binary
vtk::Legendre::cells::ascii
vtk::Legendre::cells::binary
vtu::Legendre::vertices::ascii
vtu::Legendre::vertices::binary
vtu::Legendre::cells::ascii
vtu::Legendre::cells::binary
```https://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/293Nans for gll nodes2019-08-14T15:37:26+02:00Leonhard RannabauerNans for gll nodesWe observe nans for the recently implemented gll nodes as soon as we work with amr on supermucng.
We start with a series of tests:
| Basis | Mesh | AMR | Arch | Opt | MPI | Works |
| ------ | ------ | ------ | ------ | ------ | ------ ...We observe nans for the recently implemented gll nodes as soon as we work with amr on supermucng.
We start with a series of tests:
| Basis | Mesh | AMR | Arch | Opt | MPI | Works |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| GLL | 25 | 1 | hsw| vect | No | yes |
| GLL | 7 | 2 | hsw| vect | No | yes |
| GL | 25 | 1 | skx| vect | Yes |yes |
| GLL | 25 | 1 | skx| vect | Yes |yes |
| GL | 25 | 2 | skx| vect | Yes | **nans** |
| GLL | 25 | 2 | skx| vect | Yes | **nans** |
| GL | 25 | 2 | skx| gen | Yes | **nans** |
| GLL | 25 | 2 | skx| gen | Yes | **nans** |
| GLL | 79 | 1 | skx| gen | Yes | yes |
| GLL | 79 | 1 | skx| gen | Yes | yes |
| GLL | 239 | 1 | skx| gen | Yes | yes |
As GL as well as GLL nodes seem to fail repeat the GL 2 AMR level test on the master branch:
| Basis | Mesh | AMR | Arch | Opt | MPI | ExaSeis | Works |
| ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
| GL | 25 | 2 | skx| gen | Yes | master | **nans** |
Which shows the same behaviour for default old cases.Leonhard RannabauerLeonhard Rannabauerhttps://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/289Luh padding and alternative layout2019-07-23T10:59:21+02:00Jean-Matthieu GallardLuh padding and alternative layoutCurrently the optimized kernels do not change luh. This was done for historical reasons (the non temp arrays had a set size independently of the kernels, now changed) and to ensure that the plotter, limiter and AMR would work no matter t...Currently the optimized kernels do not change luh. This was done for historical reasons (the non temp arrays had a set size independently of the kernels, now changed) and to ensure that the plotter, limiter and AMR would work no matter the kernels.
However being able to work with a padded luh or even further an SoS-layout luh (x,n,y,z coordinates instead of the current n,x,y,z) could provide a speedup. Currently the linear vectorized split_ck implementation does the back and forth transpositions to SoS layout and the cost of these is non negligible (even if more than compensated by the vectorization speedup).
The Limiter projections+tests and AMR can now be done using optimized kernels too so the compatibility issue here could easily be solved by generating the right kernels.
Regarding the plotters a preprocessing step to translate back luh locally could be added in case luh is non standard.
Is there a good way to do this?
Open questions: would this impact other domain of the code
@domcha @leo.rannabauer
Occurrences of luh:
-------------------
Search Term: ``getSolution()``
**exahype plotters**
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/Carpet/ADERDG2Carpet.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/Carpet/FiniteVolume2Carpet.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/CSV/ADERDG2LegendreCSV.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/CSV/Patch2CSV.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/FlashHDF5/ADERDG2FlashHDF5.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/PeanoFileFormat/ADERDG2CartesianPeanoPatchFileFormat.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/PeanoFileFormat/ADERDG2LegendrePeanoPatchFileFormat.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/PeanoFileFormat/FiniteVolumes2PeanoPatchFileFormat.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/Tecplot/ExaHyPE2Tecplot.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/ADERDG2CartesianVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/ADERDG2LegendreDivergenceVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/ADERDG2LegendreVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/ADERDG2LobattoVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/FiniteVolumes2VTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/LimitingADERDG2CartesianVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/LimitingADERDGSubcells2CartesianVTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/VTK/Patch2VTK.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/ADERDG2ProbeAscii.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/ADERDG2UserDefined.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/FiniteVolumes2ProbeAscii.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/FiniteVolumes2UserDefined.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/plotters/LimitingADERDG2UserDefined.cpp
**exhaype/solvers**
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/ADERDGSolver_FusedTimeStepJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/ADERDGSolver_PredictionJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/ADERDGSolver_UpdateJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/ADERDGSolver.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/FiniteVolumesSolver_UpdateJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/FiniteVolumesSolver.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/LimitingADERDGSolver_LocalRecomputationJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/LimitingADERDGSolver_UpdateJob.cpp
/ExaHyPE-Engine_upstream/ExaHyPE/exahype/solvers/LimitingADERDGSolver.cppJean-Matthieu GallardJean-Matthieu Gallardhttps://gitlab.lrz.de/exahype/ExaHyPE-Engine/-/issues/288Separate Variables from Parameters2019-07-23T10:40:15+02:00Jean-Matthieu GallardSeparate Variables from ParametersProblem: Currently parameters are stored right after the variables in luh, Q and its related arrays (lQi, lQhi, lQhbnd). This make it difficult to provide vectorized PDE options and make some operations where the parameter have to be ski...Problem: Currently parameters are stored right after the variables in luh, Q and its related arrays (lQi, lQhi, lQhbnd). This make it difficult to provide vectorized PDE options and make some operations where the parameter have to be skipped less intuitive and slower with SIMD
Solution: Introduce a new array like luh to store the parameters. This array is to be passed to the user functions using parameters (nullptr if no parameters) like luh or Q is. The linear space time predictor with split_ck already do this locally.
Issue: Will change the signatures of some user functions and formulation if they are indeed using parameters.
@ga96nuv