dorie issueshttps://ts-gitlab.iup.uni-heidelberg.de/groups/dorie/-/issues2019-11-28T15:46:10+01:00https://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.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/56Add job for building and deploying DORiE Docker image2018-06-08T10:41:18+02:00Lukas Riedelmail@lukasriedel.comAdd job for building and deploying DORiE Docker image### Description
DockerHub will be the primary hub for accessing DORiE. After tests were successful, DORiE should be compiled into a Docker image which is then pushed to the Docker Hub. However, this requires Docker to be executed from within a GitLab runner.
### Proposal
- [x] Register new runner with [docker-in-docker executor](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor) (see https://ts-gitlab.iup.uni-heidelberg.de/infrastructure/hermes/issues/11)
- Add job that rebuilds the DUNE environment
- Add build job that builds DORiE based on the shipped `Dockerfile`
### How to test the implementation?
Deploy job works. DORiE is available from Docker Hub.
### Related issues### Description
DockerHub will be the primary hub for accessing DORiE. After tests were successful, DORiE should be compiled into a Docker image which is then pushed to the Docker Hub. However, this requires Docker to be executed from within a GitLab runner.
### Proposal
- [x] Register new runner with [docker-in-docker executor](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor) (see https://ts-gitlab.iup.uni-heidelberg.de/infrastructure/hermes/issues/11)
- Add job that rebuilds the DUNE environment
- Add build job that builds DORiE based on the shipped `Dockerfile`
### How to test the implementation?
Deploy job works. DORiE is available from Docker Hub.
### Related issuesv1.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/55Change the header system2018-07-26T16:01:29+02:00Santiago Ospina De Los Ríossospinar@gmail.comChange the header system### Description
DORiE has a central header system, that is, all headers are included in one file `dorie.hh`. Its use is quite convenient when it is needed to use all functionalities of DORiE, however, that is not always the case. An example of this is the `impl/` folder where we create a library with instances of `simulation` objects: since every header is not independent, it's not enough to call `simulation.hh` and we are forced to have to call `dorie.hh`. This is counter-productive for the library because it also creates the object `SimulationFactory` which at the same time creates many instantiations of `Simulation`. Because we want an individual instantiation of `Simulation` per `.cc` file we are forced to exclude `SimulationFactory` somehow, leading to awkward CPP directives:
``` c++
#ifndef DUNE_DORIE_SIMULATION_FACTORY_HH
#define DUNE_DORIE_SIMULATION_FACTORY_HH
#endif
```
### Proposal
*Decentralize* the header system making every header independent and self-sufficient from others.
### How to test the implementation?
Changing `#include <dune/dorie/dorie.hh>` for `#include <dune/dorie/interface/simulation.hh>` in every file in `impl` would be enough.
### Related issues and MR
This is a proposal made by @lriedel in !30.
<!--
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
DORiE has a central header system, that is, all headers are included in one file `dorie.hh`. Its use is quite convenient when it is needed to use all functionalities of DORiE, however, that is not always the case. An example of this is the `impl/` folder where we create a library with instances of `simulation` objects: since every header is not independent, it's not enough to call `simulation.hh` and we are forced to have to call `dorie.hh`. This is counter-productive for the library because it also creates the object `SimulationFactory` which at the same time creates many instantiations of `Simulation`. Because we want an individual instantiation of `Simulation` per `.cc` file we are forced to exclude `SimulationFactory` somehow, leading to awkward CPP directives:
``` c++
#ifndef DUNE_DORIE_SIMULATION_FACTORY_HH
#define DUNE_DORIE_SIMULATION_FACTORY_HH
#endif
```
### Proposal
*Decentralize* the header system making every header independent and self-sufficient from others.
### How to test the implementation?
Changing `#include <dune/dorie/dorie.hh>` for `#include <dune/dorie/interface/simulation.hh>` in every file in `impl` would be enough.
### Related issues and MR
This is a proposal made by @lriedel in !30.
<!--
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
-->Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/54Raise mass conservation limits2018-03-16T19:44:40+01:00Lukas Riedelmail@lukasriedel.comRaise mass conservation limits#### Summary
Apparently, !14 changed the results of the mass conservation test. This might be due to the different time step behavior, as the tests run much faster now. This indicates that global mass conservation also depends on time step size.
#### What is the current behaviour?
Mass conservation test for static simplex grid fails. Mass conservation is three orders of magnitude worse than expected.
### Proposal
* Raise mass conservation limits to appropriate value
* Add tests on rectangular grids again, because execution time is much lower now.#### Summary
Apparently, !14 changed the results of the mass conservation test. This might be due to the different time step behavior, as the tests run much faster now. This indicates that global mass conservation also depends on time step size.
#### What is the current behaviour?
Mass conservation test for static simplex grid fails. Mass conservation is three orders of magnitude worse than expected.
### Proposal
* Raise mass conservation limits to appropriate value
* Add tests on rectangular grids again, because execution time is much lower now.v1.0 ReleaseLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/53Use Git LFS for storing H5 and VTK files2018-10-16T10:54:04+02:00Lukas Riedelmail@lukasriedel.comUse Git LFS for storing H5 and VTK files### Description
I need to change the reference VTK files (again), and we might change the H5 parameter field files in the future. To avoid bloating up local repositories, we could store these binary files with [Git LFS](https://git-lfs.github.com/). However, this requires `git-lfs` to be installed on client systems for simply cloning DORiE.
Another option would be to create a separate repository just for the testing files, as done in KnoFu. However, I would like files to remain within a single repository.
### Proposal
- [ ] Enable Git LFS for this repository
* Make `git-lfs` a requirement for DORiE (!)
* Track `.h5` and `.vtu` files with LFS
### Related issues
We might postpone the new reference tests in #46 until this is decided
### Comments or thoughts appreciated
@sospinar @mfels### Description
I need to change the reference VTK files (again), and we might change the H5 parameter field files in the future. To avoid bloating up local repositories, we could store these binary files with [Git LFS](https://git-lfs.github.com/). However, this requires `git-lfs` to be installed on client systems for simply cloning DORiE.
Another option would be to create a separate repository just for the testing files, as done in KnoFu. However, I would like files to remain within a single repository.
### Proposal
- [ ] Enable Git LFS for this repository
* Make `git-lfs` a requirement for DORiE (!)
* Track `.h5` and `.vtu` files with LFS
### Related issues
We might postpone the new reference tests in #46 until this is decided
### Comments or thoughts appreciated
@sospinar @mfels