Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in
D
dorie
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 28
    • Issues 28
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 13
    • Merge Requests 13
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Commits
  • Issue Boards
  • dorie
  • dorie
  • Merge Requests
  • !65

Merged
Opened Jul 23, 2018 by Santiago Ospina De Los Ríos@sospinar3 of 3 tasks completed3/3 tasks
  • Report abuse
Report abuse

Simulation Traits

What does this MR do?

This MR proposes to modify the current Trait system for one that can manage more than one model as is wanted in #73 (closed). In many regards, this MR is very similar to the changes done and discussed in !30 (closed) with respect Traits.

Particularly, everything specialized trait still depends on the BaseTraits class. However, now each model has its own traits that define all the needed types for the simulation.

  • Since models can have differences regarding the orders of polynomials of the FEM, the argument order was removed from BaseTraits and delegated to the specific model Traits, in this case, that is done in RichardsSimulationTraits. (To be consistent, it was also added as an argument for the AdaptativeHandler and its factory).

  • It was removed the template template parameter from the Grid in BaseTraits, and the template dimension argument. Reason: every dune-grid exports the dimension. Therefore, there is no need for templates deduction.

  • Since this is done to support several models, this MR already renames the Simulation object to RichardsSimulation and its respective files from simulation.* to richards_simulation.*.

Is there something that needs to be double checked?

The pipeline is failing because of conservation of mass test. This MR shouldn't modify anything there that doesn't fail at compile time, then, I am beginning to think this is due to some problem with the CI itself.

Changes in traits should not change anything for the user and a passing pipeline (i.e. successful compilation) must suffice as a test.

Can this MR be accepted?

  • Implemented
  • Pipeline passing
  • Added entry to CHANGELOG.md

Related issues

#73 (closed)

Edited Jul 31, 2018 by Santiago Ospina De Los Ríos
  • Discussion 17
  • Commits 13
  • Changes 23
Assignee
Assign to
Solute Transport Feature
Milestone
Solute Transport Feature
Assign milestone
Time tracking
2
Labels
Doing Enhancement
Assign labels
  • View project labels
Reference: dorie/dorie!65