dorie issueshttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues2018-08-29T18:18:48+02:00https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/88Switch to release branch of dune-testtools2018-08-29T18:18:48+02:00Lukas Riedelmail@lukasriedel.comSwitch to release branch of dune-testtools### Description
The [`dune-testtools`](https://gitlab.dune-project.org/quality/dune-testtools) module now has a release branch matching DUNE v2.6. We should switch to that instead of relying on the unstable `master` branch.
### Proposal
Switch to `dune-testtools` branch `releases/2.6`:
* Update Dockerfile
* Rebuild Docker images
* Update `README.md`
### How to test the implementation?
Pipeline passes with new base image.
### Related issues
None.### Description
The [`dune-testtools`](https://gitlab.dune-project.org/quality/dune-testtools) module now has a release branch matching DUNE v2.6. We should switch to that instead of relying on the unstable `master` branch.
### Proposal
Switch to `dune-testtools` branch `releases/2.6`:
* Update Dockerfile
* Rebuild Docker images
* Update `README.md`
### How to test the implementation?
Pipeline passes with new base image.
### Related issues
None.Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/87Artifacts folder for tests in CI is wrong2018-09-03T14:22:48+02:00Santiago Ospina De Los Ríossospinar@gmail.comArtifacts folder for tests in CI is wrongArtifacts folder for tests in CI is wrong
#### Summary
The path for tests in [CI file](.gitlab-ci.yml) is wrong
#### Steps to reproduce
Jobs in pipelines are exporting artifacts with void folders
#### What is the expected _correct_ behaviour?
Export a folder containing the files generated by the test system
<!-- Put very long log outputs within the <pre></pre> tags below -->
<!-- If this doesn't apply, delete the whole <details></details> block -->
<details>
<summary>Expand to see logs</summary>
<pre>
</pre>
</details>
#### Ideas how to fix this?
Changing
```yaml
# --- Tests ---
test:exec_cmds: &test
stage: test
dependencies:
- build:main
script:
- $DUNECONTROL --only=dorie configure
- $DUNECONTROL --only=dorie make test_dorie_exec
artifacts:
name: "$CI_JOB_NAME"
paths:
- $CI_PROJECT_DIR/build-cmake/Testing
expire_in: 1 day
```
for
```yaml
# --- Tests ---
test:exec_cmds: &test
stage: test
dependencies:
- build:main
script:
- $DUNECONTROL --only=dorie configure
- $DUNECONTROL --only=dorie make test_dorie_exec
artifacts:
name: "$CI_JOB_NAME"
paths:
- $CI_PROJECT_DIR/build-cmake/testing
expire_in: 1 day
```Artifacts folder for tests in CI is wrong
#### Summary
The path for tests in [CI file](.gitlab-ci.yml) is wrong
#### Steps to reproduce
Jobs in pipelines are exporting artifacts with void folders
#### What is the expected _correct_ behaviour?
Export a folder containing the files generated by the test system
<!-- Put very long log outputs within the <pre></pre> tags below -->
<!-- If this doesn't apply, delete the whole <details></details> block -->
<details>
<summary>Expand to see logs</summary>
<pre>
</pre>
</details>
#### Ideas how to fix this?
Changing
```yaml
# --- Tests ---
test:exec_cmds: &test
stage: test
dependencies:
- build:main
script:
- $DUNECONTROL --only=dorie configure
- $DUNECONTROL --only=dorie make test_dorie_exec
artifacts:
name: "$CI_JOB_NAME"
paths:
- $CI_PROJECT_DIR/build-cmake/Testing
expire_in: 1 day
```
for
```yaml
# --- Tests ---
test:exec_cmds: &test
stage: test
dependencies:
- build:main
script:
- $DUNECONTROL --only=dorie configure
- $DUNECONTROL --only=dorie make test_dorie_exec
artifacts:
name: "$CI_JOB_NAME"
paths:
- $CI_PROJECT_DIR/build-cmake/testing
expire_in: 1 day
```Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/85CI schedule for released versions2018-08-20T23:55:24+02:00Santiago Ospina De Los Ríossospinar@gmail.comCI schedule for released versions### Proposal
Schedule CI Pipelines regularly (e.g. monthly) for released versions ([v1.0.0](https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/tags/v1.0.0) and [v1.1.0](https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/tags/v1.1.0)).
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->### Proposal
Schedule CI Pipelines regularly (e.g. monthly) for released versions ([v1.0.0](https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/tags/v1.0.0) and [v1.1.0](https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/tags/v1.1.0)).
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/84Improve triggering of DUNE environment image setup in CI pipeline2018-09-03T20:24:23+02:00Lukas Riedelmail@lukasriedel.comImprove triggering of DUNE environment image setup in CI pipeline### Description
The CI pipeline currently rebuilds the DUNE environment image(s) whenever a pipeline is manually started through the web interface ("Run pipeline"). The interface allows for adding custom CI variables. This should be used to actually trigger a new setup of the images.
The `only` keyword in the [`.gitlab-ci.yml` syntax](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) allows for evaluating variable expressions. In particular, one can check for a variable being [defined and non-empty](https://docs.gitlab.com/ee/ci/variables/README.html#supported-syntax)
### Proposal
* Run the `setup` jobs only when the variable `REBUILD_BASE_IMAGE` is defined and non-empty:
```yaml
only:
variables:
- $REBUILD_BASE_IMAGE
```
* Add a `README.md` to the `docker` directory, explaining the Docker image usage and pipeline.
### How to test the implementation?
* Pipeline passes
### Related issues
* #83 will update the pipeline as well. It might be easier merging both into one MR.### Description
The CI pipeline currently rebuilds the DUNE environment image(s) whenever a pipeline is manually started through the web interface ("Run pipeline"). The interface allows for adding custom CI variables. This should be used to actually trigger a new setup of the images.
The `only` keyword in the [`.gitlab-ci.yml` syntax](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) allows for evaluating variable expressions. In particular, one can check for a variable being [defined and non-empty](https://docs.gitlab.com/ee/ci/variables/README.html#supported-syntax)
### Proposal
* Run the `setup` jobs only when the variable `REBUILD_BASE_IMAGE` is defined and non-empty:
```yaml
only:
variables:
- $REBUILD_BASE_IMAGE
```
* Add a `README.md` to the `docker` directory, explaining the Docker image usage and pipeline.
### How to test the implementation?
* Pipeline passes
### Related issues
* #83 will update the pipeline as well. It might be easier merging both into one MR.Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/83Remove unnecessary files from deployed Docker image2018-10-07T02:27:40+02:00Lukas Riedelmail@lukasriedel.comRemove unnecessary files from deployed Docker image### Description
The `deploy` jobs have no dedicated `dependencies`, which leads to artifacts from the previous stage being downloaded by these jobs. This increases the image's size and clutters it.
### Proposal
Declare 'empty' dependencies according to the [GitLab docs](https://docs.gitlab.com/ee/ci/yaml/#dependencies):
> Defining an empty array will skip downloading any artifacts for that job.
```yaml
dependencies: []
```
### How to test the implementation?
* Pipeline passes
* No artifacts are downloaded for `deploy` jobs
### Related issues
* #44 seeks for reducing the image size### Description
The `deploy` jobs have no dedicated `dependencies`, which leads to artifacts from the previous stage being downloaded by these jobs. This increases the image's size and clutters it.
### Proposal
Declare 'empty' dependencies according to the [GitLab docs](https://docs.gitlab.com/ee/ci/yaml/#dependencies):
> Defining an empty array will skip downloading any artifacts for that job.
```yaml
dependencies: []
```
### How to test the implementation?
* Pipeline passes
* No artifacts are downloaded for `deploy` jobs
### Related issues
* #44 seeks for reducing the image sizeLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/79Add more Issue and MR templates2019-09-24T16:51:20+02:00Lukas Riedelmail@lukasriedel.comAdd more Issue and MR templates### Description
The [GitLab description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) are very useful, but we need more of them.
### Proposal
Add MR templates for
* Creating an MR _without_ issue
* Bugfix release MR, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/merge_requests/90
Add Issue templates for
* Release rollout:
- bugfix release, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/96
- minor release, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/78
- major release
### People involved
@sospinar, do you have another idea for an additional template? Does an existing template need an update?### Description
The [GitLab description templates](https://docs.gitlab.com/ee/user/project/description_templates.html) are very useful, but we need more of them.
### Proposal
Add MR templates for
* Creating an MR _without_ issue
* Bugfix release MR, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/merge_requests/90
Add Issue templates for
* Release rollout:
- bugfix release, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/96
- minor release, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/78
- major release
### People involved
@sospinar, do you have another idea for an additional template? Does an existing template need an update?https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/77Define the public API2018-09-03T20:24:23+02:00Lukas Riedelmail@lukasriedel.comDefine the public API### Description
DORiE is intended to comply to [Semantic Versioning](https://semver.org/). Updates are indicated by patches, minor revisions, and major revisions. The two latter relate to backwards compatible changes of the public API. Therefore, an API must be defined. This has not occurred as of v1.0.0.
The public API should encompass:
* The `dorie` CLI (how the compiled program is executed)
* The input files for the program:
- Config files
- Parameter field H5 file
- boundary condition input file
* The API of the main program instance: `Simulation`.
The config files are defined by the Cheat Sheet. The API of `Simulation` could be looked up in the doxygen documentation (which currently does not exist!). The boundary condition input file is defined in the docs.
### Proposal
* Add a new docs page concerning the public API
* Update the docs on the `dorie` CLI
* Add a specification of the parameter field file
* Deprecations and removals will be mentioned in the `CHANGELOG.md`
### How to test the implementation?
No testing necessary
### Related issues### Description
DORiE is intended to comply to [Semantic Versioning](https://semver.org/). Updates are indicated by patches, minor revisions, and major revisions. The two latter relate to backwards compatible changes of the public API. Therefore, an API must be defined. This has not occurred as of v1.0.0.
The public API should encompass:
* The `dorie` CLI (how the compiled program is executed)
* The input files for the program:
- Config files
- Parameter field H5 file
- boundary condition input file
* The API of the main program instance: `Simulation`.
The config files are defined by the Cheat Sheet. The API of `Simulation` could be looked up in the doxygen documentation (which currently does not exist!). The boundary condition input file is defined in the docs.
### Proposal
* Add a new docs page concerning the public API
* Update the docs on the `dorie` CLI
* Add a specification of the parameter field file
* Deprecations and removals will be mentioned in the `CHANGELOG.md`
### How to test the implementation?
No testing necessary
### Related issuesLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/76Make compilation procedure more efficient2019-11-28T15:46:10+01:00Lukas Riedelmail@lukasriedel.comMake compilation procedure more efficient### Description
The current compilation procedure is focused on not exceeding 2 GB of RAM for sequential `make` runs. As indicated in !63, compiling single instantiations of the `Simulation` template can be inefficient, both in terms of memory and CPU usage.
The new restrictive limit is the default GitLab runner, which is limited to 3 GB.
### Proposal
Use less object files:
1. Move multiple `YASPGrid` instantiations into one object file
2. _(optional)_ Move more `UGGrid` instantiations into single object files
### How to test the implementation?
Pipeline passes (faster than now)
### Related issues
See !63.### Description
The current compilation procedure is focused on not exceeding 2 GB of RAM for sequential `make` runs. As indicated in !63, compiling single instantiations of the `Simulation` template can be inefficient, both in terms of memory and CPU usage.
The new restrictive limit is the default GitLab runner, which is limited to 3 GB.
### Proposal
Use less object files:
1. Move multiple `YASPGrid` instantiations into one object file
2. _(optional)_ Move more `UGGrid` instantiations into single object files
### How to test the implementation?
Pipeline passes (faster than now)
### Related issues
See !63.https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/75Documentation page down2018-09-03T14:22:48+02:00Santiago Ospina De Los Ríossospinar@gmail.comDocumentation page downDocumentation page listed in README.md (http://dorie-docs.gitballoon.com) is down.Documentation page listed in README.md (http://dorie-docs.gitballoon.com) is down.Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/74Switch to OVLP_AMG_4_DG for all computations2018-09-03T20:24:22+02:00Lukas Riedelmail@lukasriedel.comSwitch to OVLP_AMG_4_DG for all computations### Description
With the switch to DUNE v2.6, proper static blocking was introduced (see #68 !53) which changed the performance of the `OVLP_AMG_4_DG` linear solver significantly. @oklein reports that it achieves similar speeds as `SuperLU` even for small problems and is significantly faster for larger problems.
### Proposal
Remove the runtime switch for the linear solver and only use `OVLP_AMG_4_DG` for any computation.
### How to test the implementation?
Pipeline passes.
### Related issues
See #68### Description
With the switch to DUNE v2.6, proper static blocking was introduced (see #68 !53) which changed the performance of the `OVLP_AMG_4_DG` linear solver significantly. @oklein reports that it achieves similar speeds as `SuperLU` even for small problems and is significantly faster for larger problems.
### Proposal
Remove the runtime switch for the linear solver and only use `OVLP_AMG_4_DG` for any computation.
### How to test the implementation?
Pipeline passes.
### Related issues
See #68Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/73Transport Local Operator for finite volume scheme2018-10-22T22:33:51+02:00Santiago Ospina De Los Ríossospinar@gmail.comTransport Local Operator for finite volume scheme## Description
The local operator must model the formulation of the transport equation in finite volumes. This local operator will be created taking into account the one created on !30, the one `convectiondiffusionccfv.hh` implemented on PDELab, and the one implemented by @oklein in dune-modelling-example.
## Tasks
- [x] Change the name of the [local operator file for richards](dune/dorie/solver/operator_DG.hh) to richards_operator_DG.hh
- [x] Implement the `alpha_volume()` method.
- [x] Implement the `jacobian_volume()` method.
- [x] Implement the `alpha_skeleton()` method.
- [x] Implement the `jacobian_skeleton()` method.
- [x] Implement the `alpha_boundary()` method.
- [x] Implement the `jacobian_boundary()` method.
- [x] Implement the `lambda_volume()` method.
## How to test the implementation?
Testing the local operator is hard without the external framework, so this task will be tied to those tasks implementing a `TransportSimulation`.
## Formulation
_**Warning**: I have to check these equations again. It seems to be that there is a mistake. Source terms omitted by now._
The strong formulation for solute transport is
```math
\begin{aligned}
\partial_t[\theta C_w] + \nabla\cdot [\textbf{j}_w C_w] - \nabla [\theta \mathsf{D}_{eff}\nabla C_w]=0 &\qquad \text{in } \Omega\\
C_w = g &\qquad \text{on } \Gamma_D \subseteq\partial\Omega\\
\nabla C_w \cdot \textbf{n} = \textbf{j}_{\scriptscriptstyle C_w}& \qquad \text{on } \Gamma_N =\partial\Omega \backslash \Gamma_D
\end{aligned}
```
with $`\textbf{j}_w = \theta \textbf{v}_w`$ and $`\mathsf{D}_{eff}(\textbf{j}_w,\theta)`$. Now, following formulation in `dune-pdelab-tutorial02` we use the ansatz function $`u=C_w`$ and the test function $`v`$, we have that the weak formulation for the spatial part is
```math
\int_\Omega \nabla\cdot [\textbf{j}_w u] v - \int_\Omega\nabla [\theta \mathsf{D}_{eff}\nabla u]v \qquad \forall v\in W_h
```
with $` W_h=\{w\in L^2(\Omega)\, : \, w|_T=\text{const for all } T\in\mathcal{T}_h\} `$. Then, integrating by parts
```math
\sum_{T\in\mathcal{T}_h}\left\{\int_{\partial T}(\textbf{j}_wu \cdot \textbf{n})v\,ds-\int_T(\textbf{j}_w\cdot\nabla v)u\,dx-\int_{\partial T}\theta\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}) v\,ds+\int_T\theta\mathsf{D}_{eff}(\nabla u\cdot\nabla v)dx\right\}
```
Taking into account that $`\nabla u|_T=0`$ and approximating normal derivatives we have
```math
\sum_{T\in\mathcal{T}_h}\left\{\int_{\partial T}(\textbf{j}_wu \cdot \textbf{n})v\,ds-\int_{\partial T}\theta\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}) v\,ds\right\}
```
and rearranging
```math
\begin{aligned}
\sum_{F\in\mathcal{F}_h^i}&\left\{\int_{\partial F}(\textbf{j}_w u\cdot\textbf{n}_F)[v(x_{T_F^-})-v(x_{T_F^+})]\right.\\
&-\left.\int_{\partial F}\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)[v(x_{T_F^-})\theta(x_{T_F^-})-v(x_{T_F^+})\theta(x_{T_F^+})] \,ds\right\} \\
+\sum_{F\in\mathcal{F}_h^{\partial\Omega}}&\left\{\int_{\partial F}\left[(\textbf{j}_wu \cdot \textbf{n}_F)-\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]v(x_{T_F^-})\,ds\right\},
\end{aligned}
```
```math
\text{with}\quad\nabla u\cdot \textbf{n}_F=\frac{u_h(x_{T_F^+})-u_h(x_{T_F^-})}{||x_{T_F^+}-x_{T_F^-}||}+\text{error}
```
For the piecewise-constant elements in the test function, we have that the basis functions that generate the space $`W_h`$ are one on one element and zero on all others, i.e.
```math
\phi_i(x) = \begin{cases}
1 &\text{if } x\in T_i \\
0 &\text{else}
\end{cases}
```
which is equivalent to $`v(x_{T_F^+})=0`$ on the equations above. Then,
```math
\begin{aligned}
&\sum_{F\in\mathcal{F}_h^i}\int_{\partial F}\left[(\textbf{j}_w u \cdot\textbf{n}_F) - \mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]\,ds \\
+&\sum_{F\in\mathcal{F}_h^{\partial\Omega}\cap\Gamma_D}\int_{\partial F}\left[(\textbf{j}_w g \cdot \textbf{n}_F)-\mathsf{D}_{eff}(\nabla^* u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]\,ds\\
-&\sum_{F\in\mathcal{F}_h^{\partial\Omega}\cap\Gamma_N}\int_{\partial F}\mathsf{D}_{eff}\textbf{j}_{\scriptscriptstyle C_w}\theta(x_{T_F^-})\,ds
\end{aligned}
```
where $`\nabla^* u\cdot \textbf{n}_F`$ is the finite difference between $`u`$ and the boundary condition $`g`$ in direction $`\textbf{n}_F`$:
```math
\nabla^* u\cdot \textbf{n}_F=\frac{u_h(x_F)-g(x_{T_F^-})}{||x_F-x_{T_F^-}||}+\text{error}
```
### General Residual Form for Local Operators
```math
\begin{aligned}
r(u,v)=&\sum_{T\in\mathcal{T}_h}\alpha_T^V(\mathcal{R}_Tu,\mathcal{R}_Tv)+\sum_{T\in\mathcal{T}_h}\lambda_T^V(\mathcal{R}_Tv)\\
+&\sum_{F\in\mathcal{F}_h^i}\alpha_F^S(\mathcal{R}_{T_F^-}u,\mathcal{R}_{T_F^+}u,\mathcal{R}_{T_F^-}v,\mathcal{R}_{T_F^+}v)\\
+&\sum_{F\in\mathcal{F}_h^{\partial\Omega}}\alpha_F^B(\mathcal{R}_{T_F^-}u,\mathcal{R}_{T_F^-}v)+\sum_{F\in\mathcal{F}_h^{\partial\Omega}}\alpha_F^B(\mathcal{R}_{T_F^-}v)
\end{aligned}
```
## Related issues
#72
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->## Description
The local operator must model the formulation of the transport equation in finite volumes. This local operator will be created taking into account the one created on !30, the one `convectiondiffusionccfv.hh` implemented on PDELab, and the one implemented by @oklein in dune-modelling-example.
## Tasks
- [x] Change the name of the [local operator file for richards](dune/dorie/solver/operator_DG.hh) to richards_operator_DG.hh
- [x] Implement the `alpha_volume()` method.
- [x] Implement the `jacobian_volume()` method.
- [x] Implement the `alpha_skeleton()` method.
- [x] Implement the `jacobian_skeleton()` method.
- [x] Implement the `alpha_boundary()` method.
- [x] Implement the `jacobian_boundary()` method.
- [x] Implement the `lambda_volume()` method.
## How to test the implementation?
Testing the local operator is hard without the external framework, so this task will be tied to those tasks implementing a `TransportSimulation`.
## Formulation
_**Warning**: I have to check these equations again. It seems to be that there is a mistake. Source terms omitted by now._
The strong formulation for solute transport is
```math
\begin{aligned}
\partial_t[\theta C_w] + \nabla\cdot [\textbf{j}_w C_w] - \nabla [\theta \mathsf{D}_{eff}\nabla C_w]=0 &\qquad \text{in } \Omega\\
C_w = g &\qquad \text{on } \Gamma_D \subseteq\partial\Omega\\
\nabla C_w \cdot \textbf{n} = \textbf{j}_{\scriptscriptstyle C_w}& \qquad \text{on } \Gamma_N =\partial\Omega \backslash \Gamma_D
\end{aligned}
```
with $`\textbf{j}_w = \theta \textbf{v}_w`$ and $`\mathsf{D}_{eff}(\textbf{j}_w,\theta)`$. Now, following formulation in `dune-pdelab-tutorial02` we use the ansatz function $`u=C_w`$ and the test function $`v`$, we have that the weak formulation for the spatial part is
```math
\int_\Omega \nabla\cdot [\textbf{j}_w u] v - \int_\Omega\nabla [\theta \mathsf{D}_{eff}\nabla u]v \qquad \forall v\in W_h
```
with $` W_h=\{w\in L^2(\Omega)\, : \, w|_T=\text{const for all } T\in\mathcal{T}_h\} `$. Then, integrating by parts
```math
\sum_{T\in\mathcal{T}_h}\left\{\int_{\partial T}(\textbf{j}_wu \cdot \textbf{n})v\,ds-\int_T(\textbf{j}_w\cdot\nabla v)u\,dx-\int_{\partial T}\theta\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}) v\,ds+\int_T\theta\mathsf{D}_{eff}(\nabla u\cdot\nabla v)dx\right\}
```
Taking into account that $`\nabla u|_T=0`$ and approximating normal derivatives we have
```math
\sum_{T\in\mathcal{T}_h}\left\{\int_{\partial T}(\textbf{j}_wu \cdot \textbf{n})v\,ds-\int_{\partial T}\theta\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}) v\,ds\right\}
```
and rearranging
```math
\begin{aligned}
\sum_{F\in\mathcal{F}_h^i}&\left\{\int_{\partial F}(\textbf{j}_w u\cdot\textbf{n}_F)[v(x_{T_F^-})-v(x_{T_F^+})]\right.\\
&-\left.\int_{\partial F}\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)[v(x_{T_F^-})\theta(x_{T_F^-})-v(x_{T_F^+})\theta(x_{T_F^+})] \,ds\right\} \\
+\sum_{F\in\mathcal{F}_h^{\partial\Omega}}&\left\{\int_{\partial F}\left[(\textbf{j}_wu \cdot \textbf{n}_F)-\mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]v(x_{T_F^-})\,ds\right\},
\end{aligned}
```
```math
\text{with}\quad\nabla u\cdot \textbf{n}_F=\frac{u_h(x_{T_F^+})-u_h(x_{T_F^-})}{||x_{T_F^+}-x_{T_F^-}||}+\text{error}
```
For the piecewise-constant elements in the test function, we have that the basis functions that generate the space $`W_h`$ are one on one element and zero on all others, i.e.
```math
\phi_i(x) = \begin{cases}
1 &\text{if } x\in T_i \\
0 &\text{else}
\end{cases}
```
which is equivalent to $`v(x_{T_F^+})=0`$ on the equations above. Then,
```math
\begin{aligned}
&\sum_{F\in\mathcal{F}_h^i}\int_{\partial F}\left[(\textbf{j}_w u \cdot\textbf{n}_F) - \mathsf{D}_{eff}(\nabla u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]\,ds \\
+&\sum_{F\in\mathcal{F}_h^{\partial\Omega}\cap\Gamma_D}\int_{\partial F}\left[(\textbf{j}_w g \cdot \textbf{n}_F)-\mathsf{D}_{eff}(\nabla^* u\cdot \textbf{n}_F)\theta(x_{T_F^-})\right]\,ds\\
-&\sum_{F\in\mathcal{F}_h^{\partial\Omega}\cap\Gamma_N}\int_{\partial F}\mathsf{D}_{eff}\textbf{j}_{\scriptscriptstyle C_w}\theta(x_{T_F^-})\,ds
\end{aligned}
```
where $`\nabla^* u\cdot \textbf{n}_F`$ is the finite difference between $`u`$ and the boundary condition $`g`$ in direction $`\textbf{n}_F`$:
```math
\nabla^* u\cdot \textbf{n}_F=\frac{u_h(x_F)-g(x_{T_F^-})}{||x_F-x_{T_F^-}||}+\text{error}
```
### General Residual Form for Local Operators
```math
\begin{aligned}
r(u,v)=&\sum_{T\in\mathcal{T}_h}\alpha_T^V(\mathcal{R}_Tu,\mathcal{R}_Tv)+\sum_{T\in\mathcal{T}_h}\lambda_T^V(\mathcal{R}_Tv)\\
+&\sum_{F\in\mathcal{F}_h^i}\alpha_F^S(\mathcal{R}_{T_F^-}u,\mathcal{R}_{T_F^+}u,\mathcal{R}_{T_F^-}v,\mathcal{R}_{T_F^+}v)\\
+&\sum_{F\in\mathcal{F}_h^{\partial\Omega}}\alpha_F^B(\mathcal{R}_{T_F^-}u,\mathcal{R}_{T_F^-}v)+\sum_{F\in\mathcal{F}_h^{\partial\Omega}}\alpha_F^B(\mathcal{R}_{T_F^-}v)
\end{aligned}
```
## Related issues
#72
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->Solute Transport Feature2018-07-18Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/72[meta] Finite Volume Method for Solute Transport2019-12-18T15:35:34+01:00Santiago Ospina De Los Ríossospinar@gmail.com[meta] Finite Volume Method for Solute Transport_Note:_ This is a meta-task. It bundles several tasks together and is only closed once all these tasks are finished.
### Aims
Following the sequence of steps stated on %"Solute Transport Feature", this meta-issue must implement a Finite Volume method in `dorie` out of the code implemented in !30, and must create some benchmarks to test the transport solution.
### Tasks
* Finite Volume solver
* [x] #73 Create a Local Operator for finite volume scheme.
* [x] #94 Propose a base class for simulations.
* [x] !65 Modify traits system such that they are consistent with the two different models.
* [x] #95 Modify `RichardsSimulation` to have the base class #94.
* [x] #98 Implement a simulation object for transport: `TransportSimulation`.
* [x] #70 Define data structures for data exchange between `RichardsSimulation` and `TransportSimulation`.
* [ ] ~~#100 Couple the `TransportSimulation` with a simple ODE solver for richards equation.~~
* [x] !64 Manage solutions (and therefore adaptors) with shared pointers.
* [x] !96 Couple the `TransportSimulation` with `RichardsSimulation`.
* [ ] ~~!96 Manage adaptivity for coupled systems.~~
* Benchmakrs
* [ ] ~~Prepare few benchmarks to test the code in order to compare later with the dG method.~~
<!-- Remember to mention tasks with '#' here, once they are created. -->
### People involved
@sospinar
### Related meta-tasks
#73
<!-- Meta-tasks of other groups that require coordination -->
<!--
PLEASE READ THIS
A meta task is used to organise and discuss several regular tasks.
When creating this meta task, please take care of the following:
- When new tasks that belong to this meta-task are created,
link them here, and add them as tasks
- Attach the correct labels
- Mention the people that should get involved
- Assign the correct milestone (if available)
-->_Note:_ This is a meta-task. It bundles several tasks together and is only closed once all these tasks are finished.
### Aims
Following the sequence of steps stated on %"Solute Transport Feature", this meta-issue must implement a Finite Volume method in `dorie` out of the code implemented in !30, and must create some benchmarks to test the transport solution.
### Tasks
* Finite Volume solver
* [x] #73 Create a Local Operator for finite volume scheme.
* [x] #94 Propose a base class for simulations.
* [x] !65 Modify traits system such that they are consistent with the two different models.
* [x] #95 Modify `RichardsSimulation` to have the base class #94.
* [x] #98 Implement a simulation object for transport: `TransportSimulation`.
* [x] #70 Define data structures for data exchange between `RichardsSimulation` and `TransportSimulation`.
* [ ] ~~#100 Couple the `TransportSimulation` with a simple ODE solver for richards equation.~~
* [x] !64 Manage solutions (and therefore adaptors) with shared pointers.
* [x] !96 Couple the `TransportSimulation` with `RichardsSimulation`.
* [ ] ~~!96 Manage adaptivity for coupled systems.~~
* Benchmakrs
* [ ] ~~Prepare few benchmarks to test the code in order to compare later with the dG method.~~
<!-- Remember to mention tasks with '#' here, once they are created. -->
### People involved
@sospinar
### Related meta-tasks
#73
<!-- Meta-tasks of other groups that require coordination -->
<!--
PLEASE READ THIS
A meta task is used to organise and discuss several regular tasks.
When creating this meta task, please take care of the following:
- When new tasks that belong to this meta-task are created,
link them here, and add them as tasks
- Attach the correct labels
- Mention the people that should get involved
- Assign the correct milestone (if available)
-->Solute Transport FeatureSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/71Rebuild Parameter data structures on current I/O2018-10-25T15:21:51+02:00Lukas Riedelmail@lukasriedel.comRebuild Parameter data structures on current I/O### Description
As a first step, the data structures for Parameters and Parameterizations will be rebuilt without changes to the current data I/O and parameter input.
### Proposal
* Add class `FlowParameters`, storing parameterization information for each grid entity
* Add class interface `RichardsParameters`
* Add class `MualemVanGenuchtenParameters`
* Use strong types internally (only)
* Adapt local operators
* Adapt VTK adaptors
For using the current I/O, we need to
* Use `MualemVanGenuchten` with `NearestNeighborInterpolator` to read in the data from the file
* Then translate to the new data structures and destroy `MualemVanGenuchten`.
### New class structure
```plantuml
FlowParameters "1 per medium" *-- RichardsParameterization
FlowParameters "1 per cell" *-- Scaling
RichardsParameterization <|-- MualemVanGenuchtenParameterization
RichardsParameterization <|-- BrooksCoreyParameterization
class FlowParameters {
- _param : map<index, pair<shared_ptr<RP>, Scaling>>
- _cache : pair<index, pair<shared_ptr<RP>, Scaling>>
- _gv : LevelGridView
- _mapper : MCMGMapper<LevelGridView>
- _config: ParameterTree
__ Caching __
+ bind (Entity)
+ cache () : pair<index, pair<shared_ptr<RP>, Scaling>>
- verify_cache ()
__ Parameterization functions __
+ conductivity_f () : function<RF(RF)>
+ saturation_f () : function<RF(RF)>
+ water_content_f () : function<RF(RF)>
+ matric_head_f () : function<RF(RF)>
}
note top of FlowParameters
Class communicating with the LocalOperator
and all other DUNE and DORiE classes and functions.
end note
class Scaling {
+ head_scale : double
+ cond_scale :double
+ por_scale : double
}
abstract class RichardsParameterization {
# _theta_r : ResidualWaterContent
# _theta_s : SaturatedWaterContent
# _k0 : SaturatedConductivity
__
+ water_content_f () : function<WaterContent(Saturation)>
..
+ {abstract} saturation_f () : function<Saturation(MatricHead)>
+ {abstract} conductivity_f () : function<Conductivity(Saturation)>
..
+ {abstract} parameters () : map<string, double&>
}
note top of RichardsParameterization
Abstract interface for parameterizations.
Contains common values and functions.
end note
class MualemVanGenuchtenParameterization {
- _alpha : Alpha
- _n : N
- _tau : Tortuosity
__
+ saturation_f () : function<Saturation(MatricHead)>
+ conductivity_f () : function<Conductivity(Saturation)>
..
+ parameters () : map<string, double&>
}
class BrooksCoreyParameterization {
- _h0 : AirEntryValue
- _lambda : PoreSizeDistribution
- _tau : Tortuosity
__
+ saturation_f () : function<Saturation(MatricHead)>
+ conductivity_f () : function<Conductivity(Saturation)>
..
+ parameters () : map<string, double&>
}
```
### How to test the implementation?
Load data from old to new structure. Then verify that functions return the same values at all grid cells.
### Related issues
See #63.### Description
As a first step, the data structures for Parameters and Parameterizations will be rebuilt without changes to the current data I/O and parameter input.
### Proposal
* Add class `FlowParameters`, storing parameterization information for each grid entity
* Add class interface `RichardsParameters`
* Add class `MualemVanGenuchtenParameters`
* Use strong types internally (only)
* Adapt local operators
* Adapt VTK adaptors
For using the current I/O, we need to
* Use `MualemVanGenuchten` with `NearestNeighborInterpolator` to read in the data from the file
* Then translate to the new data structures and destroy `MualemVanGenuchten`.
### New class structure
```plantuml
FlowParameters "1 per medium" *-- RichardsParameterization
FlowParameters "1 per cell" *-- Scaling
RichardsParameterization <|-- MualemVanGenuchtenParameterization
RichardsParameterization <|-- BrooksCoreyParameterization
class FlowParameters {
- _param : map<index, pair<shared_ptr<RP>, Scaling>>
- _cache : pair<index, pair<shared_ptr<RP>, Scaling>>
- _gv : LevelGridView
- _mapper : MCMGMapper<LevelGridView>
- _config: ParameterTree
__ Caching __
+ bind (Entity)
+ cache () : pair<index, pair<shared_ptr<RP>, Scaling>>
- verify_cache ()
__ Parameterization functions __
+ conductivity_f () : function<RF(RF)>
+ saturation_f () : function<RF(RF)>
+ water_content_f () : function<RF(RF)>
+ matric_head_f () : function<RF(RF)>
}
note top of FlowParameters
Class communicating with the LocalOperator
and all other DUNE and DORiE classes and functions.
end note
class Scaling {
+ head_scale : double
+ cond_scale :double
+ por_scale : double
}
abstract class RichardsParameterization {
# _theta_r : ResidualWaterContent
# _theta_s : SaturatedWaterContent
# _k0 : SaturatedConductivity
__
+ water_content_f () : function<WaterContent(Saturation)>
..
+ {abstract} saturation_f () : function<Saturation(MatricHead)>
+ {abstract} conductivity_f () : function<Conductivity(Saturation)>
..
+ {abstract} parameters () : map<string, double&>
}
note top of RichardsParameterization
Abstract interface for parameterizations.
Contains common values and functions.
end note
class MualemVanGenuchtenParameterization {
- _alpha : Alpha
- _n : N
- _tau : Tortuosity
__
+ saturation_f () : function<Saturation(MatricHead)>
+ conductivity_f () : function<Conductivity(Saturation)>
..
+ parameters () : map<string, double&>
}
class BrooksCoreyParameterization {
- _h0 : AirEntryValue
- _lambda : PoreSizeDistribution
- _tau : Tortuosity
__
+ saturation_f () : function<Saturation(MatricHead)>
+ conductivity_f () : function<Conductivity(Saturation)>
..
+ parameters () : map<string, double&>
}
```
### How to test the implementation?
Load data from old to new structure. Then verify that functions return the same values at all grid cells.
### Related issues
See #63.v2.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/70Solution Container2019-01-08T18:18:23+01:00Santiago Ospina De Los Ríossospinar@gmail.comSolution Container### Description
Because of the two simulations (or models) that we want to couple, Richards and Transport, and the fact that they can have different time steps, it is necessary to store their solutions and be able to provide intermediate results by some evaluation policy (i.e. linear interpolation, previous solution, or last solution).
`dune-modelling` provide a solution, nevertheless it has two drawbacks:
1. Simple containers always do a hard copy of the solutions. (easy to change)
2. `SolutionStorage` require a complete interface made with dune modelling with the definition of `Traits`, `ModelParameters`, `EquationTraits`, and `Boundary`.
### Proposal
In order to continue using the same interface, I would like to require that a container of several solutions to mirror or extend a `GridFunction` such that is easy to be reused in other contexts. For example, that way will be easy to store the solution in arbitrary times with the `VTKWriter` (see discussion on #102). On the other hand, It will select the right solution when a solvers asks the local operators to set the time.
### How to test the implementation?
* An indirect form to test this is to check that mass is being conserved on the solute solution
### Related MR.
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->### Description
Because of the two simulations (or models) that we want to couple, Richards and Transport, and the fact that they can have different time steps, it is necessary to store their solutions and be able to provide intermediate results by some evaluation policy (i.e. linear interpolation, previous solution, or last solution).
`dune-modelling` provide a solution, nevertheless it has two drawbacks:
1. Simple containers always do a hard copy of the solutions. (easy to change)
2. `SolutionStorage` require a complete interface made with dune modelling with the definition of `Traits`, `ModelParameters`, `EquationTraits`, and `Boundary`.
### Proposal
In order to continue using the same interface, I would like to require that a container of several solutions to mirror or extend a `GridFunction` such that is easy to be reused in other contexts. For example, that way will be easy to store the solution in arbitrary times with the `VTKWriter` (see discussion on #102). On the other hand, It will select the right solution when a solvers asks the local operators to set the time.
### How to test the implementation?
* An indirect form to test this is to check that mass is being conserved on the solute solution
### Related MR.
<!--
PLEASE READ THIS
Briefly explain __what__ should be changed and __propose__ how this can happen.
Adding pseudo code or diagrams would be great!
Additionally, you can:
- add suitable labels
- assign a milestone
- mention other issues
-->Solute Transport FeatureSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/69Add additional debug job with Clang2018-09-03T14:25:19+02:00Lukas Riedelmail@lukasriedel.comAdd additional debug job with Clang### Description
We now support Clang which emits more warnings than GCC. This should be reflected in the testing.
### Proposal
* Have two testing images, one with Clang and one with GCC.
* Compile a smaller executable for debug builds.
* Have two debug builds, one with GCC and one with Clang.
* Fix all compiler warnings
### How to test the implementation?
* Both Debug builds succeed (without warnings)
### Related issues
See #28### Description
We now support Clang which emits more warnings than GCC. This should be reflected in the testing.
### Proposal
* Have two testing images, one with Clang and one with GCC.
* Compile a smaller executable for debug builds.
* Have two debug builds, one with GCC and one with Clang.
* Fix all compiler warnings
### How to test the implementation?
* Both Debug builds succeed (without warnings)
### Related issues
See #28Santiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/67PkLocalFiniteElementMap creates continuous function space2018-05-15T14:38:16+02:00Lukas Riedelmail@lukasriedel.comPkLocalFiniteElementMap creates continuous function space### Description
We use `PkLocalFiniteElementMap` for grids with simplices. This type of finite element map creates a continuous function space instead of a discontinuous one.
This was noticed when comparing the DOF of a simplex grid to the number of vertices. As the case for CG spaces, the number of DOF was equal to the number of vertices.
### Proposal
Switch `PkLocalFiniteElementMap` to `OPBLocalFiniteElementMap`, whatever that is.
### How to test the implementation?
* Pipeline passes
* Verify number of DOF### Description
We use `PkLocalFiniteElementMap` for grids with simplices. This type of finite element map creates a continuous function space instead of a discontinuous one.
This was noticed when comparing the DOF of a simplex grid to the number of vertices. As the case for CG spaces, the number of DOF was equal to the number of vertices.
### Proposal
Switch `PkLocalFiniteElementMap` to `OPBLocalFiniteElementMap`, whatever that is.
### How to test the implementation?
* Pipeline passes
* Verify number of DOFLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/65[meta] Reconstruct physical flux from DG solution2019-01-15T19:22:25+01:00Lukas Riedelmail@lukasriedel.com[meta] Reconstruct physical flux from DG solution_Note:_ This is a meta-task. It bundles several tasks together and is only closed once all these tasks are finished.
### Aims
The DG solution is discontinuous by nature, but handles fluxes arising from solution jumps at interfaces are handled appropriately in the discretization scheme. This is not the case if fluxes are evaluated from the current solution without considering an appropriate reconstruction based on interface jumps. The reconstruction is also necessary to compute solute transport, since it requires a continuous physical flux as input.
For flux reconstruction we use an implementation from the dune-modelling module, which must be incorporated into the requirements and our testing image.
### Tasks
* ~~[ ] #66: Add dune-modelling as dependency~~ _Delayed usage of `dune-modelling` module until further development_
* [ ] !52 Compute reconstructed fluxes in the solver routine
* [ ] #62: Replace current flux with reconstructed fluxes in the VTK output
### People involved
@lriedel @sospinar
<!--
PLEASE READ THIS
A meta task is used to organise and discuss several regular tasks.
When creating this meta task, please take care of the following:
- When new tasks that belong to this meta-task are created,
link them here, and add them as tasks
- Attach the correct labels
- Mention the people that should get involved
- Assign the correct milestone (if available)
-->_Note:_ This is a meta-task. It bundles several tasks together and is only closed once all these tasks are finished.
### Aims
The DG solution is discontinuous by nature, but handles fluxes arising from solution jumps at interfaces are handled appropriately in the discretization scheme. This is not the case if fluxes are evaluated from the current solution without considering an appropriate reconstruction based on interface jumps. The reconstruction is also necessary to compute solute transport, since it requires a continuous physical flux as input.
For flux reconstruction we use an implementation from the dune-modelling module, which must be incorporated into the requirements and our testing image.
### Tasks
* ~~[ ] #66: Add dune-modelling as dependency~~ _Delayed usage of `dune-modelling` module until further development_
* [ ] !52 Compute reconstructed fluxes in the solver routine
* [ ] #62: Replace current flux with reconstructed fluxes in the VTK output
### People involved
@lriedel @sospinar
<!--
PLEASE READ THIS
A meta task is used to organise and discuss several regular tasks.
When creating this meta task, please take care of the following:
- When new tasks that belong to this meta-task are created,
link them here, and add them as tasks
- Attach the correct labels
- Mention the people that should get involved
- Assign the correct milestone (if available)
-->Solute Transport FeatureSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/64Order procedures and suggestions regarding solute transport2018-07-06T15:04:34+02:00Lukas Riedelmail@lukasriedel.comOrder procedures and suggestions regarding solute transport### Summary
There have been a couple of suggestions and discussions regarding improvements of DORiE. Most, but not all of them are related to the goal of incorporating solute transport into the current framework. This issue is intended to bring order into this and to discuss how to proceed.
@sospinar, I'd like you to comment (shortly) on the issues and my considerations below and order them by importance or precedence. I also hope to ensure that your development version doesn't diverge too far from the DORiE main build. You are working pretty fast and incorporating large changes back in can be a huge pain in the :butterfly:
Finally, I also have to consider which features enter the next release(s), but this is a minor concern.
### Outdated issues / MRs
* #40: In recent discussions, we decided to implement solute transport in the DORiE framework and only use portions of the dune-modelling module.
* !30: Since #40 is outdated, we can close this MR.
### Ongoing issues
* #63: Can new parameters required for solute transport be implemented in the current setup, or with a small workaround? Then this issue can be considered independent.
* #62: Problems with the flux output in 'vertex' mode are related to the missing flux reconstruction which is also necessary for computing solute transport. I guess this should be one of the primary goals then?
* #11: The subsampling VTK writer previously showed artifacts in matric head and flux, especially after grid refinement. After !21, !43, and resolving #62, we can checkout if it works correctly and if we can finally have full precision output.
### How to order everything
I consider the solute transport part a major undertaking, so I'd like to open up a new Milestone. Work can then be split up into meta-tasks with several issues each, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/52 and https://ts-gitlab.iup.uni-heidelberg.de/utopia/utopia/issues/7 for examples of such a procedure. The idea is to have a meta-task for each 'larger' feature, that is then split up into small work assignments. We have had very good results with this kind of ordering in the Utopia project, so I'd like to uphold it here as well.### Summary
There have been a couple of suggestions and discussions regarding improvements of DORiE. Most, but not all of them are related to the goal of incorporating solute transport into the current framework. This issue is intended to bring order into this and to discuss how to proceed.
@sospinar, I'd like you to comment (shortly) on the issues and my considerations below and order them by importance or precedence. I also hope to ensure that your development version doesn't diverge too far from the DORiE main build. You are working pretty fast and incorporating large changes back in can be a huge pain in the :butterfly:
Finally, I also have to consider which features enter the next release(s), but this is a minor concern.
### Outdated issues / MRs
* #40: In recent discussions, we decided to implement solute transport in the DORiE framework and only use portions of the dune-modelling module.
* !30: Since #40 is outdated, we can close this MR.
### Ongoing issues
* #63: Can new parameters required for solute transport be implemented in the current setup, or with a small workaround? Then this issue can be considered independent.
* #62: Problems with the flux output in 'vertex' mode are related to the missing flux reconstruction which is also necessary for computing solute transport. I guess this should be one of the primary goals then?
* #11: The subsampling VTK writer previously showed artifacts in matric head and flux, especially after grid refinement. After !21, !43, and resolving #62, we can checkout if it works correctly and if we can finally have full precision output.
### How to order everything
I consider the solute transport part a major undertaking, so I'd like to open up a new Milestone. Work can then be split up into meta-tasks with several issues each, see https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/issues/52 and https://ts-gitlab.iup.uni-heidelberg.de/utopia/utopia/issues/7 for examples of such a procedure. The idea is to have a meta-task for each 'larger' feature, that is then split up into small work assignments. We have had very good results with this kind of ordering in the Utopia project, so I'd like to uphold it here as well.Solute Transport Featurehttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/63[meta] Parameters and Parametrization2020-06-17T13:36:44+02:00Santiago Ospina De Los Ríossospinar@gmail.com[meta] Parameters and Parametrization## Description
Today's parameter objects have several problems.
* Maybe the most important one is that it's working with dynamic polymorphism even though we only have one parametrization, this is simply not acceptable for functions that do virtually no computation (like `Interpolation` and `MualemVanGenuchten`) and is even worst for functions that only have to access data. Local operators are usually memory bounded, and having this kind of polymorphism affects directly its performance.
* Another problem is that they are strongly coupled with the input of parameters and with its use in the local operator. Since the base structure is an array, it affects directly the partitioning in parallel, plus strange artifacts on the solution in the interface of two parameter cells.
## Proposal
Change parameters and parametrizations objects such that they are based on a continuous or element-wise representation. Gmsh and DFG readers in dune have ways to identify elements (in codims 0 and dim) and therefore also ways to attach parameters to the grid.
Thus, my proposal is to create parameter grids that contain the parameters in a more clean and efficient way. I already have a bit of the code and seems to be a good approach to any kind of input data that is
$`C^{-1}`$ and $`C^0`$, however, the main problem then would be the parameter field generator `pfg`. My approach for that would be just to implement my proposal such that we can attach manually data to Gmsh and DFG, and later, we can take a look how to generate the data directly to for the Gmsh and DFG files.
## Procedures
- [x] #71: Build new parameter structures on top of current implementation
- [x] #89: Introduce [`yaml-cpp`](https://github.com/jbeder/yaml-cpp) as dependency
- [x] #86: Implement new parameter input scheme (with `yaml-cpp`)
- [x] #110: Revamp scaling implementation and add input of global scaling fields
- [ ] Add deprecation warnings to branch `1.1-stable`
- [ ] Add Mualem-Brooks-Corey parameterization
## Description
Today's parameter objects have several problems.
* Maybe the most important one is that it's working with dynamic polymorphism even though we only have one parametrization, this is simply not acceptable for functions that do virtually no computation (like `Interpolation` and `MualemVanGenuchten`) and is even worst for functions that only have to access data. Local operators are usually memory bounded, and having this kind of polymorphism affects directly its performance.
* Another problem is that they are strongly coupled with the input of parameters and with its use in the local operator. Since the base structure is an array, it affects directly the partitioning in parallel, plus strange artifacts on the solution in the interface of two parameter cells.
## Proposal
Change parameters and parametrizations objects such that they are based on a continuous or element-wise representation. Gmsh and DFG readers in dune have ways to identify elements (in codims 0 and dim) and therefore also ways to attach parameters to the grid.
Thus, my proposal is to create parameter grids that contain the parameters in a more clean and efficient way. I already have a bit of the code and seems to be a good approach to any kind of input data that is
$`C^{-1}`$ and $`C^0`$, however, the main problem then would be the parameter field generator `pfg`. My approach for that would be just to implement my proposal such that we can attach manually data to Gmsh and DFG, and later, we can take a look how to generate the data directly to for the Gmsh and DFG files.
## Procedures
- [x] #71: Build new parameter structures on top of current implementation
- [x] #89: Introduce [`yaml-cpp`](https://github.com/jbeder/yaml-cpp) as dependency
- [x] #86: Implement new parameter input scheme (with `yaml-cpp`)
- [x] #110: Revamp scaling implementation and add input of global scaling fields
- [ ] Add deprecation warnings to branch `1.1-stable`
- [ ] Add Mualem-Brooks-Corey parameterization
v2.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/62GradientFluxAdapter problem2019-01-15T19:22:26+01:00Santiago Ospina De Los Ríossospinar@gmail.comGradientFluxAdapter problemIncorrect representation of fluxes in the output
#### Summary
Since fluxes are quite important for the transport model, in `dune-modelling` they are calculated directly from the local operator, later reconstructed and stored using [Raviart-Thomas elements](https://en.wikipedia.org/wiki/Raviart–Thomas_basis_functions), meanwhile, in `DORiE` they are calculated only for postprocessing purposes using `GridFunctionInterface` and later adapted to the vtk output with `VTKGridFunctionAdapter`. Details of both are quite diferent, but in the end, I would say they must representing the very same flux!
#### Steps to reproduce
Enforce a strong Neumann boundary condition.
#### What is the current _bug_ behaviour?
Here I'm posting the differences I have found between both for a 1D case with infiltration. (left `DORiE` VTKAdapter, right `dune-modelling` flux reconstruction)
![Screen_Shot_2018-04-03_at_14.01.31](/uploads/bd6d5efddb5e47b15eadde6960f3d76e/Screen_Shot_2018-04-03_at_14.01.31.png)
In `DORiE`, the flux is being calculated point-wise, which is wrong because in the DG model they have only meaning in the interface of elements. Moreover, the evaluation of the fluxes in the interface is also wrong because they are being computed without taking into account that the head is a discontinuous quantity. This can be seen in the figure: Although the influx is 5.5e-8, only the "inner" flux of the element is computed in the `DORiE` adapter. The missing part of the flux is given by the jump between the boundary and the element face. In this case, with a big jump due to a strong boundary condition, the output already differs by three orders of magnitude.
#### What is the expected _correct_ behaviour?
If the printing is continuous, then, fluxes must be reconstructed. Another option would be to enforce printing only vertex values in the interfaces and restrict somehow the interpolation in paraview such that is clear it doesn't have a clear continuous representation.Incorrect representation of fluxes in the output
#### Summary
Since fluxes are quite important for the transport model, in `dune-modelling` they are calculated directly from the local operator, later reconstructed and stored using [Raviart-Thomas elements](https://en.wikipedia.org/wiki/Raviart–Thomas_basis_functions), meanwhile, in `DORiE` they are calculated only for postprocessing purposes using `GridFunctionInterface` and later adapted to the vtk output with `VTKGridFunctionAdapter`. Details of both are quite diferent, but in the end, I would say they must representing the very same flux!
#### Steps to reproduce
Enforce a strong Neumann boundary condition.
#### What is the current _bug_ behaviour?
Here I'm posting the differences I have found between both for a 1D case with infiltration. (left `DORiE` VTKAdapter, right `dune-modelling` flux reconstruction)
![Screen_Shot_2018-04-03_at_14.01.31](/uploads/bd6d5efddb5e47b15eadde6960f3d76e/Screen_Shot_2018-04-03_at_14.01.31.png)
In `DORiE`, the flux is being calculated point-wise, which is wrong because in the DG model they have only meaning in the interface of elements. Moreover, the evaluation of the fluxes in the interface is also wrong because they are being computed without taking into account that the head is a discontinuous quantity. This can be seen in the figure: Although the influx is 5.5e-8, only the "inner" flux of the element is computed in the `DORiE` adapter. The missing part of the flux is given by the jump between the boundary and the element face. In this case, with a big jump due to a strong boundary condition, the output already differs by three orders of magnitude.
#### What is the expected _correct_ behaviour?
If the printing is continuous, then, fluxes must be reconstructed. Another option would be to enforce printing only vertex values in the interfaces and restrict somehow the interpolation in paraview such that is clear it doesn't have a clear continuous representation.Solute Transport FeatureSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.com