dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2017-12-04T09:50:54Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/600[WIP][components][plotproperties] Add a source file to plot properties of som...2017-12-04T09:50:54ZThomas Fetzer[WIP][components][plotproperties] Add a source file to plot properties of some componentsCan be extended for other components and properties before actually mergedCan be extended for other components and properties before actually mergedTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/633WIP: [math] use FieldVector and Matrix instead of DenseVector again2017-12-22T13:12:23ZSimon EmmertWIP: [math] use FieldVector and Matrix instead of DenseVector again[math] use FieldVector and Matrix instead of DenseVector in math to make tpfa-tests of 2pnc and 2pncmin compile again
* [ ] fix copy prohibiton or move back to previous version (would be very sad)[math] use FieldVector and Matrix instead of DenseVector in math to make tpfa-tests of 2pnc and 2pncmin compile again
* [ ] fix copy prohibiton or move back to previous version (would be very sad)Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/478WIP Feature/optimize tpfa2017-12-22T13:12:27ZTimo Kochtimokoch@math.uio.noWIP Feature/optimize tpfaabout 5% performance gain.
The scvf can be replaced by a class that caches corners and geometry type if that's really needed e.g. for non-linear Neumann boundaries in convergence tests.
* [ ] Consider scv/scvf classes with and without g...about 5% performance gain.
The scvf can be replaced by a class that caches corners and geometry type if that's really needed e.g. for non-linear Neumann boundaries in convergence tests.
* [ ] Consider scv/scvf classes with and without geometries (mostly unnecessary overhead)
* [x] replace boundaryInfo struct in bcTypes
* [ ] possibility to explicitly set NeumannNoFLow as boundary typeDennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/721Fix/rename fluidsystem file2018-01-02T10:56:34ZBernd FlemischFix/rename fluidsystem fileThomas FetzerThomas Fetzerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/760include dune-version checks for different GeometryTypes2018-01-29T11:52:14ZSimon Emmertinclude dune-version checks for different GeometryTypes(cherry picked from commit f261c74c6c902e4e301d532a801ea7a1276496a8)(cherry picked from commit f261c74c6c902e4e301d532a801ea7a1276496a8)3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/770WIP: Resolve "Rename Problem-TypeTags to end in "TypeTag""2018-01-31T16:57:15ZMelanie LippWIP: Resolve "Rename Problem-TypeTags to end in "TypeTag""Closes #413Closes #4133.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/772[geometryintersection] Add missing include2018-02-01T16:18:08ZKilian Weishaupt[geometryintersection] Add missing includefixed in !765fixed in !7653.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/739Feature/mpnc 2p2c comparison2018-02-05T12:23:16ZKatharina HeckFeature/mpnc 2p2c comparison3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/582[wip] Feature/box interface solver2018-02-14T14:55:44ZDennis Gläser[wip] Feature/box interface solverAn interface solver is necessary for a proper implementation of the box-dfm framework.An interface solver is necessary for a proper implementation of the box-dfm framework.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/409[WIP]Feature/add features in localresidual on next2018-02-18T21:34:45ZKilian Weishaupt[WIP]Feature/add features in localresidual on nextTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/852[constraintsolvers] do not use the deleted interface for singularity limit in...2018-03-14T18:21:08ZDennis Gläser[constraintsolvers] do not use the deleted interface for singularity limit in FMatrixPrecision3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/851Feature/rans2018-03-15T21:09:17ZThomas FetzerFeature/rans* [x] Calculate velocity gradients
* [x] Include Flow and WallNormalAxis
* [x] Update documentation
* [x] Cleanup
* [x] Add reference test for Laufer pipe* [x] Calculate velocity gradients
* [x] Include Flow and WallNormalAxis
* [x] Update documentation
* [x] Cleanup
* [x] Add reference test for Laufer pipe3.0Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/850Feature/model traits staggered2018-03-19T11:12:55ZKilian WeishauptFeature/model traits staggered3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/769[WIP] Feature/improve fuller2018-04-17T09:19:57ZKilian Weishaupt[WIP] Feature/improve fullerWhen executing the test, the "optimized" version (using `static` variables in the function
for values that are expensive to calculate, e.g. involving `std::cbrt`) is surprisingly slower
than the version without static variables (with c...When executing the test, the "optimized" version (using `static` variables in the function
for values that are expensive to calculate, e.g. involving `std::cbrt`) is surprisingly slower
than the version without static variables (with compiler optimizations).
Without compiler optimization, the opposite is true (which would be expected).
Making the variables `static constexpr` (and adapting the relevant methods involved), makes the "optimized" version
as fast as the other one.
How should we deal with this? Might be related to #441
Closes #3893.0Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/876WIP: TEMP [rans][lowrekepsilon] Implement first version of a low-Re k-epsilon...2018-04-17T14:21:24ZThomas FetzerWIP: TEMP [rans][lowrekepsilon] Implement first version of a low-Re k-epsilon model* [x] implement balance equations
* [x] implement proper laufer pipe test (inflow/boundary conditions)
* [ ] fix test
* [ ] improve averaging method?
* [ ] test non-isothermal model
* [ ] documentation (balance equations, todos, units)* [x] implement balance equations
* [x] implement proper laufer pipe test (inflow/boundary conditions)
* [ ] fix test
* [ ] improve averaging method?
* [ ] test non-isothermal model
* [ ] documentation (balance equations, todos, units)3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/451[WIP] [freeflow] Introduce extrusion factor2018-04-18T05:59:04ZKilian Weishaupt[WIP] [freeflow] Introduce extrusion factor* Account for extrusion factor everywhere face.area() or the cell volume
is involved* Account for extrusion factor everywhere face.area() or the cell volume
is involved3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/937Fix replaceCompEqIdx for freeflow2018-04-30T14:30:57ZSina AckermannFix replaceCompEqIdx for freeflowcloses #482closes #482Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/951WIP: Cleanup/rans and fluidsystem2018-05-04T11:27:40ZThomas FetzerWIP: Cleanup/rans and fluidsystemDepends on !949Depends on !9493.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/817WIP: Feature/solidsystem2018-05-08T13:16:41ZTimo Kochtimokoch@math.uio.noWIP: Feature/solidsystemPrototype for a solid system and a solid component, see #453.Prototype for a solid system and a solid component, see #453.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/736WIP: Feature/multidomain on 3.02018-05-30T08:48:21ZTimo Kochtimokoch@math.uio.noWIP: Feature/multidomain on 3.0This merge request adds a multidomain module to Dumux. It is a fairly generic module that provides a generic assembler for multi-domain problems (more than two domains possible). The domains can have different dimension. The coupling man...This merge request adds a multidomain module to Dumux. It is a fairly generic module that provides a generic assembler for multi-domain problems (more than two domains possible). The domains can have different dimension. The coupling manager concept allows to specify coupling dof dependencies and defines how to evaluate coupling residuals / residual derivatives.
The goal is to be able to use this module for
* equal-dimension multi-domain problems (e.g. Darcy-Stokes coupling)
* mixed-dimension multi-domain problems (e.g. embedded mixed-dimension methods, embedded fracture models)
* multi-physics problems (e.g. dual-continuum models)
TODO
* [x] depends on !737 and !738 to be merged.
* [x] check function overloads for different element types, probably need domainId as element types can be the same
* [ ] add coupling manager for darcy-darcy domain decomposition
* [ ] implement additional derivatives for caching disabled -> custom ElementVolVar type
* [ ] implement explicit assembly
* [x] Unify newtoncontroller with staggered newtoncontroller (depends on !762)
3.0