dumux merge requests
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests
2023-07-27T17:17:46Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3625
[bin][installdumux] Use logger to print to file and stream simultaneouly and ...
2023-07-27T17:17:46Z
Timo Koch
timokoch@math.uio.no
[bin][installdumux] Use logger to print to file and stream simultaneouly and add progress symbol
(1) Prints simultaneously to stream and file.
The terminal only shows info messages warnings and errors while the file also contains debug output in addition.
Before some output was in the file and some in the terminal which made it diff...
(1) Prints simultaneously to stream and file.
The terminal only shows info messages warnings and errors while the file also contains debug output in addition.
Before some output was in the file and some in the terminal which made it difficult to inspect the log file.
(2) I also added a progress spinner that gets displayed while a command is running.
The initial suggestion for (1) came from @gruenich in !3615. I added a thank you note in the commit message.
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3620
[ff-pm-coupling] allow different discretization schemes
2023-07-26T17:38:33Z
Martin Schneider
[ff-pm-coupling] allow different discretization schemes
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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**:
It allows to implement specializations for ff-pm coupling
<!--
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**
I have made separate commits for the renaming such that the commit history is easier to read when looking at each of the commits. Before merging, we should squash these renaming commits in the corresponding subsequent commit.
<!--
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.
<!--
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)
-->
3.8
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3613
[test][timestepping] Cache residuals instead of variables
2023-07-14T14:40:38Z
Timo Koch
timokoch@math.uio.no
[test][timestepping] Cache residuals instead of variables
Depends on !3612 (should be merged first)
Depends on !3612 (should be merged first)
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3612
[experimental] Add 3rd order DIRK time stepping scheme
2023-07-13T10:33:53Z
Timo Koch
timokoch@math.uio.no
[experimental] Add 3rd order DIRK time stepping scheme
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3611
Feature/expression parser
2023-07-12T17:45:17Z
Timo Koch
timokoch@math.uio.no
Feature/expression parser
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**What this MR does / why does DuMux need it**:
Adds an expression parser using the ExprTK library....
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
**What this MR does / why does DuMux need it**:
Adds an expression parser using the ExprTK library. This can be used to evaluate math expressions from the parameter input file (functional input).
Before you request a review from someone, make sure to revise the following points:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] 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))
- [x] 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)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] 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.
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3607
[experimental] Implement cached residual variant in test
2023-07-14T14:42:34Z
Timo Koch
timokoch@math.uio.no
[experimental] Implement cached residual variant in test
Implement the timestepping test in a ways that the residuals of the last stage do not have to be recomputed.
This means we also don't have to store the variables of the last step.
Implement the timestepping test in a ways that the residuals of the last stage do not have to be recomputed.
This means we also don't have to store the variables of the last step.
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3569
Draft: Feature/ff pm coupling allow different discretizations
2023-07-26T14:25:19Z
Martin Schneider
Draft: Feature/ff pm coupling allow different discretizations
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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**:
To be able to choose different discretization schemes for ff-pm coupling, we need to allow discretization-dependent specializations.
<!--
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)
-->
3.8
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3544
Improve error message for untracked files in make_installscript.py
2023-08-04T11:19:39Z
Mathis Kelm
Improve error message for untracked files in make_installscript.py
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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**:
Running `make_installscript.py` for a repository with untracked files will give a warning, suggesting `--ignoreuntracked` if they are not necessary. The actual behavior is just to suppress this warning and add untracked files through patches.
<!--
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:
- [x] remove fixup commits
<!--
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:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] 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))
- [x] 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)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] 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.
<!--
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)
-->
3.8
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3426
Add dualnetwork test from dumux-pub repository Koch2021a
2023-05-22T06:19:57Z
Anna Mareike Kostelecky
Add dualnetwork test from dumux-pub repository Koch2021a
<!--
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**:
This adds the possibility to s...
<!--
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**:
This adds the possibility to study the heat transfer between one fluid phase and a solid phase with one porenetwork model for the void space coupled to one network model for the solid phase (dualnetwork)
In addition one test case is provided with reference solutions
<!--
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**
Files and test case, where taken from [https://git.iws.uni-stuttgart.de/dumux-pub/Koch2021a](https://git.iws.uni-stuttgart.de/dumux-pub/Koch2021a) and modified, such that it is runs on the current master
<!--
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:
- [x] does the new code follow the [style guide](doc/styleguide.md)?
- [x] 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))
- [x] 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)
- [x] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [x] is the list of the header includes complete? ("include what you use")
- [x] 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.
- [x] (if not applicable remove) are newly introduced or modified physical values/functions backed up with a scientific reference (including doi) in the docs?
<!--
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)
-->
3.8
Anna Mareike Kostelecky
Anna Mareike Kostelecky
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/421
Replace const char * by std::string for type safety
2017-11-27T14:09:17Z
Timo Koch
timokoch@math.uio.no
Replace const char * by std::string for type safety
Sina Ackermann
Sina Ackermann
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2563
[components] Add component LinearizedH2O
2023-09-27T16:15:58Z
Timo Koch
timokoch@math.uio.no
[components] Add component LinearizedH2O
Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new com...
Fixes #1013
I hope this is consistent. Water vapor is modeled as an ideal gas. inner energy and vapor pressure are linearized around the reference state. The evaporation enthalpy should be automatically included now.
I added a new component as this implementation will probably yield different results than SimpleH2O.
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2012
[WIP] TEMP: first draft of new staggered fvgridgeometry
2023-02-19T23:24:45Z
Kilian Weishaupt
[WIP] TEMP: first draft of new staggered fvgridgeometry
This is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs
This is a first prototype for a "real" staggered fvGeometry.
Results of discussion so far:
* staggered fvGeometry contains 4 (2D quad cells) scvs and 12 scvfs
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/2001
[WIP] Feature/python fluidsystem
2023-12-13T10:52:21Z
Kilian Weishaupt
[WIP] Feature/python fluidsystem
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.
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 Weishaupt
Kilian Weishaupt
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1215
[fix] Fix Wshadow warnings from dumux.
2018-10-31T16:21:09Z
Farid Mohammadi
[fix] Fix Wshadow warnings from dumux.
Related issue: #469
Related issue: #469
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1117
[freeflow] Move calculation of BJS-velocity to model and adapt the calculation…
2018-07-20T12:55:00Z
Thomas Fetzer
[freeflow] Move calculation of BJS-velocity to model and adapt the calculation…
[freeflow] Move calculation of BJS-velocity to model and adapt the calculation of velocity gradients for the RANS models
[freeflow] Move calculation of BJS-velocity to model and adapt the calculation of velocity gradients for the RANS models
Sina Ackermann
Sina Ackermann
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/1112
[fluidsystems] Add a 1p adapter fluidsystem for multi-phase fluid systems
2018-07-20T12:54:59Z
Timo Koch
timokoch@math.uio.no
[fluidsystems] Add a 1p adapter fluidsystem for multi-phase fluid systems
Fixes #528.
* Adds the 1p adapter
* Uses it in the 1p tests
* uses it in the fluid system tests
* other models can incrementally follow this implementation as everything is compatible
- VtkOutputModule doesn't need phaseOffset ...
Fixes #528.
* Adds the 1p adapter
* Uses it in the 1p tests
* uses it in the fluid system tests
* other models can incrementally follow this implementation as everything is compatible
- VtkOutputModule doesn't need phaseOffset anymore (once no model uses it anymore)
- fluidsystem phase index is now always 0 and main component index also 0 (to keep the convention the component indices are switched by the adapter if the second/third phase is chosen)
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/291
Feature/mpfaboundaryhandling
2016-12-13T10:01:00Z
Dennis Gläser
Feature/mpfaboundaryhandling
This also introduces flux-specific property tags to set the different flux types (advection, molecular diffusion, heat conduction) to being solution-independent.
This also introduces flux-specific property tags to set the different flux types (advection, molecular diffusion, heat conduction) to being solution-independent.
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3762
Generalize Slip Condition
2024-03-03T11:27:39Z
Martin Schneider
Generalize Slip Condition
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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**:
- All slip condition related functions should not be in base problem but instead implemented on level of test problem
- One should be able to switch slip conditions. Currently BJ was always assumed.
<!--
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**
This is a first draft. There are still some things we should discuss.
TODOs:
- [ ] Can we unify the slip velocity interface? The issue with fcstaggered currently is the fact that the user can pass `tangentialVelocityGradient` which allows to overwrite derivatives
- [x] Is the current BJ implementation even correct in 3D? I would have expected that it is not enough to only consider one single tangential direction
- [x] Also introduce BJS
3.9
Martin Schneider
Martin Schneider
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3759
[richards] allow user to define mpicommunicator for richards solver
2024-02-13T13:03:22Z
Mona Giraud
[richards] allow user to define mpicommunicator for richards solver
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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**:
This patch makes it possible to have different MPIcommunicator for the richards solver. This is usefull when the users want to use the dummy MPIcommunicator
<!--
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.
-->
Before you request a review from someone, make sure to revise the following points:
- [X] does the new code follow the [style guide](doc/styleguide.md)?
- [X] 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))
- [X] 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)
- [X] does your change affect public interfaces or behavior, or, does it introduce a new feature? If so, document the change in `CHANGELOG.md`.
- [X] is the list of the header includes complete? ("include what you use")
- [X] 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.
<!--
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)
-->
Mona Giraud
Mona Giraud
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/3752
Feature/gridformat writer
2024-03-26T15:14:27Z
Dennis Gläser
Feature/gridformat writer
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
Thanks for considering to open a merge request!
Before asking for a review of your MR, please...
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
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 [gridformat](https://github.com/dglaeser/gridformat) as git submodule and a wrapper around its generic readers/writers in order to provide I/O from/to various grid file formats.
TODO:
- [x] Discuss class and file names. The current choice was made s.t. the include is `#include <dumux/io/gridwriter.hh>`, since it's generic over the formats...
- [x] Support discontinuous output. Could be achieved by adding a separate template argument and perform a similar mechanism as currently done for the lagrange wrapper (i.e. add one more wrapper layer around the stored grid...). EDIT: will be done in a separate MR.
- [x] Add support for vol-var output as in `VTKOutputModule`. I suggest to derive from this writer and expose an additional `setVolVarField` function, because for vol var output we need more things (e.g. `GridVariables`, `X`, etc...). By adding it as additional derived class we can keep simple output "simpler". EDIT: will be done in a separate MR.
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)
-->
3.9
Dennis Gläser
Dennis Gläser