dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2020-03-18T09:58:02Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/795[tabulation] Generalize tabulation and interpolation2020-03-18T09:58:02ZBeatrix Becker[tabulation] Generalize tabulation and interpolationShould be possible to switch to splines, Should work for pc-sw tooShould be possible to switch to splines, Should work for pc-sw too3.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/549Add comparisons to analytical solutions for Richards model2020-03-17T21:51:00ZTimo Kochtimo.koch@iws.uni-stuttgart.deAdd comparisons to analytical solutions for Richards modelThere are some contributed Richards benchmark in dumux-appl/dumux-rootgrowth.
I would be nice to add the analytical solutions (which are not in C++ now) and add tests to dumux.There are some contributed Richards benchmark in dumux-appl/dumux-rootgrowth.
I would be nice to add the analytical solutions (which are not in C++ now) and add tests to dumux.3.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/210FS#210 enthalpy of dissolved component2020-03-17T21:52:47ZFSFS#210 enthalpy of dissolved component# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Last edited at | Sep 22, 2015 06:52 |
# Description
In the fluidsystems currently used in \\\\\\\\Dumux (those that do not use tables), the enthalpy of the dissolved component is either neglected (e.g. n2 in H2O in h2on2fluidsystem) or the enthalpy of the gas state is used (h2on2fluidsystemkinetic).
In either case the enthalpy of dissolution http://en.wikipedia.org/wiki/Enthalpy_change_of_solution is neglected.
If this is on purpose, it should be somewhere documented.# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | Fluid systems |
| Reported by | Philipp Nuske (philipp.nuske@iws.uni-stuttgart.de) |
| Reported at | Oct 16, 2013 08:40 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Nicolas Schwenck (nicolas.schwenck@iws.uni-stuttgart.de) |
| Last edited at | Sep 22, 2015 06:52 |
# Description
In the fluidsystems currently used in \\\\\\\\Dumux (those that do not use tables), the enthalpy of the dissolved component is either neglected (e.g. n2 in H2O in h2on2fluidsystem) or the enthalpy of the gas state is used (h2on2fluidsystemkinetic).
In either case the enthalpy of dissolution http://en.wikipedia.org/wiki/Enthalpy_change_of_solution is neglected.
If this is on purpose, it should be somewhere documented.3.3https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/415Implement better tests for freeflow2020-03-25T14:54:40ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deImplement better tests for freeflow__This isssue has been split into #839 #838 #837 and will be closed.__
There is a myriad of benchmarks, numerical and analytical solutions for free-flow problems. We should incorporate more of them in our free-flow tests. Thomas and Christoph had some of them for their staggered grid implementation.
Currently, there are two test which come with an analytical solution:
`test_donea` and `test_kovasznay`
Here a some ideas what could be added:
- [ ] Analytical solution for simple stationary 2d channel test (test already exists)
- [ ] [Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341)
- [x] Transient flow field test with analytical solution
- [ ] Transient flow field test: lid driven cavity
- [ ] Analytical solution for diffusion (mass/energy) tests
- [x] Ensure same results for mass and mole formulation (see !950)
More suggestions welcome!
- [ ] Improve the description of the tests and the help-message
Could be a job for a HiWi.__This isssue has been split into #839 #838 #837 and will be closed.__
There is a myriad of benchmarks, numerical and analytical solutions for free-flow problems. We should incorporate more of them in our free-flow tests. Thomas and Christoph had some of them for their staggered grid implementation.
Currently, there are two test which come with an analytical solution:
`test_donea` and `test_kovasznay`
Here a some ideas what could be added:
- [ ] Analytical solution for simple stationary 2d channel test (test already exists)
- [ ] [Ghia 1982](https://ac.els-cdn.com/0021999182900584/1-s2.0-0021999182900584-main.pdf?_tid=e9f7486c-d67c-11e7-96b6-00000aab0f26&acdnat=1512121945_6871c2de3e7d5699f53ef718416dc341)
- [x] Transient flow field test with analytical solution
- [ ] Transient flow field test: lid driven cavity
- [ ] Analytical solution for diffusion (mass/energy) tests
- [x] Ensure same results for mass and mole formulation (see !950)
More suggestions welcome!
- [ ] Improve the description of the tests and the help-message
Could be a job for a HiWi.3.2Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/627Dumux cheat-sheet2019-05-04T19:47:18ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deDumux cheat-sheetHow about writing something similar as the dune cheat-sheet for Dumux?
We could ask a hiwi to do that.How about writing something similar as the dune cheat-sheet for Dumux?
We could ask a hiwi to do that.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/454[task] Remove all deprecation warning related to Components2018-04-10T16:00:12ZTimo Kochtimo.koch@iws.uni-stuttgart.de[task] Remove all deprecation warning related to ComponentsComponents are now in the namespace `Components`. Components should now derive from `Base` and `Liquid`, `Gas`, and/or `Solid` depending on for what states they are implemented.Components are now in the namespace `Components`. Components should now derive from `Base` and `Liquid`, `Gas`, and/or `Solid` depending on for what states they are implemented.3.0Timo Kochtimo.koch@iws.uni-stuttgart.deTimo Kochtimo.koch@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/451[task] Use the new `NewtonSolver`s in all tests2018-04-09T14:08:55ZTimo Kochtimo.koch@iws.uni-stuttgart.de[task] Use the new `NewtonSolver`s in all tests3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/85FS#85 Implement time step ramp up for the implicit models2016-11-23T18:46:34ZFSFS#85 Implement time step ramp up for the implicit models# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Anonymous (Id=0) |
| Reported at | Apr 1, 2010 09:53 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Anonymous (Id=1) |
| Last edited at | Aug 17, 2010 08:21 |
| Closed by | Anonymous (Id=1) |
| Closed at | Aug 17, 2010 08:21 |
| Closed in version | unknown (Id=0) |
| Resolution | Implemented |
# Description
```
The current implementation of the newton method uses the same time step size for each of its iterations. Given that the main non-linearities lie in the storage term, it should be possible to achieve much larger final time steps if the time step size is "ramped up" in the first few iterations of the newton method. in pseudo-code this approach looks like this:
rampUpIterations = 3;
finalDeltaT = timeManager.timeStepSize();
while (numIterations < rampUpIterations && !converged()) {
if (numIterations < rampUpIterations) {
// here, we can chose different strategies
deltaTFraction = (numIterations + 1)/rampUpIterations;
timeManager.setTimeStepSize(finalDeltaT * deltaTFraction);
}
// do a newton iteration
};
The task involves implementing the approach in DuMuX, comparing the ramp-up approach with the current approach and testing different strategies for the ramp up. Strategies can be a linear, accelerating or deaccelerating the fraction of the final time step size during the course of the ramp-up.
```# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Anonymous (Id=0) |
| Reported at | Apr 1, 2010 09:53 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Anonymous (Id=1) |
| Last edited at | Aug 17, 2010 08:21 |
| Closed by | Anonymous (Id=1) |
| Closed at | Aug 17, 2010 08:21 |
| Closed in version | unknown (Id=0) |
| Resolution | Implemented |
# Description
```
The current implementation of the newton method uses the same time step size for each of its iterations. Given that the main non-linearities lie in the storage term, it should be possible to achieve much larger final time steps if the time step size is "ramped up" in the first few iterations of the newton method. in pseudo-code this approach looks like this:
rampUpIterations = 3;
finalDeltaT = timeManager.timeStepSize();
while (numIterations < rampUpIterations && !converged()) {
if (numIterations < rampUpIterations) {
// here, we can chose different strategies
deltaTFraction = (numIterations + 1)/rampUpIterations;
timeManager.setTimeStepSize(finalDeltaT * deltaTFraction);
}
// do a newton iteration
};
The task involves implementing the approach in DuMuX, comparing the ramp-up approach with the current approach and testing different strategies for the ramp up. Strategies can be a linear, accelerating or deaccelerating the fraction of the final time step size during the course of the ramp-up.
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/30FS#30 Implement the weierstrass box scheme2016-11-23T18:46:33ZFSFS#30 Implement the weierstrass box scheme# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Anonymous (Id=0) |
| Reported at | Dec 10, 2009 16:41 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | Jul 9, 2012 09:37 |
| Closed by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Closed at | Jul 9, 2012 09:37 |
| Closed in version | unknown (Id=0) |
| Resolution | Won't implement |
# Description
The weierstrass institute of applied analysis and stochastics (WIAS) uses a box method very similar to the one used by us, but with the exception that the finite element gradients are always perpendicular to the normal of a sub-control volume face. This method has some advantages when it comes to grid effects but requires that the grid used fullfills the Delaunay property. The task for this thesis would be to implement FVElementGeometry geometry in two and three dimensions used by the method. After this, results of the WIAS method will be compared to those produced by our current model.# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Anonymous (Id=0) |
| Reported at | Dec 10, 2009 16:41 |
| Type | Potential Thesis/Job |
| Version | Git |
| Last edited by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Last edited at | Jul 9, 2012 09:37 |
| Closed by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Closed at | Jul 9, 2012 09:37 |
| Closed in version | unknown (Id=0) |
| Resolution | Won't implement |
# Description
The weierstrass institute of applied analysis and stochastics (WIAS) uses a box method very similar to the one used by us, but with the exception that the finite element gradients are always perpendicular to the normal of a sub-control volume face. This method has some advantages when it comes to grid effects but requires that the grid used fullfills the Delaunay property. The task for this thesis would be to implement FVElementGeometry geometry in two and three dimensions used by the method. After this, results of the WIAS method will be compared to those produced by our current model.