Commit 97d4abff authored by Alexander Jaust's avatar Alexander Jaust
Browse files

[doc] Remove mkdocs documentation and update README

The documentation was out of date and not everything would have been interesting for user anyway. Therefore, we remove this documentation for the moment. This also adds some information about the documentation in the main `` of the repository.
parent 4bb09e8f
Pipeline #13331 passed with stages
in 14 minutes
......@@ -2,6 +2,7 @@
## Not released yet
- 2022-02-01: Add some extra information on the documentation in the ``. 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.
......@@ -47,6 +47,23 @@ This repository provides a [DuMuX]( adapter to coupl
## 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]( 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]( 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.,
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?
# 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**
# 1st iteration
velocities to be sent to ff
# 2nd iteration
velocities to be sent to ff
**PM solver**
# initial data
# 1st iteration
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?
- 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](
We do the following now:
| Solver | writes | reads |
| ------------ | ------ | ----- |
| SolidEnergy | Temperature | Heat flux |
| FreeFlow | Heat flux | Temperature |
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)`;
#### 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
- 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
- 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?
- 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:
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]);
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`[](
1. Using `OpenFOAM` adapter + `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", [](
## 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 |
| Solid density | rho_s | 1 |
| Fluid thermal conductivity | k_f | = k_s / k |
| Fluid density | rho_f | 1 |
| Dynamic viscosity | mu | = rho_f * U_infty * L / Re |
| Fluid specific heat capacity | c_pf | = k_f Pr / mu |
**Note**: There is a [master's thesis by Lucia Cheung Yau]( in which she ran the simulation for a wider range of values.
### Flow solver
| Parameter | value |
| --------- | ----- |
| dt | 0.01 |
| t_end | 10 |
### Solid solver
| Parameter | value |
| --------- | ----- |
| dt | 0.01 |
| t_end | 10 |
\ No newline at end of file
%\usetikzlibrary{...}% tikz package already loaded by 'tikz' option
% \newcommand*{\Length}{1}
% \newcommand{\channelHeight}{0.5*\Length}
\begin{tikzpicture}[scale=5.0]% Example:
\coordinate (fluid_n1) at (-0.5,0.0);
\coordinate (fluid_n2) at (3.0,0.0);
\coordinate (fluid_n3) at (3.0,0.5);
\coordinate (fluid_n4) at (-0.5,0.5);
\draw[fill=water] (fluid_n1) -- (fluid_n2) -- node[right, midway] {\textbf{Outflow}} (fluid_n3) -- (fluid_n4) -- node[color=blue,left, midway,text width=2cm] {\textbf{Inflow}\\$T=300K$\\Re=500\\Pr=0.01} (fluid_n1) ;
\node[] at (1.5,0.25) {\textbf{Fluid}} ;
\node[below] at (fluid_n1) {$(-0.5,0)$};
\node[below] at (fluid_n2) {$(3.0,0)$};
\node[above] at (fluid_n3) {$(3.0,0.5)$};
\node[above] at (fluid_n4) {$(-0.5,0.5)$};
\draw[color=blue,line width=2pt] (fluid_n1) -- (fluid_n4) node[right,midway, text width=2cm] {};
\coordinate (solid_n1) at (0.0,0.0);
\coordinate (solid_n2) at (0.0,-0.25);
\coordinate (solid_n3) at (1.0,-0.25);
\coordinate (solid_n4) at (1.0,0.0);
\draw[fill=porousmedia] (solid_n1) -- (solid_n2) -- (solid_n3) -- (solid_n4) -- cycle;
\node[above] at (solid_n1) {$(0.,0)$};
\node[below] at (solid_n2) {$(0.0,-0.25)$};
\node[below] at (solid_n3) {$(1.0,-0.25)$};
\node[above] at (solid_n4) {$(1.0,0.0)$};
\node[] at (0.5,-0.125) {\textbf{Solid}} ;
\draw[color=Interface,line width=2pt] (solid_n1) -- (solid_n4) node[midway, above] {\textbf{Interface}};
\draw[color=red,line width=2pt] (solid_n2) -- (solid_n3) node[midway, below, text width=2cm] {\textbf{Heated}\\$T=310K$};
% Slipwall
\draw[color=slipwall,line width=2pt, dashed] (fluid_n1) -- (solid_n1) node[below,midway, text width=2cm] {\textbf{Slip wall}};
\draw[color=slipwall,line width=2pt, dashed] (fluid_n3) -- (fluid_n4) node[above,midway, text width=2cm] {\textbf{Slip wall}};
% Noslip wall
\draw[color=noslipwall,line width=2pt] (solid_n4) -- (fluid_n2) node[below,midway, text width=3cm] {\textbf{No-Slip wall}};
\ No newline at end of file
# Welcome to the DuMuX-preCICE coupling project
## Quick facts
- GitLab: [](
- Logs/Minutes of last meetings can be found [here](logs/
- The DuMuX adapter moved into [another repository]( and was added as a submodule.
# Overview over the last meetings
**Next meeting**: 2019-??-??
## 2019-04-12
Side note: My class `PreciceWrapper` is in fact a singleton.
- We found out that certain questions have come up regarding the test case
- Maybe double check wall boundary conditions
- Inflow: Verify that it is a rectangular flow profile (slip walls)
- Does the fluid have to be incompressible?
- Are the flow parameters depending on the solution? This means, are flow parameters like the viscosity depending on the temperature?
- What are the flow quantities.
- Where are the values prescribed in OpenFOAM. Are these actual boundary values or are they cell centered?
- How is the coupling carried out? What values are used for the heat flux? What temperatures do we use and which conductivity?
Question for us:
**What quantities do we need?**
Known parameters
| Parameter | value |
| --------- | ----- |
| Reynolds | 500 |
| Prandtl | 0.1 |
| k | 1 |
**Note**: k=1 means that k_s = k_f = 1. The heat conductivity of fluid and solid are the same.
- Inflow velocity:
- Inflow temperature:
- Viscosity (given Reynolds number)
- Conductivity: Comes from the Prandtl number. We need to now c_p and density rho of the fluid
## 2019-04-03
Participants: Kilian, Ned, Alex
### Contents
- Discussion on the test case and how to set it up.
- Some discussion about tools (`MkDocs`, `pandoc`, `sphinx` etc.).
- Alex should come to one of the DuMuX meetings some time. Maybe present some of the tools.
### Outcome/Plans:
- Create GitLab repository
- Set up [conjugate heat transfer test case](../ in DuMuX. This will be done twice:
1. Monolithic setup with DuMuX
1. Two seperate DuMuX solvers that will be coupled with preCICE afterwards.
- Alex should push his notes about the `dumux-lecture` to the repository.
- Checkpointing of the solution for preCICE has to be done "by hand". There is no functionality for this currently in DuMuX.
- Integrate the preCICE-DuMuX-adapter in the DuMuX repository. This keeps it close to potential users and it will not be forgotten in the preCICE repository.
\ No newline at end of file
site_name: DuMuX-preCICE coupling project
- Home:
- DuMux-preCICE coupling:
- General information:
- Test cases:
- Meeting logs: logs/
theme: mkdocs
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment