dumux-repositories issueshttps://git.iws.uni-stuttgart.de/groups/dumux-repositories/-/issues2019-04-03T05:41:22Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/378[doc] Differentiate between test, tutorial/documented, tutorial/undocumented2019-04-03T05:41:22ZTimo Kochtimo.koch@iws.uni-stuttgart.de[doc] Differentiate between test, tutorial/documented, tutorial/undocumentedCurrently we have two general "getting started tutorials", however many of our _tests_ are also thought of tutorials as they demonstrate a certain model.
I suggest to distinguish between _tests_ in the _test_ -folder that are specifically designed to test certain features and are small/run rather fast, and _tutorials_ in the _tutorial_-folder that are designed to show a certain feature, e.g. how to use the tensor grid factory in a Richards model to refine towards the soil top. I further suggest to create two new subfolders _documented_ and _undocumented_ where all _documented tutorials_ have a detailed latex/markdown problem and feature description. In the future, a number of maybe 10 such documented tutorials would be nice. All tutorials in undocumented can potentially become documented in the future.
Of course tutorials should also tested by the automated build system.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/721[Navier-Stokes] Revise definition of transporting velocity on boundary for mo...2019-06-06T09:31:02ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[Navier-Stokes] Revise definition of transporting velocity on boundary for momentum upwindingThe transporting velocity is always
```
const Scalar transportingVelocity = faceVars.velocityLateralInside(localSubFaceIdx);
```
However, if the own scvf lies on a boundary and a tangential slip velocity is specified, we should probably rather take this value.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/711Access to problem quantities (like thermal conductivity) model dependent2019-05-28T13:54:14ZAlexander JaustAccess to problem quantities (like thermal conductivity) model dependentI observed that it is problem-/model-dependent how to obtain the thermal conductivity. This make it hard to reuse some of my functions with different problems/models.
- Would it be possible to unify the interface?
- Is there a (smart) way to generalize functions that should work for different problems/models?
## Short description
The interface to obtain model properties is not unique. Obtaining the thermal conductivity `lambda` looks different for different types of problems used.
- Using `SolidEnergy` model: `lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,problem.spatialParams(),element,fvGeometry,scv)`
- Using `NavierStokesNI` model: `lambda = volVars.effectiveThermalConductivity()`
In my case, this makes is hard to reuse an already implemented function. Moreover, it does not feel intuitive that the interface to obtain the conductivity differs (that much) between two physical models.
## Longer description
Kilian and me have been recently worked on a routine that constructs the temperature on a boundary. It basically gets a heat flux `Q` on the face of an element and the temperature `T_cc` at the cell center. Together with the thermal conductivity `lambda` and the distance from the cell center to the face `distance` obtain the temperature on the face `T_face` from the following formula:
```
Q = - lambda ( T_face - T_center ) / distance
=> T_face = - Q * distance / lambda + T_center
```
It has been implement once for a heat equation problem that inherits from `SolidEnergy`. In this case heat conductivity is obtained via `ThermalConductivityModel::effectiveThermalConductivity`. In my particular case it looks like that:
```c++
const Scalar lambda = ThermalConductivityModel::effectiveThermalConductivity(volVars,
problem.spatialParams(),
element,
fvGeometry,
scv);
```
Now, I wanted to reuse the function for a Navier-Stokes based problem that inherits `NavierStokesNI`. I tried reuse the function we had already written, but this fails since the heat conductivity has to be obtained via the `effectiveThermalConductivity` member function of an object of type `ElementVolumeVariables`. In my case it looks like:
```c++
const Scalar insideLambda = volVars.effectiveThermalConductivity();
```
Due to that I had to implement the same function twice which I would like to avoidhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/707Generic implementation of L2-norm calculation using generic L2-projection2019-05-31T21:20:12ZTimo Kochtimo.koch@iws.uni-stuttgart.deGeneric implementation of L2-norm calculation using generic L2-projectionWith !1609 we get a generic l2-projection. In order to use it for interpolation between two arbitrary grids (arbitrary function spaces already works), we need to implement
* [x] 2d-2d intersections (!1625)
* [ ] 3d-3d intersections
That would be a great tool for convergence tests.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/675[freeflow] Remove property NormalizePressure2019-04-02T06:11:33ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de[freeflow] Remove property NormalizePressureWhen enabled, all pressure related calculations for the momentum equations are done with `p - p_const`. The idea was to lower the numerical values of the pressure in the hope of decreasing numerical errors when further processing the values in for the Jacobian. However, `p - p_const` probably already introduces the same error we wanted to avoid in the first place.
The property and the pressure normalization should therefore be removed after a check of the Matrix' condition number.3.1Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.dehttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/661Possibly include update of Box flux variables cache2019-05-18T11:37:21ZDennis GläserPossibly include update of Box flux variables cacheThe flux variable caches for the box scheme are always assumed to be solution-independent. We should think of a way to support user-defined, solution-dependent caches.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/660Pass FluxVarsCache to Neumann Function2019-05-18T11:54:56ZDennis GläserPass FluxVarsCache to Neumann FunctionWe build the flux variable caches for boundary faces, but do not hand them into the Neumann function, where it could be used. For box, we actually never use the object, so it's unnecessary overhead.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/654Allow C++172019-05-17T16:45:48ZTimo Kochtimo.koch@iws.uni-stuttgart.deAllow C++17I think quite some new features speak for allowing C++17. There are some compilers supporting all features, gcc 8 or gcc 7 (without std::filesystem), clang 8 or 5 (without std::filesystem). https://en.cppreference.com/w/cpp/compiler_support. However, there seems to be no cray compiler.
Who is using the newest Dumux version on a platform without C++17 support?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/652Provide interface for more parallel solvers/preconditioners of ISTL2019-02-01T07:13:01ZLeopold StadlerProvide interface for more parallel solvers/preconditioners of ISTLSo far we have only the AMG-backend (parallel linear solver based on the ISTL AMG preconditioner and the ISTL BiCGSTAB solver). It would be great to add support for more preconditioners and solvers of ISTL.
The following combinations should be available:
* SSOR with BiCGSTAB
* ILU with BiCGSTAB
* ILU with GMRES
Are there any further wishes ?Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/524(Re-)Implement CFL criterion2019-02-15T10:25:14ZTimo Kochtimo.koch@iws.uni-stuttgart.de(Re-)Implement CFL criterionAs a first step of porting the decoupled/sequential models to the new structure, it would be a good thing to implement a CFL criterion for the time step control for the current porousmediumflow models. Add good start is e.g. a CFL is e.g. the 1p_tracer test (https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/tree/master/test/porousmediumflow/tracer/1ptracer) that uses an explicit Euler for the transport but currently has a constant time step that is small enough for the test. CFL would be a big improvement.
@martins Maybe you are the best to deal with this?3.1Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/436Minimize private alias declarations and static constants?2018-02-28T13:59:35ZBernd FlemischMinimize private alias declarations and static constants?Currently, each Dumux class that takes a TypeTag as template parameter typically contains several/many private alias declarations and static constant definitions extracted from the TypeTag. This may happen hundreds of lines above the first usage of the declared names.
An alternative would be to put the declarations as close as possible to the place where they are used. If the declarations are used as function parameter / return types, one could use template parameters / auto instead.
The expected benefit would be an improved readability of the code and the avoidance of unused declarations and definitions.
In order to discuss this, I set up !741. Please have a look and share your opinions here.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/726More tools for regression tests2019-06-17T16:56:36ZTimo Kochtimo.koch@iws.uni-stuttgart.deMore tools for regression tests<!--
This form is for feature requests ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Feature request**
New ideas for regression tests. It should be possible to ignore changes at let's say a saturation front, maybe by allowing a certain number of dofs to have a error higher tolerance. Another idea would be to map the solution of an adaptive grid to some reference grid and compare the solution there (we have some L2-projection capabilities now (only 2d for non-matching grids)).
**What does this feature / why does DuMux need it**:
It would make it possible to create more robust tests in cases where this is desired / physically-sensible.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/725[Navier Stokes] Upwinding of transporting velocity2019-06-17T14:48:00ZMelanie Lipp[Navier Stokes] Upwinding of transporting velocityWe at some point also discussed if we wand to do upwinding also for the transporting velocity. I think it might be better to upwind both factors of the advective term. I think that would involve upwind decisions self versus opposite for the integrals along the frontal faces and upwind decisions inside versus outside velocity lateral for the integrals along the lateral faces.
For the upwind decision self or opposite, it would be based on (self+opposite)/2. For a upwind decision inside versus outside, I could imagine basing the decision on self+parallel/2.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/724[Navier Stokes] Gravity upwinding2019-06-17T14:48:36ZMelanie Lipp[Navier Stokes] Gravity upwindingDo we want to use the upwind-density for both half-cells instead of the currently used density of the corresponding half-cell?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/723[Navier Stokes] Possibly revise initial condition of instationary channel test2019-06-06T09:12:56ZMelanie Lipp[Navier Stokes] Possibly revise initial condition of instationary channel testI would say that the initial conditions of an instationary test should such that the Navier-Stokes and continuity equation can be fulfilled. Currently, we start our channel test with a velocity profile u=1 at the left boundary, u=0 everywhere else. This means that for the cells on the very left the continuity equation can not be fulfilled. @nedc had the idea to start with u=1 everywhere besides at the top and bottom boundary where we have u=0. This would be in accordance with continuity.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/722(Not) modifying parameter tree during simulation2019-06-04T15:11:44ZTimo Kochtimo.koch@iws.uni-stuttgart.de(Not) modifying parameter tree during simulationI think in the design of the parameter tree, it was acutally desired that the tree shouldn't be modified after the initialization (but it can be initialized several times by overwriting previous initializaitons).
However currently it is technically possible to call init anywhere (globally) and modify the params which may lead to side effects in other classes.
It's technically possible to throw an error if the tree is modified by init after getParam has been called for the first time. However in some tests (some sequential tests and the fluid system test) this bug/feature is actually used/misused.
We should decide which way we want it and think about how to enforce it backwards-compatibly.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/719FVElementGeometry public alias FVGridGeometry is not generic enough2019-05-31T19:19:08ZTimo Kochtimo.koch@iws.uni-stuttgart.deFVElementGeometry public alias FVGridGeometry is not generic enoughFor compatibilty with FEM this alias should be called GridGeometry. In the FEElementGeoemtry this alias is actually still missing. This is needed to implement elementSolution/evalSolution for FEM.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/717SPE 10 as example2019-05-29T09:00:00ZTimo Kochtimo.koch@iws.uni-stuttgart.deSPE 10 as exampleThere is some code for the SPE10 https://git.iws.uni-stuttgart.de/dumux-appl/dumux-spe10 based on some old dumux version. It would be nice to update it to the new version and implement the five-spot SPE10.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/714Calculate time derivatives by product rule and total derivative for compressi...2019-06-07T08:04:00ZMelanie LippCalculate time derivatives by product rule and total derivative for compressible Navier-Stokes equationFor the one-component compressible Navier-Stokes equation in connection with the ideal gas law we might do the following changes:
Momentum balance:
```math
\frac{\partial \left(\varrho v\right)}{\partial t} = \frac{\partial \left(\varrho^{n_I-1} v\right)}{\partial t}
```
Mass balance:
```math
\frac{\partial \varrho }{\partial t} =
\frac{1}{RT}\frac{\partial p}{\partial t} + \frac{-p}{RT^2}\frac{\partial T}{\partial t}
```
Energy balance:
```math
\frac{\partial \left(\varrho u^e\right) }{\partial t} = \frac{\partial \left(\varrho^{n_I-1} u^e\right) }{\partial t}
```
with $`n_I-1`$: last iteration stepMelanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues/713Generalize implementation of Beavers-Joseph(-Saffmann) slip condition2019-05-28T14:00:33ZKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deGeneralize implementation of Beavers-Joseph(-Saffmann) slip conditionSo far ths BJS condition only considers $`du/dy`$. We should extend this to $`(du/dy`$ + $`dv/dx)`$3.1Kilian Weishauptkilian.weishaupt@iws.uni-stuttgart.deKilian Weishauptkilian.weishaupt@iws.uni-stuttgart.de