Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • ExaHyPE-Engine ExaHyPE-Engine
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 68
    • Issues 68
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

6.4.2023: Due to updates GitLab may be unavailable for some minutes between 9:00 and 11:00.

  • ExaHyPEExaHyPE
  • ExaHyPE-EngineExaHyPE-Engine
  • Issues
  • #174
Closed
Open
Issue created Aug 31, 2017 by Ghost User@ghostContributor

Generic kernels: Select fluxes,ncp similar as for optimised kernels?

This issue is open for discussion.

Issue

Working with new ExaHyPE users has revealed that they often are not familar with the object-oriented programming concept of inheritance. Especially, they do not know how to overriding virtual functions of the AbstractMySolver class. They are further not familiar with the keywords "virtual" and "override".

This issue makes it difficult for them to select the right PDE kernels (flux,ncp,...) for their application. Even worse: The code might even compile and run but it will not perform the expected calculations. Such an error is very hard to detect in practice. Especially for a new ExaHyPE user.

Toolkit-based solution (open for discussion)

JM has moved the selection of the PDE kernels to the toolkit by requiring the user to specify the kernels in the following way:

kernels const = optimised::fluxes::nonlinear // flux only

or

kernels const = optimised::fluxes::ncp::nonlinear // flux and ncp

or

kernels const = optimised::fluxes::ncp::source::nonlinear // flux and ncp, source

In my opinion, this is the better approach. The "const" modifier of "kernels" indicates that the user has to rerun the toolkit everytime he selects different PDE-kernels The toolkit will then update the AbstractSolver Header file.

The compiler will deal with any inconsistencies between the files:

  • The compiler will tell you if you have not implemented a kernel you have specified - not an assertion as it is the case right now. (Users often do not even know about the Asserts Mode.)

  • The compiler will tell you if you have implemented a method which is not called. You should then comment out the implementation or remove it.

What is your opinion?

Please comment below.

Assignee
Assign to
Time tracking

LRZ Homepage | Datenschutz | Dokumentation und Betriebsbedingungen | Impressum