Commit be366d07 authored by Alexander Jaust's avatar Alexander Jaust
Browse files

Update master

parent 711fb28e
Pipeline #19389 passed with stages
in 3 minutes and 37 seconds
---
Language: Cpp
# BasedOnStyle: Chromium
AccessModifierOffset: -1
AccessModifierOffset: -4
AlignAfterOpenBracket: Align
AlignConsecutiveMacros: false
AlignConsecutiveAssignments: false
......
#image: dumux-precice:3.3git-iterative-pr-2.2.0
#image: dumux-precice:3.3-2.2.1
image: ub2004-style-check:clang-10
#image: ajaust/style-check:clang-10
image: ajaust/style-check:0.1
stages:
- check
......@@ -21,6 +21,21 @@ check-style-clang-10:
- style-patch.diff
expire_in: 2 days
check-style-black:
stage: check
script:
- sudo apt-get update && sudo apt-get install -y python3 python3-distutils python-is-python3 wget
- wget https://bootstrap.pypa.io/get-pip.py && python get-pip.py && rm get-pip.py && ln -sf ${HOME}/.local/bin/pip3 ${HOME}/.local/bin/pip && export PATH="${HOME}/.local/bin":"${PATH}" && pip install black
- black .
- git diff > python-style-patch.diff
- if [ -s python-style-patch.diff ]; then echo "Download the style patch as artifact and apply it or run black . and commit again."; false; fi
needs: []
artifacts:
when: on_failure
paths:
- python-style-patch.diff
expire_in: 2 days
.build_template: &build-tests
stage: build
script:
......@@ -37,17 +52,21 @@ check-style-clang-10:
- build-cmake/
build-tests:3.3-2.2.1:
image: ub2004-dumux-precice:3.3-2.2.1
image: ajaust/dumux-precice:3.3-2.2.1
<<: *build-tests
rules:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
build-tests:3.4-2.2.1:
image: ub2004-dumux-precice:3.4-2.2.1
image: ajaust/dumux-precice:3.4-2.2.1
<<: *build-tests
build-tests:3.4-2.3.0:
image: ajaust/dumux-precice:3.4-2.3.0
<<: *build-tests
build-tests:master-2.2.1:
image: dumux-precice:master-2.2.1
image: ajaust/dumux-precice:master-2.2.1
rules:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
<<: *build-tests
......@@ -65,7 +84,7 @@ build-tests:master-2.2.1:
- build-cmake/
test-partitioned:3.3-2.2.1:
image: ub2004-dumux-precice:3.3-2.2.1
image: ajaust/dumux-precice:3.3-2.2.1
<<: *test-partitioned-cases
rules:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
......@@ -73,13 +92,19 @@ test-partitioned:3.3-2.2.1:
- build-tests:3.3-2.2.1
test-partitioned:3.4-2.2.1:
image: ub2004-dumux-precice:3.4-2.2.1
image: ajaust/dumux-precice:3.4-2.2.1
<<: *test-partitioned-cases
needs:
- build-tests:3.4-2.2.1
test-partitioned:3.4-2.3.0:
image: ajaust/dumux-precice:3.4-2.3.0
<<: *test-partitioned-cases
needs:
- build-tests:3.4-2.3.0
test-partitioned:master-2.2.1:
image: ub2004-dumux-precice:master-2.2.1
image: ajaust/dumux-precice:master-2.2.1
<<: *test-partitioned-cases
rules:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
......@@ -91,6 +116,7 @@ test-partitioned:master-2.2.1:
stage: test
script:
- cd build-cmake
- echo $PYTHONPATH
- CTEST_OUTPUT_ON_FAILURE=1 ctest -j2 -L ^monolithic$
artifacts:
expire_in: 2 days
......@@ -99,7 +125,7 @@ test-partitioned:master-2.2.1:
- build-cmake/
test-monolithic:3.3-2.2.1:
image: ub2004-dumux-precice:3.3-2.2.1
image: ajaust/dumux-precice:3.3-2.2.1
<<: *test-monolithic-cases
needs:
- build-tests:3.3-2.2.1
......@@ -107,13 +133,19 @@ test-monolithic:3.3-2.2.1:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
test-monolithic:3.4-2.2.1:
image: ub2004-dumux-precice:3.4-2.2.1
image: ajaust/dumux-precice:3.4-2.2.1
<<: *test-monolithic-cases
needs:
- build-tests:3.4-2.2.1
test-monolithic:3.4-2.3.0:
image: ajaust/dumux-precice:3.4-2.3.0
<<: *test-monolithic-cases
needs:
- build-tests:3.4-2.3.0
test-monolithic:master-2.2.1:
image: ub2004-dumux-precice:master-2.2.1
image: ajaust/dumux-precice:master-2.2.1
<<: *test-monolithic-cases
rules:
- if: '$CI_NIGHTLY_BUILD == "TRUE"'
......
## Description
<!--
Please describe the problem/feature request. Please also describe what you want
to achieve.
--->
### Environment
<!--
Please provide information about the operating system and relevant versions of
the software.
Example:
Ubuntu 20.04 LTS, preCICE 2.3.0, DuMuX 3.4, DuMuX-preCICE 0.1
--->
## Steps to reproduce
<!-- Please describe the steps one has to execture to reproduce the problem. --->
### Expected behavior
<!-- What outcome did you expect? --->
### Actual behavior
<!-- What was the actual outcome? --->
## Description
<!--
Please describe shortly what this merge request is doing and why
it is needed. If there is an related issue, please mention it here.
-->
## Checklist
<!--
Please make sure to go over all points on the checklist and
mark them as checked.
-->
- [ ] I made sure that the source files are formatted properly.
- [ ] I added my changes to the changelog (`CHANGELOG.md`)
- [ ] I updated the documentation.
<!--
If the pull request adds new content, please check the points
below. Otherwise remove the following lines.
-->
- [ ] I added a test for the new feature.
......@@ -2,6 +2,15 @@
## Not released yet
- 2022-02-18: Updated CI to use images from account `ajaust` from Dockerhub. Changed tolerance for partitioned tests to 5e-5 due to minimal changes in the solution with the new images on a new VM.
- 2022-02-09: Made sure all private member of the adapter are suffixed with an underscore.
- 2022-02-01: Add some extra information on the documentation in the `README.md`. Removed old/out-of-date mkdocs documentation from `doc/mkdocs`.
- 2022-01-31: Increased robustness of test scripts.
- 2022-01-31: We now use `diff -w` to compare preCICE's output files for regression tests. In preCICE 2.3.0 the white spaces used have changed which broke our regressions tests.
- 2022-01-26: Renamed `dumupreciceindexwrapper.[hh|cc]` to `dumupreciceindexmapper.[hh|cc]` to be consistent with the class name.
- 2022-01-26: Add and configure Doxygen code documentation of coupling adapter.
- 2022-01-25: Fix code formatting configuration to be close to the original DuMuX code formatting configuration.
- 2022-01-25: Added [description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) for merge requests and issues.
- 2022-01-12: The repository has been restructured. The main changes are:
- The adapter is now called `CouplingAdapter` and resides in `dumux-precice/`. The build process has been adapted accordingly.
......@@ -19,4 +28,4 @@
This marks the initial release of the DuMuX-preCICE adapter.
- Should represent the state of adapter used in publication [Jaust2020a](https://git.iws.uni-stuttgart.de/dumux-pub/jaust2020a).
- Requires preCICE 1.6
\ No newline at end of file
- Requires preCICE 1.6
......@@ -47,6 +47,23 @@ This repository provides a [DuMuX](https://dumux.org/)-specific adapter to coupl
ctest
```
## Documentation
### User documentation
At the moment the documentation is provided by the API documentation (see below) as well as the test and example cases. If something is unclear or you would want something to be documented better, please open an [issue](https://git.iws.uni-stuttgart.de/dumux-appl/dumux-precice/-/issues) and let us know.
### API documentation
The interface of the coupling adapter and also the internal (private) interface are documented using Doxygen. In order to build this documentation you need [Doxygen](https://www.doxygen.nl/index.html) installed. After configuring the project using CMake/`dunecontrol` you can build the documentation via navigating to the `build-cmake` directory and building the `doxygen_dumux-precice` target, i.e.,
```text
cd build-cmake
make doxygen_dumux-precice
```
This generates a HTML documentation which you can view in a browser of your choice. It is stored in `build-cmake/doc/doxygen/index.html`.
## Publications
### How to cite this code?
......
# This file contains local changes to the doxygen configuration
# please use '+=' to add files/directories to the lists
PROJECT_NAME = "DuMuX-preCICE"
PROJECT_BRIEF = "Adapter to couple DuMuX to other solver via preCICE"
PROJECT_NUMBER = @DUNE_MOD_VERSION@
# The INPUT tag can be used to specify the files and/or directories that contain
# documented source files. You may enter file names like "myfile.cpp" or
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
INPUT += @top_srcdir@/dune/
INPUT += @top_srcdir@/dumux-precice/ \
@top_srcdir@/doc/doxygen \
# see e.g. dune-grid for the examples of mainpage and modules
# INPUT += @srcdir@/mainpage \
# @srcdir@/modules
......@@ -15,7 +20,7 @@ INPUT += @top_srcdir@/dune/
# excluded from the INPUT source files. This way you can easily exclude a
# subdirectory from a directory tree whose root is specified with the INPUT tag.
# EXCLUDE += @top_srcdir@/dune/dumux-precice/test
EXCLUDE += @top_srcdir@/dumux-precice/dumux-addon/
# The EXAMPLE_PATH tag can be used to specify one or more files or
# directories that contain example code fragments that are included (see
......@@ -28,3 +33,6 @@ INPUT += @top_srcdir@/dune/
# the \image command).
# IMAGE_PATH += @top_srcdir@/dune/dumux-precice/pics
FILE_PATTERNS += *.hh *.dox
/*! \mainpage DuMuX-preCICE adapter
*
* This project helps with coupling DuMuX-based solvers
* with other solvers via the coupling library preCICE.
*
*/
\ No newline at end of file
# DuMuX-preCICE coupling
## Milestones
### Free flow and poious media flow coupling
We plan to do the following
| Solver | writes | reads |
| ------ | ------ | ----- |
| Darcy | Pressure | Velocity |
| FreeFlow | Velocity | Pressure |
The data is then incorporated into the BJS boundary conditions. Hopefully in a smart way.
- Let's try a `shared_ptr` concept instead of the singleton approach!
- Does not prevent user to create more than one instance what is somewhat bad!
- **Does not really work.** So forget about that now. Cannot pass it properly to our hacky helper functions.
- We need to set the initial pressure in the Darcy problem back to 0.
#### Questions
Flow is reversed after 1.5 iterations!
**Initial velocity**
![Initial velocity](./figs/initial_data_pm-ff-coupling.png)
**Velocity after 1 ff step and 1 pm step (=1 coupling step)**
![Velocity after 1 coupling step](./figs/1step_pm-ff-coupling.png)
**Velocity after 2 ff steps and 1 pm step (=1.5 coupling step)**
![Velocity after 2 ff steps and 1 pm step](./figs/1andhalf_step_pm-ff-coupling.png)
**FF solver**
```c++
# 1st iteration
velocities to be sent to ff
v[0]=-6.61414e-08
v[1]=-6.19115e-08
v[2]=-5.6572e-08
v[3]=-5.04326e-08
v[4]=-4.36579e-08
v[5]=-3.63742e-08
v[6]=-2.86902e-08
v[7]=-2.07036e-08
v[8]=-1.25056e-08
v[9]=-4.18234e-09
v[10]=4.18234e-09
v[11]=1.25056e-08
v[12]=2.07036e-08
v[13]=2.86902e-08
v[14]=3.63742e-08
v[15]=4.36579e-08
v[16]=5.04326e-08
v[17]=5.6572e-08
v[18]=6.19115e-08
v[19]=6.61414e-08
# 2nd iteration
velocities to be sent to ff
v[0]=-2.41576e-05
v[1]=-2.28153e-05
v[2]=-2.1064e-05
v[3]=-1.897e-05
v[4]=-1.65748e-05
v[5]=-1.39209e-05
v[6]=-1.10525e-05
v[7]=-8.01602e-06
v[8]=-4.8588e-06
v[9]=-1.62892e-06
v[10]=1.62521e-06
v[11]=4.85508e-06
v[12]=8.01227e-06
v[13]=1.10487e-05
v[14]=1.3917e-05
v[15]=1.65709e-05
v[16]=1.8966e-05
v[17]=2.106e-05
v[18]=2.28111e-05
v[19]=2.41533e-05
```
**PM solver**
```c++
# initial data
p[0]=5e-10
p[1]=5e-10
p[2]=5e-10
p[3]=5e-10
p[4]=5e-10
p[5]=5e-10
p[6]=5e-10
p[7]=5e-10
p[8]=5e-10
p[9]=5e-10
p[10]=5e-10
p[11]=5e-10
p[12]=5e-10
p[13]=5e-10
p[14]=5e-10
p[15]=5e-10
p[16]=5e-10
p[17]=5e-10
p[18]=5e-10
p[19]=5e-10
# 1st iteration
p[0]=-1.6348e-06
p[1]=-1.52962e-06
p[2]=-1.39717e-06
p[3]=-1.24513e-06
p[4]=-1.07754e-06
p[5]=-8.97521e-07
p[6]=-7.07721e-07
p[7]=-5.10538e-07
p[8]=-3.08192e-07
p[9]=-1.02794e-07
p[10]=1.03616e-07
p[11]=3.09015e-07
p[12]=5.1136e-07
p[13]=7.08544e-07
p[14]=8.98344e-07
p[15]=1.07837e-06
p[16]=1.24595e-06
p[17]=1.39799e-06
p[18]=1.53044e-06
p[19]=1.63562e-06
```
In FreeFlow `ffproblem.hh`
- Should alphaBJ and permeability be transfered? I thought they would be constant?
In Darcy
- Do we receive mass flux or velocity?
- How to reconstruct certain things?!
- What happens when `values.setBJS` is called? Is it callable with preCICE running?
**NEW**
- I even get negative pressures. Should that be expected? I would guess pressures would be in between 0 and 1e-9 as prescribed on the domain boundaries. Although I understand that is not total pressure so negative values are not forbidden.
- What are the pressures in the Darcy domain normally? Is there a jump between free flow and Darcy flow?
- Change direction of data transfer to change the Dirichlet/Neumann coupling? The idea is to give the Darcy-solver more freedom when solving its problem.
| Solver | writes | reads |
| ------ | ------ | ----- |
| FreeFlow | Pressure | Velocity |
| Darcy | Velocity | Pressure |
- Monolithic solver is broken?!
### Conjugate heat transfer problem
See [test case description](dumux_test_case.md#conjugate-heat-transfer)
We do the following now:
| Solver | writes | reads |
| ------------ | ------ | ----- |
| SolidEnergy | Temperature | Heat flux |
| FreeFlow | Heat flux | Temperature |
**Attention**
This is the opposite way of writing things than in the OpenFOAM example! If we want to couple to OpenFOAM we have to change that.
#### Code related questions
What is the best way to reload a checkpoint?
Saving `sol` and then
1. reloading `sol` via `GridVariables->update(sol)` followed by a `GridVariables->advanceTimeStep()`.
1. reloading `sol` via `GridVariables->init(sol)`;
Codes:
```c++
GridVariables->update(sol);
GridVariables->advanceTimeStep();
```
```c++
GridVariables->init(sol)
```
#### Problems
- [x] We have to be careful with the initialization of the solvers.
- **Valid case** Heat solver starts: The heat solver computes a temperature to be send, the heat flux is zero. Thus, the temperature equals the temperature in the cell center.
- **Invalid case** Flow solver starts: The flow solver computes a heat flux from its temperatures. However, the temperature on the interface (stored in the precice adapter) is zero! Thus, a **very high** heat flux is initialized.
- **Note**: There were some errors in the preCICE configuration file.
- [x] The implicit coupling creates a solution that develops too fast.
- **Needs more testing** The checkpointing die only reload parts of the solution. In the end the Newton solver continued from its previous state, but with the initial guess being reset.
- [x] How do we control the adaptive time stepping? It increases above the suggested time step size which makes it impossible for preCICE to catch the solvers.
- I have adapted the adaptive solver. I hope it works properly now!
- Seems to be fine
#### Work
**Done**:
- Test case with heat transfer is up and running
- Follows the idea of the preCICE-tutorial test case, but is not exactly the same
- Compressible flow
- Slightly different boundary conditions
- Neumann-Neumann boundary condition
- Computation of heat flux is a bit different (harmonic mean) `lambda_harmonic = 2 / ( 1 / lambda_solid + 1 / lambda_fluid )`
- Working with dimensions
- Set up monolithic solver
- Set up two separate solvers
- Set up project with preCICE
**On the way**
- Implementing an adapter/wrapper
**Todo**:
- Write a preCICE-DuMuX-adapter
- Couple two separate solvers with preCICE **partially**
- Read/write temperature and heat flux
- Move `PreciceWrapper` into a different directory.
- Check solution of monolithic and partitioned approach
#### Requirements
What functions do we need?
Heat fluxes:
- `readSolidHeatFlux`
- `writeSolidHeatFlux`
- `writeFluidHeatFlux`
- `readFluidHeatFlux`
Are they read/written pointwise? Can we read/write them as vectors/arrays?
Geometry:
- How do we communicate the geometry to preCICE?
- **Preferred way**: Hand over a DuMuX data structure to preCICE. This would be easier for DuMuX users. Similar to fracturebenchmark setting?
- **Bad way**: Collect points in an array in DuMuX and hand it over to the adapter.
Generation of interface data in fracture case:
```c++
using FractureFVGridGeometry = typename FVGridGeometry::Type<1>;
const auto numFracturePoints = fvGridGeometry[onePFractureId].numDofs();
static constexpr int dimWorld = FractureFVGridGeometry::GridView::dimensionworld;
std::vector<double> pointCloud(numFracturePoints*dimWorld);
for (const auto& element : elements(fvGridGeometry[onePFractureId].gridView()))
{
auto fvGeometry = localView(fvGridGeometry[onePFractureId]);
fvGeometry.bind(element);
for (const auto& scv : scvs(fvGeometry))
for (unsigned int i = 0; i < dimWorld; ++i)
pointCloud[scv.dofIndex()*dimWorld + i] = scv.dofPosition()[i];
}
```
# Conjugate heat transfer
Last updated: 2019-04-16
**NOTE**: The description below refers to the preCICE-OpenFOAM test case. Our current setting is motivated by that test case, but has some differences.
**TODO**: Write down information about our current test case.
## Short description
The test case descibes fluid flow in a square channel connected to a solid, square block. The square block is heate from below and connected from to the channel. The block is cooled by the fluid at the top. This means that the fluid is heated up accordingly and the temperature changes.
Further description can be on the `preCICE` homepage:
1. Using `OpenFOAM`+`OpenFOAM`[https://github.com/precice/openfoam-adapter/wiki/Tutorial-for-CHT:-Flow-over-a-heated-plate](https://github.com/precice/openfoam-adapter/wiki/Tutorial-for-CHT:-Flow-over-a-heated-plate)
1. Using `OpenFOAM` adapter + `FEniCS` [https://github.com/precice/precice/wiki/Tutorial-for-CHT:-Flow-over-a-heated-plate-with-OpenFOAM-and-FEniCS](https://github.com/precice/precice/wiki/Tutorial-for-CHT:-Flow-over-a-heated-plate-with-OpenFOAM-and-FEniCS)
The test case is based on
[1]: M.Vynnycky, S.Kimura, K.Kanev, I.Pop: "Forced convection heat transfer from a flat plate: the conjugate problem", [https://www.sciencedirect.com/science/article/pii/S0017931097001130](https://www.sciencedirect.com/science/article/pii/S0017931097001130)
## Geometry
Image of geometry:
![Image of geometry](./figs/heat_transfer_channel.png)
### Generic geometry description
The solid block has length L and its height b varies depending on the sources I see.
In the tutorial (only `OpenFOAM` sovlers) the following values are used
- L = 1
- b = L/4 = 0.25 (height of block)
- l = 3.5 * L = 3.5 (length of channel)
- h = L / 2 = 0.5 (height of channel)
The coordinates as used in the tutorials are given in the attached image `heat_transfer_channel.png` (Look into the tex file `heat_transfer_channel.tex`).
**Note** (Alex): The description of the geometry is a bit misleading sometimes. The current coordinates are taken from the OpenFOAM setup that is distributed with the OpenFOAM adapter.
### Boundary conditions
**Note** (Alex): I just checked the OpenFOAM test case and it seems that we have slip wall boundaries almost everywhere.
- Slip wall: Bottom left of channel (in front of interface) and top of channel
- No-slip wall: Bottom of channel after interface
- Inflow: Left of channel
- Outflow: right of channel
- Heats: Bottom of solid
- No-slip + temperature: Interface. They use a mix of Neumann (heat flux) and Dirichlet (temperature) boundary conditions in the solvers, if I understand them correctly.
## Test case description
Reynolds number is Re=500 and Prandtl number is Pr=0.01. The ratio between solid and fluid conductivity is k = k_s/k_f = 1.
| Parameter | value |
| --------- | ----- |
| Re | 500 |
| Pr | 0.01 |
| k | 1 |
Dimensional parametes from Lucia's thesis:
| Parameter | Symbol | Value |
| --------- | ------ | ----- |
| Inlet velocity | U_infty | 0.1 |
| Plate length | L | 1|
| Solid thermal conductivity | k_s | 100 |
| Solid specific heat capacity | c_ps | 100 |