dorie issueshttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues2018-04-14T21:38:41+02:00https://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/62GradientFluxAdapter problem2019-01-15T19:22:26+01:00Santiago Ospina De Los Ríossospinar@gmail.comGradientFluxAdapter problemIncorrect representation of fluxes in the output
#### Summary
Since fluxes are quite important for the transport model, in `dune-modelling` they are calculated directly from the local operator, later reconstructed and stored using [Raviart-Thomas elements](https://en.wikipedia.org/wiki/Raviart–Thomas_basis_functions), meanwhile, in `DORiE` they are calculated only for postprocessing purposes using `GridFunctionInterface` and later adapted to the vtk output with `VTKGridFunctionAdapter`. Details of both are quite diferent, but in the end, I would say they must representing the very same flux!
#### Steps to reproduce
Enforce a strong Neumann boundary condition.
#### What is the current _bug_ behaviour?
Here I'm posting the differences I have found between both for a 1D case with infiltration. (left `DORiE` VTKAdapter, right `dune-modelling` flux reconstruction)
![Screen_Shot_2018-04-03_at_14.01.31](/uploads/bd6d5efddb5e47b15eadde6960f3d76e/Screen_Shot_2018-04-03_at_14.01.31.png)
In `DORiE`, the flux is being calculated point-wise, which is wrong because in the DG model they have only meaning in the interface of elements. Moreover, the evaluation of the fluxes in the interface is also wrong because they are being computed without taking into account that the head is a discontinuous quantity. This can be seen in the figure: Although the influx is 5.5e-8, only the "inner" flux of the element is computed in the `DORiE` adapter. The missing part of the flux is given by the jump between the boundary and the element face. In this case, with a big jump due to a strong boundary condition, the output already differs by three orders of magnitude.
#### What is the expected _correct_ behaviour?
If the printing is continuous, then, fluxes must be reconstructed. Another option would be to enforce printing only vertex values in the interfaces and restrict somehow the interpolation in paraview such that is clear it doesn't have a clear continuous representation.Incorrect representation of fluxes in the output
#### Summary
Since fluxes are quite important for the transport model, in `dune-modelling` they are calculated directly from the local operator, later reconstructed and stored using [Raviart-Thomas elements](https://en.wikipedia.org/wiki/Raviart–Thomas_basis_functions), meanwhile, in `DORiE` they are calculated only for postprocessing purposes using `GridFunctionInterface` and later adapted to the vtk output with `VTKGridFunctionAdapter`. Details of both are quite diferent, but in the end, I would say they must representing the very same flux!
#### Steps to reproduce
Enforce a strong Neumann boundary condition.
#### What is the current _bug_ behaviour?
Here I'm posting the differences I have found between both for a 1D case with infiltration. (left `DORiE` VTKAdapter, right `dune-modelling` flux reconstruction)
![Screen_Shot_2018-04-03_at_14.01.31](/uploads/bd6d5efddb5e47b15eadde6960f3d76e/Screen_Shot_2018-04-03_at_14.01.31.png)
In `DORiE`, the flux is being calculated point-wise, which is wrong because in the DG model they have only meaning in the interface of elements. Moreover, the evaluation of the fluxes in the interface is also wrong because they are being computed without taking into account that the head is a discontinuous quantity. This can be seen in the figure: Although the influx is 5.5e-8, only the "inner" flux of the element is computed in the `DORiE` adapter. The missing part of the flux is given by the jump between the boundary and the element face. In this case, with a big jump due to a strong boundary condition, the output already differs by three orders of magnitude.
#### What is the expected _correct_ behaviour?
If the printing is continuous, then, fluxes must be reconstructed. Another option would be to enforce printing only vertex values in the interfaces and restrict somehow the interpolation in paraview such that is clear it doesn't have a clear continuous representation.Solute Transport FeatureSantiago Ospina De Los Ríossospinar@gmail.comSantiago Ospina De Los Ríossospinar@gmail.comhttps://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/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/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/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/67PkLocalFiniteElementMap creates continuous function space2018-05-15T14:38:16+02:00Lukas Riedelmail@lukasriedel.comPkLocalFiniteElementMap creates continuous function space### Description
We use `PkLocalFiniteElementMap` for grids with simplices. This type of finite element map creates a continuous function space instead of a discontinuous one.
This was noticed when comparing the DOF of a simplex grid to the number of vertices. As the case for CG spaces, the number of DOF was equal to the number of vertices.
### Proposal
Switch `PkLocalFiniteElementMap` to `OPBLocalFiniteElementMap`, whatever that is.
### How to test the implementation?
* Pipeline passes
* Verify number of DOF### Description
We use `PkLocalFiniteElementMap` for grids with simplices. This type of finite element map creates a continuous function space instead of a discontinuous one.
This was noticed when comparing the DOF of a simplex grid to the number of vertices. As the case for CG spaces, the number of DOF was equal to the number of vertices.
### Proposal
Switch `PkLocalFiniteElementMap` to `OPBLocalFiniteElementMap`, whatever that is.
### How to test the implementation?
* Pipeline passes
* Verify number of DOFLukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/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/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/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/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/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/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/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/75Documentation page down2018-09-03T14:22:48+02:00Santiago Ospina De Los Ríossospinar@gmail.comDocumentation page downDocumentation page listed in README.md (http://dorie-docs.gitballoon.com) is down.Documentation page listed in README.md (http://dorie-docs.gitballoon.com) is down.Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.comhttps://ts-gitlab.iup.uni-heidelberg.de/dorie/dorie/-/issues/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/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/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/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/80Estimate of matrix backend entry numbers is wrong2018-09-03T20:24:23+02:00Lukas Riedelmail@lukasriedel.comEstimate of matrix backend entry numbers is wrong### Summary
`estimate_mbe_entries` produces wrong estimates of the matrix backend size.
When constructing the matrix backend, one can given an estimate of the number of matrix entries per element for faster resource allocation. The old values are wrong.
The numbers were extracted from the `patternStatistics` of the `OneStepGridOperator` jacobian, but are related to the wrong blocking that was used before the update to DUNE v2.6 (see #68, !56)
### Correct values
For a DG method, the numbers are
* simplex: `dim + 2`
* cube: `2*dim + 1`
### Summary
`estimate_mbe_entries` produces wrong estimates of the matrix backend size.
When constructing the matrix backend, one can given an estimate of the number of matrix entries per element for faster resource allocation. The old values are wrong.
The numbers were extracted from the `patternStatistics` of the `OneStepGridOperator` jacobian, but are related to the wrong blocking that was used before the update to DUNE v2.6 (see #68, !56)
### Correct values
For a DG method, the numbers are
* simplex: `dim + 2`
* cube: `2*dim + 1`
Lukas Riedelmail@lukasriedel.comLukas Riedelmail@lukasriedel.com