@@ -5,7 +5,8 @@ The aim of this exercise is to get familiar with setting up coupled free flow/po
## Problem set-up
The model domain consists of two non-overlapping subdomains.
Free flow is modeled in the upper subdomain, while the lower subdomain models a flow in a porous medium. Both single-phase flow and two-phase flow will be considered in the porous domain.
Free flow is modeled in the upper subdomain, while the lower subdomain models a flow in a porous medium.
Both single-phase flow and two-phase flow will be considered in the porous domain.
### 0. Getting familiar with the code
...
...
@@ -14,7 +15,7 @@ Free flow is modeled in the upper subdomain, while the lower subdomain models a
There are three sub folders: `interface` (Exercise 1), `models` (Exercise 2) and `turbulence` (Exercise 3).
The problem-related files for this exercise are:
The task-related files for the simualtion exercises are as follows:
* Three __main files__ for the three sub-tasks :`interface/main.cc`, `models/main.cc`, `turbulence/main.cc`,
* Three __free flow problem files__: `interface/freeflowsubproblem.hh`, `models/freeflowsubproblem.hh`, `turbulence/freeflowsubproblem.hh`
* Three __porous medium flow problem files__: `interface/porousmediumsubproblem.hh`, `models/porousmediumsubproblem.hh`, `turbulence/porousmediumsubproblem.hh`
...
...
@@ -24,21 +25,21 @@ The problem-related files for this exercise are:
In the main file, `TypeTags` for both submodels are defined, `FreeflowTypeTag` and `PorousMediumTypeTag`. These `TypeTags` collect all of the properties associated with each subproblem.
The same applies for types such as `GridManager`, `FVGridGeometry`, `Problem`, etc...
Since we use a monolithic coupling scheme, there is only one `Assembler` and one `NewtonSolver`.
Since we use a monolithic coupling scheme, there is only one `Assembler` and one `NewtonSolver`, which help to assemble and solve the full coupled problem.
The problem files very much look like "regular", uncoupled ones with the exception that they hold a pointer to the `CouplingManager` which allows to evaluate the coupling conditions and to exchange information between the coupled models.
The problem files very much look like the "regular", uncoupled problem files seen in previous exercises, with the exception that they hold a pointer to the `CouplingManager`.
This allows them to evaluate the coupling conditions and to exchange information between the coupled models.
The coupling conditions are realized technically in terms of boundary condition. For instance,
in `interface/freeflowsubproblem.hh`, `couplingNeumann` boundary conditions are set, which means that the free flow models evaluates the
mass and momentum fluxes coming from the porous domain and uses these values as boundary conditions at the interface.
Note the certain checks are performed when combining different models, e.g., the fluid system has to be the same for both domains
Note that certain checks are performed when combining different models, e.g., the fluid system has to be the same for both domains
and the sub-control-volume faces at the interface have to match.
We will use a staggered grid for the free flow and a cell-centered finite volume method for the porous medium.
We will use a staggered grid to discretize the free-flow domain and a cell-centered finite volume method for the porous medium domain.
Keep in mind that the staggered grid implementation distinguishes between face variables (velocity components) and
cell center variables (all other variables), therefore in some cases either the `stokesCellCenterIdx`
or the `stokesFaceIdx` is used respectively, while for the porous medium all variables can be accessed with `darcyIdx`.
cell center variables (all other variables).
For this reason either the `CouplingManager::stokesCellCenterIdx` or the `CouplingManager::stokesFaceIdx` index sets need to be used, while for the porous medium all variables can be accessed with `CouplingManager::darcyIdx`.
__Task__:
Take a closer look at the listed files before moving to the next part of the exercise:
