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
  • Issues
  • #126

Closed
Open
Opened Nov 06, 2018 by Lukas Riedel@lriedelOwner

New input for boundary condition data

Description

We want to drop the dreadful muPhi-like boundary condition datafile and switch to an input through YAML data files (as mentioned in #29 (closed)). This is in line with the changes for the parameterization data input (see #86 (closed)).

The new boundary condition input should be match the boundary segmentation input by using the segmentation indices for identification.

Proposal

YAML boundary condition file

Have a new boundary condition data input file in YAML format. The proposal looks like this:

north: # arbitrary name
  index: 1 # association index
  conditions:
    rain_1:
      type: neumann
      value: -5.55e-6
      time: 2000 # single value: extrapolate until finish

    evaporation_1:
      type: dirichlet
      value: [-6, -0] # sequence: linear interpolation of values
      time: [1000, 2000] # sequence: time interval

south:
  index: 2
  conditions:
    water_table:
      type: dirichlet
      value: 0.0
      time: 0

# unspecified boundaries: no-flow
default:
  type: neumann
  value: 0.0

Loadup algorithm

The algorithm has to perform the following steps:

  • Create a map: Association index -> BC list
    • Open the YAML file
    • store the default BC
    • iterate over all other segments
    • read the index
    • iterate over conditions, following this algorithm:
  • fill in "blanks":

    • compare sets of BC association indices from YAML files and mappings
    • fill missing time intervals with default BC
    • create default BC for missing association indices
  • create map: Boundary index -> shared pointer to BC list

    • iterate over all grid boundary faces
    • read boundary index
    • use boundary index map to infer association index and hence BC list

Local operator interface

Adapt FlowBoundary:

FlowBoundary
{
private:
  using BCList = std::list<std::shared_ptr<BoundaryCondition>>;
  using BoundaryConditionStorage = std::vector<BCList>;

  // store a list of boundary conditions for every boundary segment (index)
  BoundaryConditionStorage _bc_storage;
  // store pointers to the currently applied boundary conditions (updated by set_time)
  BCList _bc_time_cache;

public:
  /// Update the time cache
  void set_time (const RF time);

  /// Retrieve the boundary condition
  std::shared_ptr<BoundaryCondition> bc (const Intersection& is);
  
}

How to test the implementation?

New unit test: Create exemplary BC data file and mapping and check internal results (also with variable time)

Related issues

Meta-issue #119 (closed)

Edited Dec 06, 2018 by Lukas Riedel
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
v2.0 Release
Milestone
v2.0 Release
Assign milestone
Time tracking
None
Due date
None
Reference: dorie/dorie#126