dumux merge requestshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests2018-01-18T14:39:10Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/742Make FVGridGeometry independent of TypeTag2018-01-18T14:39:10ZTimo Kochtimokoch@math.uio.noMake FVGridGeometry independent of TypeTag* [x] Make mapper types compatible with Dune 2.5* [x] Make mapper types compatible with Dune 2.53.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/740Make Newtoncontroller independent of TypeTag2018-01-18T11:14:06ZTimo Kochtimokoch@math.uio.noMake Newtoncontroller independent of TypeTagEnables to use a Newton method independent of the property system. Especially useful for multidomain problems with several sub problem typetags.Enables to use a Newton method independent of the property system. Especially useful for multidomain problems with several sub problem typetags.3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/738Feature/make linearsolver independent of typetag2018-05-30T08:46:11ZTimo Kochtimokoch@math.uio.noFeature/make linearsolver independent of typetagDepends on !737 to be merged.
Thanks to @DennisGlaeser for fixing some small bugs.Depends on !737 to be merged.
Thanks to @DennisGlaeser for fixing some small bugs.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/737Improve assembly more2018-05-30T08:46:11ZTimo Kochtimokoch@math.uio.noImprove assembly moreFixes some things forgotten before merging feature/improve-fvassembler-even-more.Fixes some things forgotten before merging feature/improve-fvassembler-even-more.3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/735[moduleutil] Copy files from last release2018-01-11T15:59:20ZThomas Fetzer[moduleutil] Copy files from last releaseEither something went wrong here or the cherry-pick was forgottenEither something went wrong here or the cherry-pick was forgotten3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/734Feature/improve fvassembler2018-01-17T18:38:48ZKilian WeishauptFeature/improve fvassembler__todo:__
- [x] implement for MPFA
- [x] treat TODOs
- [x] `fluxVarCache` for box
- [x] improve docu
- [x] test analytical cases
- [x] test explicit cases
- [x] test on network/surface grids
- [x] account for failing tests
- [x] fix `m...__todo:__
- [x] implement for MPFA
- [x] treat TODOs
- [x] `fluxVarCache` for box
- [x] improve docu
- [x] test analytical cases
- [x] test explicit cases
- [x] test on network/surface grids
- [x] account for failing tests
- [x] fix `mpnc` local residual3.0Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/725Fix/compiler errors and warnings clang2018-01-03T15:32:49ZTimo Kochtimokoch@math.uio.noFix/compiler errors and warnings clang3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/724[pointsources] Do not enable by default2018-01-04T08:24:03ZTimo Kochtimokoch@math.uio.no[pointsources] Do not enable by defaultThe point source computation in FVProblem uses the problem implementation to compute the point source map.
However it is executed in the constructor where the problem implemenation is not fully instatiated yet as it
derives from FVProble...The point source computation in FVProblem uses the problem implementation to compute the point source map.
However it is executed in the constructor where the problem implemenation is not fully instatiated yet as it
derives from FVProblem. This patch disables point source computation by default. If you want to specify point
sources you have to manually call problem->computePointSourceMap() now.3.0Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/723[sequential] remove all calls to the deprecated `*_PARAM*` macros2018-01-03T14:37:37ZBernd Flemisch[sequential] remove all calls to the deprecated `*_PARAM*` macrosReplace all calls of `*_PARAM*` macros by corresponding calls to
`getParam`. Remove the corresponding properties. If `getParam`
is called more than once for one parameter, specify a default value
in [`properties.hh`](dumux/porousmediu...Replace all calls of `*_PARAM*` macros by corresponding calls to
`getParam`. Remove the corresponding properties. If `getParam`
is called more than once for one parameter, specify a default value
in [`properties.hh`](dumux/porousmediumflow/sequential/properties.hh).
Otherwise, specify the default value in the call to `getParam`.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/720[doc] fix documentation in fluidsystems2018-01-16T15:15:10ZBernd Flemisch[doc] fix documentation in fluidsystemsManual cherry-pick of a part of 993d4801.Manual cherry-pick of a part of 993d4801.3.0Thomas FetzerThomas Fetzerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/719[cmake] Require CMake 3.1 similar to dune-common 2.62018-01-02T13:27:13ZChristoph Grüninger[cmake] Require CMake 3.1 similar to dune-common 2.6Otherwise it will lead to CMake warnings and might break code.Otherwise it will lead to CMake warnings and might break code.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/718[mpfa] Use numLocalScvf instead of constant2018-01-06T20:56:48ZChristoph Grüninger[mpfa] Use numLocalScvf instead of constant@DennisGlaeser this might impact performance? Maybe the function can be constexpr with dune 2.6?@DennisGlaeser this might impact performance? Maybe the function can be constexpr with dune 2.6?3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/498Correct computation of molar densities (fixes small mass balances errors)2018-07-04T11:41:20ZSimon EmmertCorrect computation of molar densities (fixes small mass balances errors)Closes #450
Depends !836
-name change is subject to further discussion (new Issue: #509)
* [x] Introduce liquidMolarDensity and gasMolarDensity for components
* [x] Use more meaningful functions in computation of the molar densi...Closes #450
Depends !836
-name change is subject to further discussion (new Issue: #509)
* [x] Introduce liquidMolarDensity and gasMolarDensity for components
* [x] Use more meaningful functions in computation of the molar density
* [x] in tutorial include liquidmolardensity in mycompressible component
* [x] introduce molardensity in new liquid and gas component
in component LNAPL include a liquidmolardensity -> opened Issue #464
**To summarize the changes:**
* introduced ``liquidMolarDensity()`` respectively ``gasMolarDensity()`` in all fluid components
* liquidMolarDensity as ``liquidDensity(temperature, pressure)/molarMass();``
* gasMolarDensity as ``IdealGas::molarDensity(temperature, pressure); ``
* exceptions are:
* brine: salinity is included in the liquidMolarDensity
* co2: is not considered an ideal gas, therefore ``gasDensity(temperature, pressure)/molarMass();`` is used
* h2o: gasMolarDensity uses IAPWS by ``gasDensity(temperature, pressure)/molarMass();``
* mesitylene: liquidMolarDensity was already implemented with a law from Reid et al. 1987 (see Doxygen)
* xylene: liquidMolarDensity was already implemented with a law from Reid et al. 1987 (see Doxygen)
* introduced ``molarDensity()`` in all fluidsystems
* for wPhaseIdx: ``MainComponent::liquidMolarDensity(temperature, pressure)``
* for a gas nPhaseIdx and !useComplexRelations: ``IdealGas::molarDensity(temperature, pressure)``
* for a gas nPhaseIdx and useComplexRelations: ``Component1::gasMolarDensity(temperature, pressure) + Component2::gasMolarDensity(temperature, pressure) + ... ``
* for a NAPL nPhaseIdx: ``NAPL::liquidMolarDensity(temperature, pressure);``
* exceptions are:
* co2: ``density(fluidState, phaseIdx)/fluidState.averageMolarMass(phaseIdx)``
* spe5: uses Peng-Robinson molarVolume calculation as before
* all general fluidstates have ``setMolarDensity()``, and the volVars set the densities in the fluidstate and get them directly from the fluidstate instead of calculating ``density()/averageMolarMass()``
* exceptions:
* tracer: uses ``fluidDensity_/fluidMolarMass_;``
3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/merge_requests/185Fix/gridcreator gmsh parameters2018-06-28T12:03:09ZTimo Kochtimokoch@math.uio.noFix/gridcreator gmsh parametersThis should be thoroughly tested.
I'm not sure yet if this works correct with ALUGrid. Does ALU support gmsh files?
For ALU the intersection.boundarySegmentIndex() doesn't seem to get the right parameter. For element params it works....This should be thoroughly tested.
I'm not sure yet if this works correct with ALUGrid. Does ALU support gmsh files?
For ALU the intersection.boundarySegmentIndex() doesn't seem to get the right parameter. For element params it works.
How parameters can be attached to a grid seems to be a mess and different for ALU and UG.
@bernd is it possible that gmsh params in parallel need manual load balancing as done for the dgf gridPtr params?
TODO
* [x] Find a measure of success for the parallel tests: as partitioning is not preserved across machines, simple parallel vtu comparison won't work.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.no