Skip to content
Snippets Groups Projects
Commit 031ccff3 authored by Maziar Veyskarami's avatar Maziar Veyskarami Committed by Ned Coltman
Browse files

[ex-fractures][propertiesheader] update README.md

parent caf9696d
No related branches found
No related tags found
1 merge request!98Fractures exercise with separate properties header
......@@ -20,6 +20,7 @@ Navigate to the directory `dumux/exercises/exercise-fractures` and familiarize y
* The __problem file__ for the fracture domain: `fractureproblem.hh`
* The __spatial parameters file__ for the matrix domain: `matrixspatialparams.hh`
* The __spatial parameters file__ for the matrix domain: `fracturespatialparams.hh`
* The __properties file__ for both domains: `properties.hh`
If you want to learn more about the program flow of coupled problems within the _DuMuX multidomain_ framework, take a closer look at the __main file__. Therein, you will find extensive comments above the key instructions that will help you to identify the main differences with respect to an uncoupled _DuMuX_ model. We will now briefly guide you through this, however, this is not necessary for this exercise. Feel free to continue with the section __Running the program__ and come back to this point later.
......@@ -54,7 +55,7 @@ matrixProblem->setCouplingManager(couplingManager);
fractureProblem->setCouplingManager(couplingManager);
```
From the matrix side, the coupling works a bit different. Since the fracture domain lives on the matrix domain's facets, the state inside the fracture (e.g. pressure, temperature etc.) will affect the fluxes computed across the respective element facets. However, flux assembly depends on the underlying finite-volume scheme and is not convenient to implement. We therefore created _TypeTag_ nodes for the matrix sub-problems in models considering facet coupling. By using these _TypeTags_, all necessary modifications for the flux computation on interior boundaries is done for you. For instance, in `matrixproblem.hh`, we define the _TypeTag_ for the matrix problem as follows (please read the provided comments):
From the matrix side, the coupling works a bit different. Since the fracture domain lives on the matrix domain's facets, the state inside the fracture (e.g. pressure, temperature etc.) will affect the fluxes computed across the respective element facets. However, flux assembly depends on the underlying finite-volume scheme and is not convenient to implement. We therefore created _TypeTag_ nodes for the matrix sub-problems in models considering facet coupling. By using these _TypeTags_, all necessary modifications for the flux computation on interior boundaries is done for you. For instance, in `properties.hh`, we define the _TypeTag_ for the matrix problem as follows (please read the provided comments):
```cpp
// We are using the framework for models that consider coupling
......@@ -64,13 +65,14 @@ From the matrix side, the coupling works a bit different. Since the fracture dom
// with tpfa.
#include <dumux/multidomain/facet/cellcentered/tpfa/properties.hh>
...
namespace Dumux::Properties {
// create the type tag node for the matrix sub-problem
// Create new type tags
// create the type tag node for the matrix and fracture sub-problems
namespace TTag {
struct MatrixProblem { using InheritsFrom = std::tuple<CCTpfaFacetCouplingModel, TwoP>; };
struct FractureProblem { using InheritsFrom = std::tuple<TwoP, CCTpfaModel>; };
} // end namespace TTag
```
Additionally, we need to provide access to the coupling manager in the matrix problem, so that the flux assembly engine of the matrix domain has access to the state inside the fracture (which the fluxes depend on):
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment