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

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

  • ExaHyPEExaHyPE
  • ExaHyPE-EngineExaHyPE-Engine
  • Issues
  • #250
Closed
Open
Issue created Sep 11, 2018 by Dominic Etienne Charrier@domchaOwner

Issue with Limiting ADER-DG combined with Material Parameters

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

    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 image

    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.

Edited Sep 11, 2018 by Dominic Etienne Charrier
Assignee
Assign to
Time tracking

LRZ Homepage | Datenschutz | Dokumentation und Betriebsbedingungen | Impressum