dorie issueshttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues2018-09-03T20:24:22+02:00https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/82Update License to include Santiago as contributor2018-09-03T20:24:22+02:00Lukas Riedelmail@lukasriedel.comUpdate License to include Santiago as contributor### Description
Santiago Ospinar is now a contributor to DORiE (to `master` and the releases) and should be mentioned in the `LICENSE.md` :tada:
@sospinar, do you want to be mentioned by your full name "Santiago Ospina De Los Ríos"? (if that is correct...?)### Description
Santiago Ospinar is now a contributor to DORiE (to `master` and the releases) and should be mentioned in the `LICENSE.md` :tada:
@sospinar, do you want to be mentioned by your full name "Santiago Ospina De Los Ríos"? (if that is correct...?)Lukas 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/78Roll out version 1.12018-08-29T18:07:05+02:00Lukas Riedelmail@lukasriedel.comRoll out version 1.1### To-do in the code
- [x] Create branch `1.1-stable`
- [x] Update `VERSION`, `CHANGELOG`, and `dune.module`
- [x] Create tag `1.1.0`
### To-do in GitLab
- [x] Create label `Pick into 1.1`
### To-do externally
- [x] Deploy Sphinx docs manually (see problems in !71)
- [x] Update description on Docker Hub
- [x] Update `latest` tag on Docker Hub
- [x] Update "Release" badge### To-do in the code
- [x] Create branch `1.1-stable`
- [x] Update `VERSION`, `CHANGELOG`, and `dune.module`
- [x] Create tag `1.1.0`
### To-do in GitLab
- [x] Create label `Pick into 1.1`
### To-do externally
- [x] Deploy Sphinx docs manually (see problems in !71)
- [x] Update description on Docker Hub
- [x] Update `latest` tag on Docker Hub
- [x] Update "Release" badgeLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://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/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/68Update to DUNE v2.62018-08-18T18:37:17+02:00Lukas Riedelmail@lukasriedel.comUpdate to DUNE v2.6### Description
[DUNE Core v2.6](https://www.dune-project.org/releases/2.6.0/#dune-2-6-release-notes) has been released. [`UG`](https://gitlab.dune-project.org/staging/dune-uggrid/blob/master/CHANGELOG.md) and [PDELab](https://gitlab.dune-project.org/pdelab/dune-pdelab/blob/releases/2.6/CHANGELOG.md) received similar updates.
We should update to them asap.
### Expected Adaptations
* `ReferenceElement` had a major overhaul. It is now constructable with `referenceElement(geometry)`.
* Layouts for `MultipleCodimMultipleGeomTypeMapper` are deprecated.
* This sounds really useful (for KnoFu?):
> The new method `MCMGMapper::indices(entity)` returns an iterable range (instance of `IntegralRange<Index>`) with the indices of dofs attached to the given entity: `for (const auto& i : mapper.indices(entity) ) dof = vector[i];`
* `StructuredGridFactory` returns a `unique_ptr` to the grid now
* PDELab extracts the "natural" blocking size from the function space now. This will break un-squaring in `adaptivity.hh`
* `L2` operator now sets integration order by itself (is probably used in adaptivity)
* Rename namespaces this time: `Dune::PDELab::istl` -> `Dune::PDELab::ISTL`
### How to test the implementation?
* Pipeline passing### Description
[DUNE Core v2.6](https://www.dune-project.org/releases/2.6.0/#dune-2-6-release-notes) has been released. [`UG`](https://gitlab.dune-project.org/staging/dune-uggrid/blob/master/CHANGELOG.md) and [PDELab](https://gitlab.dune-project.org/pdelab/dune-pdelab/blob/releases/2.6/CHANGELOG.md) received similar updates.
We should update to them asap.
### Expected Adaptations
* `ReferenceElement` had a major overhaul. It is now constructable with `referenceElement(geometry)`.
* Layouts for `MultipleCodimMultipleGeomTypeMapper` are deprecated.
* This sounds really useful (for KnoFu?):
> The new method `MCMGMapper::indices(entity)` returns an iterable range (instance of `IntegralRange<Index>`) with the indices of dofs attached to the given entity: `for (const auto& i : mapper.indices(entity) ) dof = vector[i];`
* `StructuredGridFactory` returns a `unique_ptr` to the grid now
* PDELab extracts the "natural" blocking size from the function space now. This will break un-squaring in `adaptivity.hh`
* `L2` operator now sets integration order by itself (is probably used in adaptivity)
* Rename namespaces this time: `Dune::PDELab::istl` -> `Dune::PDELab::ISTL`
### How to test the implementation?
* Pipeline passingLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/66Add dune-modelling as dependency2018-10-16T10:59:10+02:00Lukas Riedelmail@lukasriedel.comAdd dune-modelling as dependency### Description
dune-modelling features a flux-reconstruction implementation we want to use. In this case, dune-modelling becomes a requirement for DORiE. However, dune-modelling seems to be a private project for now. We have to talk to Ole about that.
### Proposal
* [x] Talk to Ole how to work around the fact that dune-modelling cannot be accessed publicly:
dune-modelling will remain private for now, but we have access
* [x] Include dune-modelling into ~~the _public_~~ _a new, private_ Docker testing image `dorie/dune-env-mod:2.5.2`
* Add dune-modelling as dependency to the `README.md`
* Add `dune-modelling` as dependency in `dune.module`
### How to test the implementation?
Pipeline succeeds with dune-modelling as (unused) dependency.
### Related issues
See #65### Description
dune-modelling features a flux-reconstruction implementation we want to use. In this case, dune-modelling becomes a requirement for DORiE. However, dune-modelling seems to be a private project for now. We have to talk to Ole about that.
### Proposal
* [x] Talk to Ole how to work around the fact that dune-modelling cannot be accessed publicly:
dune-modelling will remain private for now, but we have access
* [x] Include dune-modelling into ~~the _public_~~ _a new, private_ Docker testing image `dorie/dune-env-mod:2.5.2`
* Add dune-modelling as dependency to the `README.md`
* Add `dune-modelling` as dependency in `dune.module`
### How to test the implementation?
Pipeline succeeds with dune-modelling as (unused) dependency.
### Related issues
See #65Lukas 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/61Add GitLab convenience features for release workflow2018-04-14T21:38:41+02:00Lukas Riedelmail@lukasriedel.comAdd GitLab convenience features for release workflow### Description
DORiE has a stable version now. We need to make some changes & additions to the repository to adapt for this workflow. This includes changes to the description templates and some new tags.
### Proposal
- [x] Add task to MR template: 'Added `CHANGELOG` entry'
- [x] Add label ~"Pick into 1.0" for bugfixes
### Up for discussion/thoughts
* When/How to roll out a new version?
Thoughts:
* We don't need labels or milestones for new versions. All changes go to `master`. As soon as we feel like it, we create a new release branch. A milestone can be created for coordinating a new release. The type of the release (`MAJOR` or `MINOR`) depends on the changes added between the releases.### Description
DORiE has a stable version now. We need to make some changes & additions to the repository to adapt for this workflow. This includes changes to the description templates and some new tags.
### Proposal
- [x] Add task to MR template: 'Added `CHANGELOG` entry'
- [x] Add label ~"Pick into 1.0" for bugfixes
### Up for discussion/thoughts
* When/How to roll out a new version?
Thoughts:
* We don't need labels or milestones for new versions. All changes go to `master`. As soon as we feel like it, we create a new release branch. A milestone can be created for coordinating a new release. The type of the release (`MAJOR` or `MINOR`) depends on the changes added between the releases.https://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/59Roll out version 1.02018-03-28T22:11:56+02:00Lukas Riedelmail@lukasriedel.comRoll out version 1.0Let's do this!
- [x] Add CHANGELOG
- [x] Add VERSION
- [x] Create branch `1.0-stable`
- [x] Create tag `1.0.0` for appropriate commit
- [x] Build and upload Docker image `1.0.0` from tagLet's do this!
- [x] Add CHANGELOG
- [x] Add VERSION
- [x] Create branch `1.0-stable`
- [x] Create tag `1.0.0` for appropriate commit
- [x] Build and upload Docker image `1.0.0` from tagv1.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/58Add contributing guide2018-04-03T10:22:11+02:00Lukas Riedelmail@lukasriedel.comAdd contributing guide### Description
For now, the DORiE repository will be made public, but contribution via GitLab is only possible as member of the TS-CCEES group. This has to be made clear in the contribution guide. Moreover, we have to address other ways of contributing.
### Proposal
- Indicate that GitLab accounts are only available for group members and associates
- Bug reports, feature requests, and improvement suggestions can be filed via email
- Indicate that resources for support are stretched thin within our group
### Additionally...
- [ ] Discuss with @yunus (& Kurt?): Would we grant an account to external people willing to contribute to DORiE?### Description
For now, the DORiE repository will be made public, but contribution via GitLab is only possible as member of the TS-CCEES group. This has to be made clear in the contribution guide. Moreover, we have to address other ways of contributing.
### Proposal
- Indicate that GitLab accounts are only available for group members and associates
- Bug reports, feature requests, and improvement suggestions can be filed via email
- Indicate that resources for support are stretched thin within our group
### Additionally...
- [ ] Discuss with @yunus (& Kurt?): Would we grant an account to external people willing to contribute to DORiE?v1.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/57Add licence information2018-03-28T15:35:09+02:00Lukas Riedelmail@lukasriedel.comAdd licence information### Description
DORiE is to be released, and should come with a license. There are two options:
* [GPLv3](https://choosealicense.com/licenses/gpl-3.0/): Easy license, which requires modifications of the source code to be distributed under the same license. Also used by DUNE. However, DUNE comes with a runtime exception, allowing for runtimes compiled from it not to be licensed under GPLv3. Moreover, DORiE does not _modify_ DUNE code, so we are in these terms free to distribute the source code under a different license.
* [MIT](https://choosealicense.com/licenses/mit/): The simplest license which just requires redistributors to include license and copyright notices.
### Proposal
Add MIT license to DORiE.### Description
DORiE is to be released, and should come with a license. There are two options:
* [GPLv3](https://choosealicense.com/licenses/gpl-3.0/): Easy license, which requires modifications of the source code to be distributed under the same license. Also used by DUNE. However, DUNE comes with a runtime exception, allowing for runtimes compiled from it not to be licensed under GPLv3. Moreover, DORiE does not _modify_ DUNE code, so we are in these terms free to distribute the source code under a different license.
* [MIT](https://choosealicense.com/licenses/mit/): The simplest license which just requires redistributors to include license and copyright notices.
### Proposal
Add MIT license to DORiE.v1.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.com