Discussion 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 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)