dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2023-12-13T10:52:19Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2730Draft: Advection Diffusion Model2023-12-13T10:52:19ZNed ColtmanDraft: Advection Diffusion ModelI'm not sure if this is something we would really want, but I set it up for a different module and mentioned this in issue #1001.
This is the same as the tracer1p model with a stationary velocity field, but it does not assume that the ...I'm not sure if this is something we would really want, but I set it up for a different module and mentioned this in issue #1001.
This is the same as the tracer1p model with a stationary velocity field, but it does not assume that the domain is a porous medium. It should solve the transport equation decoupled from any momentum balance.
The test calculates a velocity field, passes this to a spatialParams, then calculates transport on the same domain with a fixed velocity field. To make it interesting, it's a rectangular domain with a circle cut out of the center.
This should produce the same result as the tracer1p model with the same velocity field and a porosity of 1.
If this is something we do want to include, It would likely benefit from a bit of refactoring.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2572[WIP] Feature/dumux solution vector2023-12-13T10:52:19ZKilian Weishaupt[WIP] Feature/dumux solution vector__TODO__:
- [ ] decide whether this is the way to go (maybe do some performance testing)
- [ ] specify interface
- [ ] make sure the `Assembler` or `NewtonSolver` already get the `native()` object (in context of residuals__TODO__:
- [ ] decide whether this is the way to go (maybe do some performance testing)
- [ ] specify interface
- [ ] make sure the `Assembler` or `NewtonSolver` already get the `native()` object (in context of residualshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3024Draft: Do not merge: Temp/poromech storagederivs hacky fix2023-12-13T10:52:19ZTimo Kochtimokoch@math.uio.noDraft: Do not merge: Temp/poromech storagederivs hacky fixhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1248[WIP] Feature/improve rans2023-12-13T10:52:19ZKilian Weishaupt[WIP] Feature/improve ranshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2433WIP: Feature/new staggered higher order2023-12-13T10:52:19ZNed ColtmanWIP: Feature/new staggered higher ordertodos:
- [x] Sincos higher order test stationary (pass)
- [x] Sincos higher order test instationary (fail)
- [x] 3D Channel higher order test (pass)
- [x] Kovaznay higher order test stationary (fail)
- [ ] Find errors that would cause ba...todos:
- [x] Sincos higher order test stationary (pass)
- [x] Sincos higher order test instationary (fail)
- [x] 3D Channel higher order test (pass)
- [x] Kovaznay higher order test stationary (fail)
- [ ] Find errors that would cause bad convergence and solution differencesNed ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1703WIP Feature/multidomain analytic jac2023-12-13T10:52:19ZTimo Kochtimokoch@math.uio.noWIP Feature/multidomain analytic jacDennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/141[WIP] Velocity output for prisms2023-12-13T10:52:19ZKilian Weishaupt[WIP] Velocity output for prismsBernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2496WIP: [linear] matrix converter with reordering2023-12-13T10:52:20ZTimo Kochtimokoch@math.uio.noWIP: [linear] matrix converter with reorderingWould be probably easier if the matrix converter would have a state.Would be probably easier if the matrix converter would have a state.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2001[WIP] Feature/python fluidsystem2023-12-13T10:52:21ZKilian Weishaupt[WIP] Feature/python fluidsystemThis is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.This is only a proof of concept.
We should decide what types of fluidsystems we want (e.g, 2pnc).
Probably, it also makes sense to create python components.Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3051Draft: Feature/grid geometry observer2023-12-13T10:52:21ZDennis GläserDraft: Feature/grid geometry observerAllows observing grid geometries such that the observers can be notified in case the grid changesAllows observing grid geometries such that the observers can be notified in case the grid changesTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3023Draft::Feature/pnm regualrize kw kn2023-12-13T10:52:21ZHanchuan WuDraft::Feature/pnm regualrize kw knHanchuan WuHanchuan Wuhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2201[WIP] Feature/new staggered impl2023-12-13T10:52:21ZKilian Weishaupt[WIP] Feature/new staggered impl__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ...__TODO__
_General:_
- [ ] Fix docu (especially copy and paste errors)
- [ ] Rethink assembly strategy (forward / inverse)?
- [x] Introduce coupling stencils per DOF?
- [x] improve design of "dual" problem
- [x] boundary flux helpers
- [ ] prohibit Dirichlet for mass model?
- [x] check difference in Jacobian for compressible fluids (channel)
- [x] periodic grids
- [ ] Look into benefits of caching options
- [ ] Add volume work to energy balance
@nedc:
- [x] Set up higher order geometry
- [x] Port the TVD methods
- [x] Add correct checks for various boundary conditions
- [x] Add useful tests for higher order
- [ ] Update and include the rans models
@kweis:
- [x] coupling (staggered-cellcentered)
- [x] implement Beavers-Joseph BC
- [x] Compositional models (1pnc)
@martins
- [ ] Finalize box-staggered coupling (old staggered)
- [ ] Port box-staggered to new staggered
- [ ] Develop new freeflow discretizations (long term)
@hanchuan
- [x] port and test Navier stokes tests (should have been completed already by @kweis)
- [x] port compositional tests (after 1pnc is updated)
- [ ] port stokes-darcy MD tests (after MD is updated)
- [ ] port rans tests (after rans is updated)
fixes #756Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2847Port/problem kovaszny2023-12-13T10:52:21ZYue Wangyue.wang@iws.uni-stuttgart.dePort/problem kovasznyKilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2885[WIP] New staggered higher order2023-12-13T10:52:21ZKilian Weishaupt[WIP] New staggered higher order* fix up allocation sizes and max per elements
* add neighbor element indexes to each scv
* differentiate between neighbor and parallel scvs* fix up allocation sizes and max per elements
* add neighbor element indexes to each scv
* differentiate between neighbor and parallel scvshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3118Draft: [test][richards] Add test case on the square to see influence (-> diff...2023-12-13T10:52:21ZTimo Kochtimokoch@math.uio.noDraft: [test][richards] Add test case on the square to see influence (-> difference...https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3167Draft: [temp] Test precompiled solver factory from dune istl branch2023-12-13T10:52:21ZTimo Kochtimokoch@math.uio.noDraft: [temp] Test precompiled solver factory from dune istl branch<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
TODO: insert text here
<!--
I...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
TODO: insert text here
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
TODO: insert text here
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [ ] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [ ] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [ ] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [ ] (if not applicable remove) if the examples are modified, is the documentation regenerated (using [`generate_example_docs.py`](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/generate_example_docs.py))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3207Draft: Feature/bin find non tested headers2023-12-13T10:52:21ZDennis GläserDraft: Feature/bin find non tested headers<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds a script to determine hea...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
Adds a script to determine headers of a dumux project that are not included by its test suite. This could be included into the test suite to ensure that any new header is covered in the test suite.
Before you request a review from someone, make sure to revise the following points:
- [ ] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (TODO: introduce a fake change to check that selection still works)
- [ ] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3212Draft: staggered par2023-12-13T10:52:22ZTimo Kochtimokoch@math.uio.noDraft: staggered parsee if there is anything from here that can be reused on mastersee if there is anything from here that can be reused on masterTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2979WIP: [freeflow] Diamond scheme2023-12-13T10:52:22ZTimo Kochtimokoch@math.uio.noWIP: [freeflow] Diamond schemeVersion 2 rebased onto master
* [x] Fix tests to work as in version 1
* [x] Fix broken coupling manager (corrupted during the rebase)Version 2 rebased onto master
* [x] Fix tests to work as in version 1
* [x] Fix broken coupling manager (corrupted during the rebase)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3265[pnm] Prevent negative non-wetting area2023-12-13T10:52:22ZHanchuan Wu[pnm] Prevent negative non-wetting area<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
TODO: insert text here
<!--
I...<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please read the [contributing guidelines](/CONTRIBUTING.md)
-->
**What this MR does / why does DuMux need it**:
TODO: insert text here
<!--
Is there a corresponding issue? Add "Fixes hashtag issuenumber" which will automatically close the issue when this MR is merged. Add "Related to hashtag issuenumber" if it's related but doesn't fix the issue completely.
-->
**Notes for the reviewer**
TODO: insert text here
<!--
Keep the following TODO list in the merge request description for documentation.
Bullet points marked with _(if not applicable remove)_ may be removed.
-->
Before you request a review from someone, make sure to revise the following points:
- [ ] does the new code follow the [style guide](doc/styleguide.md)?
- [ ] do the test pipelines pass? (see guide on [how to run pipelines for a merge request](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/wikis/Running-test-pipelines-for-merge-requests))
- [ ] is the code you changed and/or the new code you wrote covered in the test suite? (if not, extend the existing tests or write new ones)
- [ ] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [ ] is the list of the header includes complete? ("include what you use")
- [ ] all files have to end with a `\n` character. Make sure there is no `\ No newline at end of file` comment in "Changes" of this MR.
- [ ] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
- [ ] (if not applicable remove) if the examples are modified, is the documentation regenerated (using [`generate_example_docs.py`](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/examples/generate_example_docs.py))
<!--
The following aspects might also come up during review:
* Does the change reduce the performance of the code (more CPU time or more memory) and is this justified by the benefits
* Does the change improve the performance? (if yes, add this aspect to the MR description)
* Is the code is a gross violation of programming best practices such as DRY (don't repeat yourself / code duplication, see https://de.wikipedia.org/wiki/Don%E2%80%99t_repeat_yourself, the SOLID principles (https://en.wikipedia.org/wiki/SOLID), or the C++ Core Guidelines (https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)?
* Is the code well-documented, concise, easily readable? (e.g. variables are well-named, the logic is split into small & well-named functions)
-->