dumux-repositories issues
https://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues
2024-03-25T10:30:31Z
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1315
Regroup parameters to other group
2024-03-25T10:30:31Z
Ivan Buntic
Regroup parameters to other group
The parameters `Problem.PoissonRatio`, `Problem.SandGrainRoughness`, `Problem.UsePrimaryVariableSwitch` and `Problem.YoungsModulus` should not be part of the `Problem` group as the Problem group should only contain parameters of the FVPr...
The parameters `Problem.PoissonRatio`, `Problem.SandGrainRoughness`, `Problem.UsePrimaryVariableSwitch` and `Problem.YoungsModulus` should not be part of the `Problem` group as the Problem group should only contain parameters of the FVProblem and model agnostic problem base classes. Therefore, the four parameters should be regrouped. Once regrouped, the [parameter file](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/doc/doxygen/extradoc/parameters.json) should be updated accordingly for these parameters.
3.9
Yue Wang
yue.wang@iws.uni-stuttgart.de
Yue Wang
yue.wang@iws.uni-stuttgart.de
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1346
[doc] fix as much typos as possible unto next release
2024-02-28T10:42:39Z
Kai Wendel
[doc] fix as much typos as possible unto next release
**Description**
when one reads through the DuMux core codes comments and other documentation, one can find sometimes comments that are obviously not correctly describing the underlining code, or there are typos. It would be worth to try...
**Description**
when one reads through the DuMux core codes comments and other documentation, one can find sometimes comments that are obviously not correctly describing the underlining code, or there are typos. It would be worth to try keeping this as tidy as we could as typos and incorrect comments are limiting the readability.
It is worth the effort, to fix as much obvious (and possbibly also some less obvious) typos or inconsistencies until the upcoming release.
Branch, that focuses on the `freeflow` part: [cleanup/smallCleanups](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/cleanup/smallCleanups?ref_type=heads). The changes are currently all limited to `freeflow`
Branch focusing on fluidsystems: [cleanup/fluidsAndFluidsystems](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/tree/cleanup/fluidsAndFluidsystems?ref_type=heads)
Kai Wendel
Kai Wendel
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1339
[FluidState][Compositional] setRelativeHumidity works on externaly passed Flu...
2024-02-27T16:48:55Z
Lars Kaiser
[FluidState][Compositional] setRelativeHumidity works on externaly passed FluidState object instead of on itself
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README....
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
**What happened / Problem description**:
The method `setRelativeHumidity` needs an FluidState object reference as argument and sets the humidity on this object instead of on the object on which the method is called.
```
template <class FluidState>
void setRelativeHumidity(FluidState &fluidState, int phaseIdx, int compIdx, Scalar value)
```
**What you expected to happen**:
The method alters the FluidState object on which it is called and the method does not need a FluidState object.
```void setRelativeHumidity(int phaseIdx, int compIdx, Scalar value)```
**How to reproduce it (as minimally and precisely as possible)**:
[Source Code](dumux/material/fluidstates/compositional.hh#L380-L398)
**Anything else we need to know?**:
Is there a specific reason that this method does not work on the object itself?
**Environment**:
- Dune version:
- DuMux version:
- Others:
3.9
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1328
Inactive merge requests and issues
2023-12-13T14:21:40Z
Bernd Flemisch
Inactive merge requests and issues
Let's close inactive merge requests and issues. Inactive for >12 months. Bug reports are excluded.
Close with the comment: Close due to inactivity for >12 months.
Let's close inactive merge requests and issues. Inactive for >12 months. Bug reports are excluded.
Close with the comment: Close due to inactivity for >12 months.
3.9
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1059
Use dynamic polymorphism in mpfa interaction volumes
2023-12-13T11:13:09Z
Dennis Gläser
Use dynamic polymorphism in mpfa interaction volumes
The mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle bou...
The mpfa code is super difficult to understand. One thing that makes it additionally complicated is the fact that it allows for two different interaction volume types to be used - because some mpfa methods (like mpfa-l) cannot handle boundary conditions properly. So one approach is to use the o-method at boundaries.
To make it possible to implement such thing, one can define to use different interaction volumes around tagged vertices (default: boundary). But this introduces a bunch of if/else branches that clutter the code.
We could probably get rid of this by using dynamic polymorphism on interaction volumes. The computations to construct an interaction volume and to compute transmissibilities are typically expensive, so I guess the runtime penalty should not matter. We should give this a try to make the mpfa code (at least a tiny bit) less frustrating to read.
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/988
[Forchheimer] Does this work for multi-phase flow?
2023-12-13T11:13:08Z
Dennis Gläser
[Forchheimer] Does this work for multi-phase flow?
In !2414, @martins and I discussed if Forchheimer (or our implementation of it) works for multi-phase settings. It is permitted in the code and, but some variables have names that suggest one-phase flow regimes. Moreover, there is this c...
In !2414, @martins and I discussed if Forchheimer (or our implementation of it) works for multi-phase settings. It is permitted in the code and, but some variables have names that suggest one-phase flow regimes. Moreover, there is this comment:
```cpp
// This is important in the case of a one-phase region in two-phase flow. The non-existing
// phase has a velocity of zero (kr=0).
```
see line 472 in https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/59ee4e5e26d6646dcf7670df8b4f7193a6fe3fda/dumux/flux/cctpfa/forchheimerslaw.hh
Roman Winter
Roman Winter
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/933
Discussion: Unify LocalAssemblers and SubDomainCouplingAssemblers
2023-12-13T11:13:08Z
Kilian Weishaupt
Discussion: Unify LocalAssemblers and SubDomainCouplingAssemblers
From a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
...
From a brief glance at `BoxLocalAssembler` and `SubDomainBoxLocalAssembler` it seems that there is a large degree of code duplication. I think it should be possible to make `SubDomainBoxLocalAssembler` inherit from `BoxLocalAssembler`.
The only critical parts are some calls to `couplingManager`. This could be replaced by some lambda calls which do nothing for the non-coupling assembler. The coupled assembler could then call the base class' function with a specialized lambda which .
, e.g., update the coupled variables.
We could evaluate the possibility of streamlining our code on the next Dumux day.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/832
Reduce code duplication in nonequilibrium/volumevariables.hh
2023-12-13T11:13:08Z
Timo Koch
timokoch@math.uio.no
Reduce code duplication in nonequilibrium/volumevariables.hh
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/nonequilibrium/volumevariables.hh
For example, the dimensionless numbers could be put in a separate class.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/214
FS#214 Implement naming rules for class names
2023-12-13T11:13:07Z
Bernd Flemisch
FS#214 Implement naming rules for class names
# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Versi...
# Metadata
| Property | Value |
| -------- | ----- |
| Project | dumux |
| Category | General |
| Reported by | Bernd Flemisch (bernd@iws.uni-stuttgart.de) |
| Reported at | Nov 4, 2013 09:34 |
| Type | Feature Request |
| Version | Git |
| Last edited by | Kilian Weishaupt (kilian.weishaupt@iws.uni-stuttgart.de) |
| Last edited at | Jan 22, 2016 10:18 |
# Description
From 2.3 to 2.4, all member functions and enums have been adapted to our naming conventions. We want to evaluate how we want to do this for class names. Currently, we have inconsistencies like TwoPTwoCNI and Stokes2cni. We discuss in particular the issue about digits in class names.
Newer compilers should provide easier deprecation possibilities. An example will follow.
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/586
Analytical differentiation with MultiDomain
2023-12-13T11:13:07Z
Dennis Gläser
Analytical differentiation with MultiDomain
It seems like the interfaces for analytical differentiation disappeared from the base coupling manager, but are still called from the local assemblers.
We should clean this up and revise the assemble routines for analytical differentiat...
It seems like the interfaces for analytical differentiation disappeared from the base coupling manager, but are still called from the local assemblers.
We should clean this up and revise the assemble routines for analytical differentiation in the local multidomain assemblers. Also, we should introduce the respective interfaces to the base coupling managers and throw proper error messages.
@timok, didn't you have an implementation for analytical differentiation in the embedded framework? I don't see it anymore...
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1311
Deprecation warnings from TimeLoop+Python
2023-10-27T18:10:25Z
Timo Koch
timokoch@math.uio.no
Deprecation warnings from TimeLoop+Python
```
python/common/timeloop.hh:54:14: warning: 'setCheckPoint' is deprecated: Use setCheckpoint(begin, end) instead. Will be removed after release 3.9. [-Wdeprecated-declarations]
self.setCheckPoint(checkPoints);
^
py...
```
python/common/timeloop.hh:54:14: warning: 'setCheckPoint' is deprecated: Use setCheckpoint(begin, end) instead. Will be removed after release 3.9. [-Wdeprecated-declarations]
self.setCheckPoint(checkPoints);
^
python/common/timeloop.hh:62:5: note: in instantiation of function template specialization 'Dumux::Python::registerTimeLoop<double>' requested here
registerTimeLoop(scope, cls);
^
python/dumux/common/_common.cc:26:13: note: in instantiation of function template specialization 'Dumux::Python::registerTimeLoop<double>' requested here
Python::registerTimeLoop<double>(module);
^
dumux/common/timeloop.hh:646:10: note: 'setCheckPoint' has been explicitly marked deprecated here
void setCheckPoint(const std::vector<ScalarOrDuration>& checkPoints)
^
python/dumux/common/_common.cc:13:
python/common/timeloop.hh:54:14: warning: 'setCheckPoint<double>' is deprecated: Use setCheckpoint(begin, end) instead. Will be removed after release 3.9. [-Wdeprecated-declarations]
self.setCheckPoint(checkPoints);
^
dumux/common/timeloop.hh:645:7: note: 'setCheckPoint<double>' has been explicitly marked deprecated here
[[deprecated("Use setCheckpoint(begin, end) instead. Will be removed after release 3.9.")]]
^
2 warnings generated.
```
3.8
Dennis Gläser
Dennis Gläser
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1300
[porousmediumflow][2pnc][volvars] Correct comment for dynamic viscosity
2023-09-27T18:01:14Z
Anna Mareike Kostelecky
[porousmediumflow][2pnc][volvars] Correct comment for dynamic viscosity
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README....
<!--
SPDX-FileCopyrightInfo: Copyright © DuMux Project contributors, see AUTHORS.md in root folder
SPDX-License-Identifier: CC0-1.0
-->
<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
@Simon Grether pointed out, that in [/dumux/porousmediumflow/2pnc/volumevariables.hh](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/blob/master/dumux/porousmediumflow/2pnc/volumevariables.hh?ref_type=heads#L353) the comment for the viscosity says kinematic viscosity, but it's actually the **dynamic** viscosity.
This should be changed to avoid confusion.
3.8
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1235
Remove deprecation warnings related to "fvGeometry.geometry(scvf)" before rel...
2023-03-23T07:05:43Z
Hamza Oukili
Remove deprecation warnings related to "fvGeometry.geometry(scvf)" before release 3.7
There are multiple similar warnings when building tests: is deprecated: Will be removed after 3.7. Use fvGeometry.geometry(scvf).
`/dumux/dumux/test/freeflow/navierstokes/angeli/main.cc:137:28: required from here
/dumux/dumux/test/fre...
There are multiple similar warnings when building tests: is deprecated: Will be removed after 3.7. Use fvGeometry.geometry(scvf).
`/dumux/dumux/test/freeflow/navierstokes/angeli/main.cc:137:28: required from here
/dumux/dumux/test/freeflow/navierstokes/angeli/problem.hh:308:41: warning: ‘Dumux::CCTpfaSubControlVolumeFace<GV, T>::Geometry Dumux::CCTpfaSubControlVolumeFace<GV, T>::geometry() const [with GV = Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > > >; T = Dumux::CCTpfaDefaultScvfGeometryTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > > > >; Dumux::CCTpfaSubControlVolumeFace<GV, T>::Geometry = Dune::MultiLinearGeometry<double, 1, 2, Dumux::CCTpfaDefaultScvfGeometryTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantOffsetCoordinates<double, 2> > > > >::ScvfMLGTraits<double> >]’ is deprecated: Will be removed after 3.7. Use fvGeometry.geometry(scvf). [-Wdeprecated-declarations]
308 | const auto geo = entity.geometry();
| ~~~~~~~~~~~~~~~^~
In file included from /dumux/dumux/dumux/discretization/cellcentered/tpfa/fvgridgeometry.hh:41,
from /dumux/dumux/dumux/discretization/cctpfa.hh:40,
from /dumux/dumux/test/freeflow/navierstokes/angeli/properties.hh:36,
from /dumux/dumux/test/freeflow/navierstokes/angeli/main.cc:56:
/dumux/dumux/dumux/discretization/cellcentered/tpfa/subcontrolvolumeface.hh:205:14: note: declared here
205 | Geometry geometry() const
| ^~~~~~~~
`
3.7
Hanchuan Wu
Hanchuan Wu
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1231
Remove deprecation warnings related to "NavierStokesMomentumCVFE" before rele...
2023-03-22T14:16:03Z
Hamza Oukili
Remove deprecation warnings related to "NavierStokesMomentumCVFE" before release 3.7
There are multiple similar warnings: This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag.
`Building CXX object test/freeflow/navierstokes/donea/CMakeFiles/test_ff_stokes_donea_momentum.dir/main_m...
There are multiple similar warnings: This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag.
`Building CXX object test/freeflow/navierstokes/donea/CMakeFiles/test_ff_stokes_donea_momentum.dir/main_momentum.cc.o
In file included from /dumux/test/freeflow/navierstokes/donea/properties_momentum.hh:54,
from /dumux/test/freeflow/navierstokes/donea/main_momentum.cc:58:
/dumux/dumux/freeflow/navierstokes/momentum/diamond/model.hh:48:2: warning: #warning "This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag." [-Wcpp]
48 | #warning "This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag."
| ^~~~~~~
In file included from /dumux/test/freeflow/navierstokes/donea/properties_momentum.hh:57,
from /dumux/test/freeflow/navierstokes/donea/main_momentum.cc:58:
/dumux/dumux/freeflow/navierstokes/momentum/pq1bubble/model.hh:48:2: warning: #warning "This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag." [-Wcpp]
48 | #warning "This file is deprecated and will be removed after 3.7. Use NavierStokesMomentumCVFE type tag."
| ^~~~~~~
`
3.7
Stefanie Kiemle
Stefanie Kiemle
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1230
Remove deprecation warnings related to "conversion of multitype matrices" bef...
2023-03-20T21:05:54Z
Hamza Oukili
Remove deprecation warnings related to "conversion of multitype matrices" before release 3.7
There are multiple similar warnings : After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature
`In file included from /dumux/dumux/multidomain/newtonsolver.hh:29,
...
There are multiple similar warnings : After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature
`In file included from /dumux/dumux/multidomain/newtonsolver.hh:29,
from /dumux/test/freeflow/navierstokes/angeli/main.cc:48:
/dumux/dumux/nonlinear/newtonsolver.hh: In instantiation of ‘bool Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystem_(Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >]’:
/dumux/dumux/nonlinear/newtonsolver.hh:518:25: required from ‘void Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystem(Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >]’
/dumux/dumux/nonlinear/newtonsolver.hh:982:17: required from ‘bool Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solve_(typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType = Dumux::PDESolver<Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>, Dumux::UMFPackBackend>]’
/dumux/dumux/nonlinear/newtonsolver.hh:351:36: required from ‘void Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solve(typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::TimeLoop&) [with Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; typename Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType::Variables = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ParentType = Dumux::PDESolver<Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>, Dumux::UMFPackBackend>; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::TimeLoop = Dumux::TimeLoopBase<double>]’
/dumux/test/freeflow/navierstokes/angeli/main.cc:177:30: required from here
/dumux/dumux/nonlinear/newtonsolver.hh:1122:38: warning: ‘std::enable_if_t<((! Dumux::linearSolverAcceptsMultiTypeMatrix<LS>()) && Dumux::isMultiTypeBlockVector<V>()), bool> Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::solveLinearSystemImpl_(LinearSolver&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::JacobianMatrix&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&, Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector&) [with LS = Dumux::UMFPackBackend; V = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >; Assembler = Dumux::MultiDomainFVAssembler<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass>, Dumux::FCStaggeredFreeFlowCouplingManager<Dumux::MultiDomainTraits<Dumux::Properties::TTag::AngeliTestMomentum, Dumux::Properties::TTag::AngeliTestMass> >, Dumux::DiffMethod::numeric>; LinearSolver = Dumux::UMFPackBackend; Reassembler = Dumux::DefaultPartialReassembler; Comm = Dune::Communication<ompi_communicator_t*>; std::enable_if_t<((! Dumux::linearSolverAcceptsMultiTypeMatrix<LS>()) && Dumux::isMultiTypeBlockVector<V>()), bool> = bool; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::JacobianMatrix = Dune::MultiTypeBlockMatrix<Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > > >, Dune::MultiTypeBlockVector<Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > >, Dune::BCRSMatrix<Dune::FieldMatrix<double, 1, 1>, std::allocator<Dune::FieldMatrix<double, 1, 1> > > > >; Dumux::NewtonSolver<Assembler, LinearSolver, Reassembler, Comm>::ResidualVector = Dune::MultiTypeBlockVector<Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > >, Dune::BlockVector<Dune::FieldVector<double, 1>, std::allocator<Dune::FieldVector<double, 1> > > >]’ is deprecated: After 3.7 Newton will no longer support conversion of multitype matrices for solvers that don't support this feature! [-Wdeprecated-declarations]
1122 | return solveLinearSystemImpl_(this->linearSolver(),
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
1123 | this->assembler().jacobian(),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1124 | deltaU,
| ~~~~~~~
1125 | this->assembler().residual());
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/dumux/dumux/nonlinear/newtonsolver.hh:1183:5: note: declared here
1183 | solveLinearSystemImpl_(LinearSolver& ls,`
3.7
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1223
Remove solver deprecation warnings
2023-03-20T21:05:52Z
Timo Koch
timokoch@math.uio.no
Remove solver deprecation warnings
* [ ] After merging !3386 there are deprecation warnings concerning the solvers for many test. The solvers should be updated to use the new IstlSolverBackend.
* [ ] After merging !3386 there are deprecation warnings concerning the solvers for many test. The solvers should be updated to use the new IstlSolverBackend.
3.7
Timo Koch
timokoch@math.uio.no
Timo Koch
timokoch@math.uio.no
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1225
[python][cmake] Simplify Python CMake code with dune 2.9
2023-03-09T13:26:46Z
Timo Koch
timokoch@math.uio.no
[python][cmake] Simplify Python CMake code with dune 2.9
Also remove documentation for setup with dune 2.8
Also remove documentation for setup with dune 2.8
3.7
Mathis Kelm
Mathis Kelm
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1175
Adapt python make_install script to main-branch name
2022-09-05T18:20:45Z
Katharina Heck
Adapt python make_install script to main-branch name
When running the `make_installscript.py` script, I get an error in pub-moduls where the main branch is called main. This comes from the script `util/common.py` where we check for the persistent branch and we only ask for the name master ...
When running the `make_installscript.py` script, I get an error in pub-moduls where the main branch is called main. This comes from the script `util/common.py` where we check for the persistent branch and we only ask for the name master (line 274). I think this needs to be adapted to also include a check for the name "main". I did not check if this also affects any other scripts, but that could be since I guess the common.py script is used in several places?
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1163
Cleanup code after release 3.5 (removal of deprecated features)
2022-07-28T14:08:45Z
Timo Koch
timokoch@math.uio.no
Cleanup code after release 3.5 (removal of deprecated features)
Features/code/headers/functions/classes deprecated before release 3.5 and marked for removal after release 3.5 can now be removed from the code base.
Features/code/headers/functions/classes deprecated before release 3.5 and marked for removal after release 3.5 can now be removed from the code base.
3.6
Ivan Buntic
Ivan Buntic
https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/1172
2pnc computes densities twice
2022-07-12T19:25:45Z
Timo Koch
timokoch@math.uio.no
2pnc computes densities twice
2pnc (maybe also 2p2c, 3p3c) computes the densities again after they have been computed in the constraint solver.
This seems like unnecessary overhead.
2pnc (maybe also 2p2c, 3p3c) computes the densities again after they have been computed in the constraint solver.
This seems like unnecessary overhead.
3.6