Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
D
dorie
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 31
    • Issues 31
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 9
    • Merge Requests 9
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • dorie
  • dorie
  • Merge Requests
  • !197

Merged
Opened Apr 20, 2020 by Lukas Riedel@lriedelOwner8 of 9 tasks completed8/9 tasks

Resolve "Time step restriction by boundary conditions differs between processors"

  • Overview 25
  • Commits 15
  • Pipelines 14
  • Changes 15

What does this MR do?

Communicate the minimal time step between all processors before computing the next time step in Richards and Transport model.

Following the philosophy that classes should be as encapsulated as possible, I decided against BoundaryConditionManager or TimeStepController communicating the minimal values internally. Both are currently not capable of doing so because the GridView is never passed to them and I did not want to add that.

This fixes the issue for the specific case reported in #187 (closed).

Is there something that needs to be double checked?

  • Is it fine that BoundaryConditionManager and TimeStepController may return different times on different processors? See explanation above.
  • I tried adding a boundary condition change to the parallel reference tests. But the issue reported in #187 (closed) does not occur in this test, probably because the grid partition works out "just right". Should we still add the boundary condition change (currently, it's not committed) or leave the test as it is? Is there any other way to verify the new/correct behavior?

Can this MR be accepted?

  • Implemented fix: Richards and Transport models communicate minimal time step internally
  • Added/Updated tests:
    • parallel_reference
    • Suggestion of different time step on each processor should yied a consisten model time step.
  • Added/Updated documentation
  • Pipeline passing
  • Squash option set
  • Delete branch option set
  • Added entry to CHANGELOG.md

Assignee: If the Squash option is set, check/update the commit message right before merging!

Related issues

Closes #187 (closed)

Edited Apr 29, 2020 by Santiago Ospina De Los Ríos
Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Reference: dorie/dorie!197
Source branch: 187-time-step-restriction-by-boundary-conditions-differs-between-processors