dumux issueshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues2018-12-20T16:11:08Zhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/635Proofread handbook2018-12-20T16:11:08ZTimo Kochtimokoch@math.uio.noProofread handbook* [x] Throw out/improve stuff that is not correct
* [x] Run spell-checker
* [x] Shorten gnuplot section and remove stuff that is not general* [x] Throw out/improve stuff that is not correct
* [x] Run spell-checker
* [x] Shorten gnuplot section and remove stuff that is not general3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/636Missing CMake guards in tests2018-12-18T20:08:07ZTimo Kochtimokoch@math.uio.noMissing CMake guards in testsSome freeflow tests have missing CMake guards for UMFPack.Some freeflow tests have missing CMake guards for UMFPack.3.0Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/637Issue with UMFPack and opm-grid2018-12-19T14:15:53ZTimo Kochtimokoch@math.uio.noIssue with UMFPack and opm-gridThere seems to be an issue that UMFPack is found (by CMake) but HAVE_UMFPACK (in C++ / config.h) is false when using opm.
The configure log actually says neither suitesparse nor superlu is found although it is installed on the system. op...There seems to be an issue that UMFPack is found (by CMake) but HAVE_UMFPACK (in C++ / config.h) is false when using opm.
The configure log actually says neither suitesparse nor superlu is found although it is installed on the system. opm seems to mess with something.3.0https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/638test_md_facet_1p1p_box_convergence fails with clang2018-12-19T15:30:47ZTimo Kochtimokoch@math.uio.notest_md_facet_1p1p_box_convergence fails with clang3.0Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/639Rename CakeGridCreator to CakeGridManager and SubgridGridCreator to SubGridMa...2019-03-03T19:16:43ZTimo Kochtimokoch@math.uio.noRename CakeGridCreator to CakeGridManager and SubgridGridCreator to SubGridManager3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/640A few tests fail without a direct solver present2018-12-20T16:10:15ZTimo Kochtimokoch@math.uio.noA few tests fail without a direct solver presentCould be the case that AMG uses a different smoother in that case. Can probably be made more stable by decreasing Newton tolerance. See buildbot's minimal build setups.Could be the case that AMG uses a different smoother in that case. Can probably be made more stable by decreasing Newton tolerance. See buildbot's minimal build setups.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/641test_2p_incompressible_tpfa_oilwet fails with clang 6.0.02019-02-27T14:39:32ZSimon Emmerttest_2p_incompressible_tpfa_oilwet fails with clang 6.0.0The tests fails for me when I build with clang 6.0.0 on Ubuntu
We should think of an improved test for the future
```
239: Data differs in parameter: S_aq
239: Difference is too large: 1.73% -> between: 0.259405 and 0.254914
239: Info f...The tests fails for me when I build with clang 6.0.0 on Ubuntu
We should think of an improved test for the future
```
239: Data differs in parameter: S_aq
239: Difference is too large: 1.73% -> between: 0.259405 and 0.254914
239: Info for S_aq: max_abs_parameter_value=1.0 and min_abs_parameter_value=0.226833.
239:
239: Data differs in parameter: S_napl
239: Difference is too large: 100.00% -> between: 9.99547e-06 and 0.0
239: Info for S_napl: max_abs_parameter_value=0.773167 and min_abs_parameter_value=0.0.
239:
239: Data differs in parameter: mob_aq
239: Difference is too large: 3.16% -> between: 114.914 and 111.283
239: Info for mob_aq: max_abs_parameter_value=1000.0 and min_abs_parameter_value=10.849.
239:
239: Data differs in parameter: mob_napl
239: Difference is too large: 99.50% -> between: 0.00189577 and 9.41958e-06
239: Info for mob_napl: max_abs_parameter_value=1157.57 and min_abs_parameter_value=0.0.
239:
239: Data differs in parameter: pc
239: Difference is too large: 99.55% -> between: 0.000934299 and 4.21307e-06
239: Info for pc: max_abs_parameter_value=2529.62 and min_abs_parameter_value=0.0.
1/1 Test #239: test_2p_incompressible_tpfa_oilwet ...***Failed 1.63 sec
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/642High residuals in poromechanics test el1p/el2p2019-01-02T14:52:45ZTimo Kochtimokoch@math.uio.noHigh residuals in poromechanics test el1p/el2p3.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/643Turbulent diffusion in shallow water equations: DuMux-SWE2019-02-07T13:04:43ZFrank PlatzekTurbulent diffusion in shallow water equations: DuMux-SWEAdd diffusion terms to the shallow water equations
(in DuMux-SWE).
One or more turbulence models will follow later.
For now a rudimentary implementation is chosen which is only accurate on orthogonal grids.
Possible non-orthogonal correc...Add diffusion terms to the shallow water equations
(in DuMux-SWE).
One or more turbulence models will follow later.
For now a rudimentary implementation is chosen which is only accurate on orthogonal grids.
Possible non-orthogonal corrections will be added later on.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/644Quy mô Vincity Tây Mỗ Đại Mỗ và thông tin tổng quan về dự án2018-12-27T03:46:03ZThanh HuyenQuy mô Vincity Tây Mỗ Đại Mỗ và thông tin tổng quan về dự án*Vincity Tây Mỗ Đại Mỗ là tổ hợp dự án chung cư, biệt thự với chuỗi tiện ích được đầu tư đồng bộ và hệ sinh thái ấn tượng, dự án được ví như một thành phố hiện đại thu nhỏ. Quy mô Vincity Tây Mỗ Đại Mỗ được quy hoạch trên khu đất rộng 28...*Vincity Tây Mỗ Đại Mỗ là tổ hợp dự án chung cư, biệt thự với chuỗi tiện ích được đầu tư đồng bộ và hệ sinh thái ấn tượng, dự án được ví như một thành phố hiện đại thu nhỏ. Quy mô Vincity Tây Mỗ Đại Mỗ được quy hoạch trên khu đất rộng 280 ha với hệ thống cơ sở hạ tầng giao thông được đầu tư đồng bộ, mật độ xây dựng chỉ 14.7% hứa hẹn mang đến không gian sống tuyệt vời dành cho khách hàng trong tương lai. Tìm hiểu thêm thông tin trong bài viết sau:*
![image](https://i.imgur.com/3tqn6Gw.jpg?1)
=> [Xem thêm](https://www.instapaper.com/p/vincitytaydaimo)
**Quy mô Vincity Tây Mỗ Đại Mỗ khu nhà ở**
Vincity Tây Mỗ Đại Mỗ được quy hoạch trên khu đất rộng 280 ha thuộc địa phận 2 phường Tây Mỗ và Đại Mỗ, quận Nam Từ Liêm, Hà Nội. Theo bản đồ quy hoạch tỷ lệ 1/500 dự kiến, mật động xây dựng chỉ khoảng 14.7% trên tổng diện tích. Khu nhà ở được triển khai 2 loại hình sản phẩm chính đó là: Biệt thự (Bao gồm: Biệt thự song lập, biệt thự đơn lập, nhà ở liền kề, nhà phố thương mại) và căn hộ chung cư. Cùng với đó là chuỗi tiện ích dịch vụ được đầu tư đồng bộ, một số tiện ích dịch vụ nổi bật có thể kể đến như: Hệ thống Siêu thị và các cửa hàng tiện ích Vinmart+, hệ thống bệnh viện Vinmec, hệ thống trường học Vinschool, tiện ích thể thao…
Quy mô Vincity Tây Mỗ Đại Mỗ khu nhà ở theo kế hoạch dự kiến, sẽ được triển khai như sau:
+ Phân khu cao tầng: Tại khu đô thị có 58 tòa nhà chung cư được triển khai xây dựng, các tòa nhà chung cư có chiều cao trung bình từ 33 – 38 tầng, mỗi tầng sẽ có khoảng 18 – 22 căn hộ và mỗi căn hộ sẽ được thiết kế với diện tích từ 25 – 90 m2 tương ứng với loại căn hộ Studio, 1 phòng ngủ, 2 phòng ngủ và 3 phòng ngủ. Bên cạnh sản phẩm thì hệ thống cảnh quan cũng được chú trọng, công viên cây xanh, vươn hoa… sẽ được thiết kế xen kẽ giữa các phân khu với khoảng cách phù hợp hứa hẹn sẽ mang lại không gian sống xanh, thoáng đãng, thư giãn dành cho cư dân.
+ Phân khu thấp tầng: Trong phân khu thấp tầng của khu đô thị Vincity Tây Mỗ Đại Mỗ sẽ được chia thành các dòng sản phẩm như: biệt thự đơn lập, biệt thự song lập, nhà ở liền kề và nhà phố thương mại với thiết kế hiện đại, độc đáo mang đến những nét đặc trưng riêng của từng phân khu.
=> Xem thêm: [khudothivincitytaymodaimo.com](https://vi-vn.facebook.com/khudothivincitytaymodaimo/)
**Quy mô Vincity Tây Mỗ Đại Mỗ hệ sinh thái**
Vincity Tây Mỗ Đại Mỗ được triển khai xây dựng thành khu đô thị kiểu mẫu đa chức năng, chủ đầu tư không chỉ chú trọng tới chất lượng sản phẩm mà còn đặc biệt chú ý tới hệ sinh thái. Mang lại không gian sống lý tưởng cũng chính là mục tiêu của tập đoàn Vingroup tại các khu đô thị Vincity tại khu vực ngoại thành Hà Nội.
Với mật độ xây dựng chỉ khoảng 14.7%, phần lớn diện tích trong khu đô thị được dùng để triển khai hệ thống sinh thái, bao gồm: công viên, cây xanh, vườn hoa, hồ nước,… cùng với đó là hệ thống công viên thể thao lớn nhất Việt Nam và đứng đầu Đông Nam Á về quy mô; hứa hẹn sẽ mang đến cho cư dân một không gian sống xanh, tuyệt vời nhất trong khu vực.
Đặc biệt, trong hệ thống công viên thể thao khu đô thị Vincity Tây Mỗ Đại Mỗ còn được trang bị thêm hàng ngàn máy tập ngoài trời, 3 công viên BBQ với hàng trăm điểm nướng, sân cỏ dưỡng sinh… đáp ứng tối đa nhu cầu rèn luyện, nâng cao sức khỏe và vui chơi giải trí của cư dân tương lai khu đô thị.
Với mật độ xây dựng chỉ chiếm 14.7%, phần lớn diện tích được dùng để triển khai hệ sinh thái, hứa hẹn mang đến một không gian xanh, môi trường sống tuyệt vời nhất dành cho cư dân tương lai trong khu đô thị Vincity Tây Mỗ Đại Mỗ. Thông tin về tiến độ và lịch mở bán sẽ được chúng tôi cập nhật ngay sau khi nhận được thông tin chính thức từ chủ đầu tư, mời khách hàng chú ý theo dõi.
=> Xem thêm: [vincity sportia tây mỗ đại mỗ](https://khudothivincitytaymodaimo.wordpress.com/)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/645Difficulty in running the exercises2019-01-02T14:39:46Ztsinober@gmail.comDifficulty in running the exercisesHi there
I'm having some trouble in running the exercises located within the course folder.
I've carefully followed the installation procedure, making sure I've got all the compatible versions specified in the installation README file....Hi there
I'm having some trouble in running the exercises located within the course folder.
I've carefully followed the installation procedure, making sure I've got all the compatible versions specified in the installation README file. The test seemed to ran successfully. For some reason when trying to compile exercise_basic_2p2c
i get the following error: fatal error: dumux/nonlinear/privarswitchnewtonsolver.hh: No such file or directory
#include <dumux/nonlinear/privarswitchnewtonsolver.hh>
I don't have much background in linux and C++ so any ideas/help will be much appreciated
Thanks!https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/646Tests: Replace problem functions postTimeStep/preTimeStep2019-02-27T13:52:59ZTimo Kochtimokoch@math.uio.noTests: Replace problem functions postTimeStep/preTimeStepFunctions with such names are due to the version 2 way of implementing simulation flow control. In version 3 such functions should not exist because
* the function name doesn't say anything about what the function does
* the functionali...Functions with such names are due to the version 2 way of implementing simulation flow control. In version 3 such functions should not exist because
* the function name doesn't say anything about what the function does
* the functionality in those functions probably doesn't belong in the problem
The function might be removed by moving the functionality into the main file, or renamed to some appropriate name if the functionality really belongs to the problem (connected to BC/IC/Sources or maybe an analytical solution).3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/647Remove deprecated IOFields::init functions2019-02-28T15:43:43ZTimo Kochtimokoch@math.uio.noRemove deprecated IOFields::init functionshttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/648Put property definitions in tests (examples/applications) in separate header2020-04-09T17:49:48ZTimo Kochtimokoch@math.uio.noPut property definitions in tests (examples/applications) in separate headerTo make another step away from the problem-does-everything-mentality that was common (and a necessary evil) in dumux 2,
I suggest to put the property definitions into a separate header. There are not connected in any way to the `Problem`...To make another step away from the problem-does-everything-mentality that was common (and a necessary evil) in dumux 2,
I suggest to put the property definitions into a separate header. There are not connected in any way to the `Problem` class, so IMO they shouldn't be defined in the problem header. For the purpose of re-usability they also shouldn't be directly coded in the main file.
__Edit: Result from the vote__: We want to advertise putting properties in a separate header.
* [x] Separate properties into `properties.hh` for the examples (milestone 3.2) !1933
* [x] Separate properties into `properties.hh` for the dumux-course (milestone 3.2) [course#24](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-course/issues/24)
* [ ] Separate properties into `properties.hh` for the dumux-lecture (milestone 3.3) [lecture#15](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux-lecture/issues/15)
* [ ] Separate properties into `properties.hh` for the tests (milestone 3.3)
This doesn't have to be in one go. If someone edits a test anyway feel free to do this change as well.3.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/649[Freeflow][test][angeli] No convergence against analytical solution for first...2021-05-19T08:55:29ZMelanie Lipp[Freeflow][test][angeli] No convergence against analytical solution for first time stepThe solution does not properly converge for the first time step. The pressure solution is really weird for very small time steps (as the 10^(-12) that is currently used). It becomes less and less weird the larger the first time step is t...The solution does not properly converge for the first time step. The pressure solution is really weird for very small time steps (as the 10^(-12) that is currently used). It becomes less and less weird the larger the first time step is taken. But even for an initial time step of e.g. 10^(-2) the solution is an unsymmetrical version of what it is supposed to be.
It is clear that the solution has the chance to recover for later time steps as the pressure solution at previous time steps does, in contrary to the velocity solution, not play a role for the current solution.
__edit__: The problem also persists on the new staggered implementation: !25713.4https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/650[freeflow][rans] update gridvariables in main file necessary for all rans tests2019-02-07T07:13:02ZKatharina Heck[freeflow][rans] update gridvariables in main file necessary for all rans testsWhen gridvolumevariables caching is switched on it is necessary to update the gridvariables again in the main file of the tests after the dynamic wall properties are updated in each time.
This can be done with
`// update wall propert...When gridvolumevariables caching is switched on it is necessary to update the gridvariables again in the main file of the tests after the dynamic wall properties are updated in each time.
This can be done with
`// update wall properties`
`problem->updateDynamicWallProperties(sol);`
`assembler->updateGridVariables(sol);`
There might be also be a better solution for this problem but this was the first fix @kweis found. I did not test yet if that changes any reference solutions for the rans problems but it changed a lot in a coupled test we look at.
@nedc This is the fix for the problem we had before christmas in the coupled komega test.3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/651Add VTK functionality to grid manager2019-03-28T08:49:55ZTimo Kochtimokoch@math.uio.noAdd VTK functionality to grid managerTimo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/652Provide interface for more parallel solvers/preconditioners of ISTL2020-03-13T15:11:22ZLeopold 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 sh...So 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/653Unefficient call for parameter in each flux evaluation2019-01-15T10:24:42ZSamuel Burbullasamuel.burbulla@mathematik.uni-stuttgart.deUnefficient call for parameter in each flux evaluationI think the call
`static const bool enableGravity = getParamFromGroup<bool>(problem.paramGroup(), "Problem.EnableGravity");`
in e.g. flux/cctpfa/darcyslaw.hh:162
executed during each flux evaluation is a performance drawback.
May one wan...I think the call
`static const bool enableGravity = getParamFromGroup<bool>(problem.paramGroup(), "Problem.EnableGravity");`
in e.g. flux/cctpfa/darcyslaw.hh:162
executed during each flux evaluation is a performance drawback.
May one wants to cache the parameter somewhere, but this is not straightforward since the function is static.
![parameterProfile](/uploads/ac1ba4bec5672ffc96fb6628b4cb35c2/parameterProfile.png)https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/654Allow C++172020-01-29T13:09:44ZTimo Kochtimokoch@math.uio.noAllow 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_supp...I 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?3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/655Newton uninitialized value for residual criterion2019-02-25T10:31:33ZTimo Kochtimokoch@math.uio.noNewton uninitialized value for residual criterionThe following settings
```ini
[Newton]
EnableResidualCriterion = true
EnableAbsoluteResidualCriterion = true
SatisfyResidualAndShiftCriterion = true
MaxAbsoluteResidual = 1e-25
```
give an error with valgrind for an uninitialized value i...The following settings
```ini
[Newton]
EnableResidualCriterion = true
EnableAbsoluteResidualCriterion = true
SatisfyResidualAndShiftCriterion = true
MaxAbsoluteResidual = 1e-25
```
give an error with valgrind for an uninitialized value in newtonsolver.hh:521.
Might be `residualNorm_` ...
Needs investigation.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/656XDMF/HDF5 Support in DuMux2019-02-01T09:38:21ZLeopold StadlerXDMF/HDF5 Support in DuMuxWe actually use XDMF/HD5F for input/output of our simulations. There are two files in the swe branch which allow to read and write triangular grids. There are many advantages compared to the vtk-format but also some drawbacks (installing...We actually use XDMF/HD5F for input/output of our simulations. There are two files in the swe branch which allow to read and write triangular grids. There are many advantages compared to the vtk-format but also some drawbacks (installing parallel hdf5, filesystems,...).
Is there any interest from the DuMux side to include XDMF/HDF5 support directly in DuMux?
I suggest to remove the files and ask the dune core developers if they are interested to create a new dune-module for xdmf/hdf5 support. I'm also not sure if there is a simple python way which might simplify the whole thing (parallel reading/writing of XDMF/HDF5 with h5py and mpi4py).https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/657Turbulent diffusion in shallow water equations2021-06-07T12:47:16ZFrank PlatzekTurbulent diffusion in shallow water equationsAdd diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be a...Add diffusion terms to the shallow water equations. One or more turbulence models will follow later. For now a rudimentary implementation is chosen which is only accurate on orthogonal grids. Possible non-orthogonal corrections will be added later on.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/658[2pncmin] precipitation of NaCl from the gas phase2019-03-27T15:43:22ZTheresa Schollenberger[2pncmin] precipitation of NaCl from the gas phaseA value is set for the source term of precipitated salt in gas, which is not physical. The suggestion is that this should balance out a fugacity of NaCl which was original nonequal to zero. However, the fugacity of NaCl was set to zero i...A value is set for the source term of precipitated salt in gas, which is not physical. The suggestion is that this should balance out a fugacity of NaCl which was original nonequal to zero. However, the fugacity of NaCl was set to zero in commit:9925d2d3 so this part of the source term has to be removed now.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/659Why does newtonProceed require two steps minimum?2019-05-29T13:22:23ZTimo Kochtimokoch@math.uio.noWhy does newtonProceed require two steps minimum?3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/660Pass FluxVarsCache to Neumann Function2019-08-30T15:17:00ZDennis 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.We 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.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/661Possibly include update of Box flux variables cache2023-03-18T18:38:31ZDennis 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.The 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.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/662Wrong use of extrusion factors (freeflow)2019-02-27T09:56:07ZKilian WeishauptWrong use of extrusion factors (freeflow)At certain points, the use of the extrusion factor is implemented wrong:
* fluxoversurface.hh lacks the factor for the calculation of the volume fluxes
* stokesdarcy/couplingdata.hh includes the factor in the calculation of diffusive fl...At certain points, the use of the extrusion factor is implemented wrong:
* fluxoversurface.hh lacks the factor for the calculation of the volume fluxes
* stokesdarcy/couplingdata.hh includes the factor in the calculation of diffusive fluxes, however, those values
are then applied as Neuman-BCs where the factor is again applied
__TODO__ @heck What about the Maxwell-Stefan fluxes in the coupling data?3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/663Staggered higher order memory2019-03-12T09:45:45ZTimo Kochtimokoch@math.uio.noStaggered higher order memoryIt should be investigated if the higher order implementation should be chosen at compile time so we can save memory and runtime.It should be investigated if the higher order implementation should be chosen at compile time so we can save memory and runtime.Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/664Staggered higher order bug in face solution2019-03-12T09:45:21ZTimo Kochtimokoch@math.uio.noStaggered higher order bug in face solutionThe following assertion fails for all freeflow tests after merging !1481:
`/data/src/dumux/dumux/discretization/staggered/facesolution.hh:68: const Dumux::StaggeredFaceSolution::FacePrimaryVariables &Dumux::StaggeredFaceSolution, std::a...The following assertion fails for all freeflow tests after merging !1481:
`/data/src/dumux/dumux/discretization/staggered/facesolution.hh:68: const Dumux::StaggeredFaceSolution::FacePrimaryVariables &Dumux::StaggeredFaceSolution, std::allocator > > >::operator[](IndexType) const [FaceSolutionVector = Dune::BlockVector, std::allocator > >, IndexType = int]: Assertion `pos != map_.end()' failed.`3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/665Compiler warning unused capture (flux over surface)2019-03-05T08:55:29ZTimo Kochtimokoch@math.uio.noCompiler warning unused capture (flux over surface)```
In file included from /data/src/dumux/test/freeflow/navierstokes/channel/2d/main.cc:42:
/data/src/dumux/dumux/freeflow/navierstokes/staggered/fluxoversurface.hh:245:26: warning: lambda capture 'this' is not used [-Wunused-lambda-capt...```
In file included from /data/src/dumux/test/freeflow/navierstokes/channel/2d/main.cc:42:
/data/src/dumux/dumux/freeflow/navierstokes/staggered/fluxoversurface.hh:245:26: warning: lambda capture 'this' is not used [-Wunused-lambda-capture]
auto fluxType = [this](const auto& element,
^
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/666Compiler error triggered by merge !1504 in nonequilibrium model2019-02-28T15:49:58ZTimo Kochtimokoch@math.uio.noCompiler error triggered by merge !1504 in nonequilibrium model```
/data/src/dumux/dumux/discretization/cellcentered/tpfa/elementfluxvariablescache.hh:181:20: error: no matching member function for call to 'fill'
filler.fill(*this, fluxVarsCache_[localScvfIdx], element, fvGeometry, elemV...```
/data/src/dumux/dumux/discretization/cellcentered/tpfa/elementfluxvariablescache.hh:181:20: error: no matching member function for call to 'fill'
filler.fill(*this, fluxVarsCache_[localScvfIdx], element, fvGeometry, elemVolVars, scvf, true);
~~~~~~~^~~~
/data/src/dumux/dumux/porousmediumflow/nonequilibrium/gridvariables.hh:105:31: note: in instantiation of function template specialization 'Dumux::CCTpfaElementFluxVariablesCache<Dumux::CCTpfaGridFluxVariablesCache<Dumux::OnePTwoCThermalNonequilibriumProblem<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa>, Dumux::PorousMediumFluxVariablesCacheImplementation<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa, Dumux::DiscretizationMethod::cctpfa>, Dumux::CCTpfaFluxVariablesCacheFiller<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa>, false, Dumux::CCTpfaDefaultGridFVCTraits<Dumux::OnePTwoCThermalNonequilibriumProblem<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa>, Dumux::PorousMediumFluxVariablesCacheImplementation<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa, Dumux::DiscretizationMethod::cctpfa>, Dumux::CCTpfaFluxVariablesCacheFiller<Dumux::Properties::TTag::OnePTwoCThermalNonequilibriumCCTpfa> > >, false>::bind<Dumux::CCTpfaFVElementGeometry<Dumux::CCTpfaFVGridGeometry<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2> > > >, false, Dumux::CCTpfaDefaultGridGeometryTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2> > > >, Dumux::DefaultMapperTraits<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2> > > >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2> > > >, Impl::MCMGFailLayout>, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::DefaultLeafGridViewTraits<const Dune::YaspGrid<2, Dune::EquidistantCoordinates<double, 2> > > >, Impl::MCMGFailLayout> > > >, false>, Dune::BlockVector<Dune::FieldVector<double, 4>, std::allocator<Dune::FieldVector<double, 4> > > >' requested here
elemFluxVarsCache.bind(element, fvGeometry, curSol);
^
```3.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/667Failing tests due to !15072019-02-28T15:14:00ZTimo Kochtimokoch@math.uio.noFailing tests due to !1507The MR !1507 changed the input file which is used for several tests but only adjusts one reference solution. The parameter should be instead just adjusted in the CMakelists for that specific test.The MR !1507 changed the input file which is used for several tests but only adjusts one reference solution. The parameter should be instead just adjusted in the CMakelists for that specific test.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/668Add brief description of staggered higher order feature to changelog2019-04-30T13:28:20ZTimo Kochtimokoch@math.uio.noAdd brief description of staggered higher order feature to changelogprobably after #663 #664 have been addressedprobably after #663 #664 have been addressed3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/669CMake error in handbook VERSION_GREATER_EQUAL2019-03-01T12:49:09ZLeopold StadlerCMake error in handbook VERSION_GREATER_EQUALI'm not sure if it is a bug. If I download the dune core modules via the script from the dumux-homepage
```
for MOD in common geometry grid localfunctions istl; do
git clone -b releases/2.6 https://gitlab.dune-project.org/core/dune-$MOD...I'm not sure if it is a bug. If I download the dune core modules via the script from the dumux-homepage
```
for MOD in common geometry grid localfunctions istl; do
git clone -b releases/2.6 https://gitlab.dune-project.org/core/dune-$MOD.git;
done
```
the modules (dune.module) have the version **2.6-git** and not **2.6**
I first thought that this causes the error when building DuMux since the handbook checks for **2.6** without **-git**
> CMake Error at doc/handbook/CMakeLists.txt:1 (if):
> if given arguments:
>
> "2.6-git" "VERSION_GREATER_EQUAL" "2.7"
>
> Unknown arguments specified
However a simple version renaming to "2.6" (dune.module in all core-modules) does not solve the problem.
> CMake Error at doc/handbook/CMakeLists.txt:1 (if):
> if given arguments:
>
> "2.6" "VERSION_GREATER_EQUAL" "2.7"
>
> Unknown arguments specified
Anyone has the same problems? I use cmake/3.6.13.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/670[md][stokesdarcy] Upwinding of component enthalpy is probably wrong2019-10-02T15:21:04ZKilian Weishaupt[md][stokesdarcy] Upwinding of component enthalpy is probably wrong```c++
const bool insideDiffFluxIsUpstream = std::signbit(diffusiveFlux[domainICompIdx]);
```
should probably be
```c++
const bool insideDiffFluxIsUpstream = diffusiveFlux[domainICompIdx] > 0.0;
```
* [ ] Furthermore, we should check...```c++
const bool insideDiffFluxIsUpstream = std::signbit(diffusiveFlux[domainICompIdx]);
```
should probably be
```c++
const bool insideDiffFluxIsUpstream = diffusiveFlux[domainICompIdx] > 0.0;
```
* [ ] Furthermore, we should check if all fluidsystems implement `componentEnthalpy`.3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/671shallowwater model for 3.02019-05-02T00:47:59ZLeopold Stadlershallowwater model for 3.0Implementation of the shallowwater model
* [ ] Add entry to changelog
* [ ] Document new functions, classes, model equationsImplementation of the shallowwater model
* [ ] Add entry to changelog
* [ ] Document new functions, classes, model equationsLeopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/672Missing bind in facet mpfa tests?2019-03-14T23:54:13ZTimo Kochtimokoch@math.uio.noMissing bind in facet mpfa tests?```
Initializing of the grid finite volume geometry took 0.052823 seconds.
Initializing of the grid interaction volume index sets took 0.0133807 seconds.
Initializing of the connectivity map took 0.0622879 seconds.
Writing output for...```
Initializing of the grid finite volume geometry took 0.052823 seconds.
Initializing of the grid interaction volume index sets took 0.0133807 seconds.
Initializing of the connectivity map took 0.0622879 seconds.
Writing output for problem "test_md_facet_1p1p_linearprofile_surface_xi066_mpfa_bulk". Took 0.108932 seconds.
Writing output for problem "test_md_facet_1p1p_linearprofile_surface_xi066_mpfa_lowdim". Took 0.000643468 seconds.
Instantiated assembler for a stationary problem.
Assemble: r(x^k) = dS/dt + div F - q; M = grad rtest_md_facet_1p1p_linearprofile_surface_mpfa: /data/src/dumux/dumux/discretization/cellcentered/tpfa/fvelementgeometry.hh:536: const LocalIndexType Dumux::CCTpfaFVElementGeometry::findLocalIndex(Dumux::CCTpfaFVElementGeometry::GridIndexType, const std::vector::GridIndex>&) const [with GG = Dumux::CCTpfaFVGridGeometry > >, false, Dumux::CCTpfaDefaultGridGeometryTraits > >, Dumux::DefaultMapperTraits > >, Dune::MultipleCodimMultipleGeomTypeMapper > >, Dune::Impl::MCMGFailLayout>, Dune::MultipleCodimMultipleGeomTypeMapper > >, Dune::Impl::MCMGFailLayout> > > >; Dumux::CCTpfaFVElementGeometry::LocalIndexType = unsigned int; Dumux::CCTpfaFVElementGeometry::GridIndexType = unsigned int; typename Dumux::IndexTraits::GridIndex = unsigned int]: Assertion `it != indices.end() && "Could not find the scv/scvf! Make sure to properly bind this class!"' failed.
```3.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/673Tracer box facet multidomain test fails. Make more robust2019-03-21T13:18:47ZTimo Kochtimokoch@math.uio.noTracer box facet multidomain test fails. Make more robust```
Fuzzy comparison...
Comparing /data/src/dumux/test/references/test_md_facet_tracertracer_box_tracer_bulk-reference.vtu and /data/build/dumux/test/multidomain/facet/tracer_tracer/test_md_facet_tracertracer_box_tracer_bulk-00010.vtu
...```
Fuzzy comparison...
Comparing /data/src/dumux/test/references/test_md_facet_tracertracer_box_tracer_bulk-reference.vtu and /data/build/dumux/test/multidomain/facet/tracer_tracer/test_md_facet_tracertracer_box_tracer_bulk-00010.vtu
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Data differs in parameter: X^tracer_0
Difference is too large: 103.05% -> between: 6.35046e-09 and -1.93402e-10
Info for X^tracer_0: max_abs_parameter_value=0.00357894 and min_abs_parameter_value=0.0.
Data differs in parameter: x^tracer_0
Difference is too large: 103.05% -> between: 3.81028e-07 and -1.16041e-08
Info for x^tracer_0: max_abs_parameter_value=0.214736 and min_abs_parameter_value=0.0.
Fuzzy comparison...
Comparing /data/src/dumux/test/references/test_md_facet_tracertracer_box_tracer_lowdim-reference.vtp and /data/build/dumux/test/multidomain/facet/tracer_tracer/test_md_facet_tracertracer_box_tracer_lowdim-00010.vtp
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Data differs in parameter: X^tracer_0
Difference is too large: 125.11% -> between: 1.44095e-07 and -5.73891e-07
Info for X^tracer_0: max_abs_parameter_value=0.000397662 and min_abs_parameter_value=0.0.
Data differs in parameter: x^tracer_0
Difference is too large: 125.11% -> between: 8.64572e-06 and -3.44334e-05
Info for x^tracer_0: max_abs_parameter_value=0.0238597 and min_abs_parameter_value=0.0.
Test #58: test_md_facet_tracertracer_box .............................***Failed 10.39 sec
```3.1Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/674Test make geometry fails sporadically2019-10-02T14:58:43ZTimo Kochtimokoch@math.uio.noTest make geometry fails sporadicallyFrom time to time the make geometry tests fails. It does so only sporadically, so there seems to be some random component.
```
testing for non axis-aligned quadrilateral
testing for quadrilateral with normal in z direction
testing for...From time to time the make geometry tests fails. It does so only sporadically, so there seems to be some random component.
```
testing for non axis-aligned quadrilateral
testing for quadrilateral with normal in z direction
testing for quadrilateral with normal in y direction
testing for quadrilateral with normal in x direction
Dune::InvalidStateException [permutatePointsAndTest:/data/src/dumux/test/common/geometry/test_makegeometry.cc:69]: Area of quadrilateral after permuation of input points is wrong
Test #9: test_makegeometry ................***Failed 0.23 sec
```3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/675[freeflow] Remove property NormalizePressure2020-08-26T08:00:48ZKilian Weishaupt[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 val...When 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.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/676[components] TabulatedComponent cannot be used for all components (e.g., air)2019-12-20T12:43:31ZKilian Weishaupt[components] TabulatedComponent cannot be used for all components (e.g., air)Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could b...Some components are lacking `vaporPressure()`, thus they cannot be compiled with a tabulation.
We could rethink this and only do the tabulation if the raw component acutally implements `vaporPressure()`, otherwise a runtime error could be thrown.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/678[parallel/amg] Some parallel or amg tests fail with dune master2019-06-25T12:30:48ZTimo Kochtimokoch@math.uio.no[parallel/amg] Some parallel or amg tests fail with dune masterSame tests pass with dune 2.6Same tests pass with dune 2.6https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/679Extend the timeLoop abtract base class2019-04-03T05:17:43ZKilian WeishauptExtend the timeLoop abtract base class* add virtual interface `setTimeStepSize()`
* accept type `TimeLoopBase` in `NewtonSolver` instead of template argument (improves type safety)
as discussed in !1529* add virtual interface `setTimeStepSize()`
* accept type `TimeLoopBase` in `NewtonSolver` instead of template argument (improves type safety)
as discussed in !15293.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/680Flexible factor for retry time step in Newton-Raphson method2019-03-27T18:13:36ZLeopold StadlerFlexible factor for retry time step in Newton-Raphson methodThe standard Newton-Raphson method uses a fixed factor to reduce the time step size if the non-linear solver has not converged (dt = dt/2). For problems with large time step sizes a much lower reduction is enough. Introducing an RetryTim...The standard Newton-Raphson method uses a fixed factor to reduce the time step size if the non-linear solver has not converged (dt = dt/2). For problems with large time step sizes a much lower reduction is enough. Introducing an RetryTimeStepReductionFactor will overcome this problem (dt = dt * RetryTimeStepReductionFactor).Leopold StadlerLeopold Stadlerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/681Segfault from grid geometry for UGGrid/YaspGrid parallel2019-05-04T22:35:53ZTimo Kochtimokoch@math.uio.noSegfault from grid geometry for UGGrid/YaspGrid parallelRunning `test_richards_lens_tpfa_parallel_ug` or `test_richards_lens_tpfa` with valgrind on two cores produces
```
Assemble: r(x^k) = dS/dt + div F - q; M = grad r==24935== Invalid read of size 4
==24935== at 0x6605C1: Dumux::CCTpfa...Running `test_richards_lens_tpfa_parallel_ug` or `test_richards_lens_tpfa` with valgrind on two cores produces
```
Assemble: r(x^k) = dS/dt + div F - q; M = grad r==24935== Invalid read of size 4
==24935== at 0x6605C1: Dumux::CCTpfaFVElementGeometry<Dumux::CCTpfaFVGridGeometry<Dune::GridView<Dune::UGGridLeafGridViewTraits<Dune::UGGrid<2> const> >, false, Dumux::CCTpfaDefaultGridGeometryTraits<Dune::GridView<Dune::UGGridLeafGridViewTraits<Dune::UGGrid<2> const> >, Dumux::DefaultMapperTraits<Dune::GridView<Dune::UGGridLeafGridViewTraits<Dune::UGGrid<2> const> >, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::UGGridLeafGridViewTraits<Dune::UGGrid<2> const> >, Dune::Impl::MCMGFailLayout>, Dune::MultipleCodimMultipleGeomTypeMapper<Dune::GridView<Dune::UGGridLeafGridViewTraits<Dune::UGGrid<2> const> >, Dune::Impl::MCMGFailLayout> > > >, false>::makeNeighborGeometries(Dune::Entity<0, 2, Dune::UGGrid<2> const, Dune::UGGridEntity> const&, unsigned int) (fvelementgeometry.hh:472)
```3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/682Test tabulation doesn't actually test anything2019-12-20T12:43:35ZTimo Kochtimokoch@math.uio.noTest tabulation doesn't actually test anythingNo matter if success is false or true the test always returns 0 exit code.No matter if success is false or true the test always returns 0 exit code.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/683prism grid assertion fails for test_1p_pointsources_timeindependent_box_prism...2019-03-29T08:39:25ZSimon Emmertprism grid assertion fails for test_1p_pointsources_timeindependent_box_prism or tpfaThe tests `test_1p_pointsources_timeindependent_box_prism` `test_1p_pointsources_timeindependent_tpfa_prism`fail on buildbot because `dune-common/dune/common/fvector.hh:130` has the assertion:
```
assert(l.size() == dimension);// Actuall...The tests `test_1p_pointsources_timeindependent_box_prism` `test_1p_pointsources_timeindependent_tpfa_prism`fail on buildbot because `dune-common/dune/common/fvector.hh:130` has the assertion:
```
assert(l.size() == dimension);// Actually, this is not needed any more!
```
The comment already states that this is not needed, but when looking at the l.size it actually is 2 in the beginning and then 3.
```
3: Reading parameters from file params.input.
3: lsize2
3: dimension3
3: Computed bounding box tree with 9679 nodes for 4840 grid entites in 0.00245224 seconds.
3: lsize3
3: dimension3
3: lsize3
3: dimension3
3: lsize3
```
@martins do you know where you have a FieldVector with size 2?https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/684Fingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?2019-08-28T10:21:17ZBeatrix BeckerFingering in freeflow test test_ff_stokes2c_densitydrivenflow to be expected?The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxR...The freeflow test `test_ff_stokes2c_densitydrivenflow` in `/test/freeflow/navierstokesnc/densitydrivenflow` shows fingers depending on Newton.MaxRelativeShift. As an example, a comparison of the magnitude of the velocity with Newton.MaxRelativeShift = 1e-14 (left) and Newton.MaxRelativeShift = 1e-8 (right) is shown below:
![Screenshot_20190328_103436](/uploads/c41421f0e0d85e05452f35ddbd0aeb6c/Screenshot_20190328_103436.png)
We should investigate if there is a physical basis for the appearance of fingers in this test.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/685Appl lens2pexercise3 in dumux-lecture fails after commit updating the timeloop2019-04-06T11:01:54ZTimo Kochtimokoch@math.uio.noAppl lens2pexercise3 in dumux-lecture fails after commit updating the timeloopPossible bug in the timeloop for large time step sizes? Fails since 2fbb615bc761c7c3fa860ced5901204eb15b5975Possible bug in the timeloop for large time step sizes? Fails since 2fbb615bc761c7c3fa860ced5901204eb15b59753.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/686Improve usage of container types in staggered2020-05-27T06:57:12ZKilian WeishauptImprove usage of container types in staggered* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time* Replace `std::vector` by `Dune::ReservedVector` or even `std::array`, where possible
* most sizes are known at compile time3.3Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/687CCTpfaFluxVariablesCacheFiller is too specific for porous medium applications2019-04-24T09:59:48ZTimo Kochtimokoch@math.uio.noCCTpfaFluxVariablesCacheFiller is too specific for porous medium applications!1525 shows that the `CCTpfaFluxVariablesCacheFiller` is specific for porous medium flow. It expects stuff like `enableMolecularDiffusion`.
Maybe such information could be moved into the Cache? Or into some physics specific property, se...!1525 shows that the `CCTpfaFluxVariablesCacheFiller` is specific for porous medium flow. It expects stuff like `enableMolecularDiffusion`.
Maybe such information could be moved into the Cache? Or into some physics specific property, set by the individual models?
@DennisGlaeser any idea?3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/688[shallow water] Add friction laws (Manning and Nikuradse)2019-07-01T09:45:38ZMartin Utz[shallow water] Add friction laws (Manning and Nikuradse)The friction laws give she shear stress at the bottom caused by the roughness of the river bed. Within this issue the frictions laws after Manning and Nikuradse are added, but there are also others, which can be added in future.The friction laws give she shear stress at the bottom caused by the roughness of the river bed. Within this issue the frictions laws after Manning and Nikuradse are added, but there are also others, which can be added in future.3.1Martin UtzMartin Utzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/689Create meaningful new 2pncmin NI test2019-10-09T07:40:46ZSimon EmmertCreate meaningful new 2pncmin NI testWe forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would ...We forgot to add the thermal conductivity law for the 2pncmin **NI** cases because there is no test available. This is addressed in !1560
We should come up with a (in my opinion) **new** test that uses the NI. I think a new test would be beneficial, because the current 2pncmin test is already relatively unstable.3.1Theresa SchollenbergerTheresa Schollenbergerhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/690[material][co2] create co2 tables with pressures less than 1 bar2022-03-30T09:17:22ZKatharina Heck[material][co2] create co2 tables with pressures less than 1 barthe current co2 tables start at 1 bar pressure but in the fluidsystems e.g. brineco2 we calculate e.g. the gas density based on partial pressure (which can be less than 1 bar). That can lead to wrong results if the partial pressure is le...the current co2 tables start at 1 bar pressure but in the fluidsystems e.g. brineco2 we calculate e.g. the gas density based on partial pressure (which can be less than 1 bar). That can lead to wrong results if the partial pressure is less than 1 bar. Then the value of 1 bar is taken from the table and added to the density calculation (which is especially wrong if no co2 is present at all)
Possibly this could be a task for a Hiwi to look into a meaningful relationship for densities etc for co2 and create new tables.3.5Johannes HommelJohannes Hommelhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/691Staggered Lingo Unification2019-04-26T07:09:20ZNed ColtmanStaggered Lingo UnificationWe waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It wou...We waste a lot of time getting confused with terms like "lateral", "normal", "parallel", "staggered", "sub-", "frontal", "tangential", and there are of course a few remaining.
Many of these terms actually refer to the same thing. It would be nice to have rules for when each of these words is used, and to unify their use within the staggered discretization and the freeflow models.
Is this possible?3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/692[staggered] Passing the object of partial(sol) to VtkWriter leads to segfault2019-04-24T10:15:41ZKilian Weishaupt[staggered] Passing the object of partial(sol) to VtkWriter leads to segfaultWhen using the staggered scheme in a multi-domain context, initializing the VtkWriter like
```cpp
auto partialSol = partial(sol);
StaggeredVtkOutputModule<GridVariables,
GetPropType<TypeTag, Properties::Solut...When using the staggered scheme in a multi-domain context, initializing the VtkWriter like
```cpp
auto partialSol = partial(sol);
StaggeredVtkOutputModule<GridVariables,
GetPropType<TypeTag, Properties::SolutionVector>> vtkWriter(*gridVariables, partialSol, name);
```
leads to a segfault.
If the writer is instead initialized like
```cpp
auto partialSol = partial(sol);
StaggeredVtkOutputModule<GridVariables,
decltype(partialSol)> vtkWriter(*gridVariables, partialSol, name);
```
everything works as expected.
Could be related to the fact that `partialSol` only stores references to the actual solution sub-vectors.
It indeed has a different type than `SolutionVector`.
C++17 probably would elegantly fix this, since we could just remove `SolutionVector` from the class template list because it could be inferred from the constructor.3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/693Small timesteps after check points in the time loop2019-05-20T06:28:38ZJohannes HommelSmall timesteps after check points in the time loopRunning some of the lecture exercises, I noticed that when simulations are run with checkpoints in the time loop, it happens that more often than not the time step sizes after the check points are quite small, because the time step size ...Running some of the lecture exercises, I noticed that when simulations are run with checkpoints in the time loop, it happens that more often than not the time step sizes after the check points are quite small, because the time step size before the check point was reduced so it end at the time of the check point. The new time step after the check point may thus start with a minuscule time step size, unnecessarily increasing the number of time steps and thereby simulation time.
In DUMUX 2.12 and older versions, it was possible to use the time step size of the last "full" time step before the check point, back then called episode, to estimate the time step size when continuing after the check point. Thus, for all setups with check points in the time loop, not only the current, but also the previous time step size would need to be stored and the previous time step size would need to be used when estimating the time step size of the time step after a check point.
It might be good to reintroduce such a feature for setups / main.cc-files using check point time loops. However, since this would now need to be done in each .cc file separately, it might be a bit time consuming and repetitive, an ideal DUMUX-day or HIWI task.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/694replace preprocessor switch USE_PCMAX2019-05-06T17:34:41ZBernd Flemischreplace preprocessor switch USE_PCMAXThere's a preprocessor switch `USE_PCMAX` used in `dumux/porousmediumflow/nonequilibrium/volumevariables.hh` that is set to `1` in `test/porousmediumflow/mpnc/implicit/kinetic/problem.hh`. We should avoid this. Probably by introducing a ...There's a preprocessor switch `USE_PCMAX` used in `dumux/porousmediumflow/nonequilibrium/volumevariables.hh` that is set to `1` in `test/porousmediumflow/mpnc/implicit/kinetic/problem.hh`. We should avoid this. Probably by introducing a flag in the traits of these volume variables?3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/695Failing non-equil tests after merging !14962019-05-04T13:49:31ZTimo Kochtimokoch@math.uio.noFailing non-equil tests after merging !1496After merging !1496 `test_1p2c_nonequilibrium_tpfa` `test_mpnc_kinetic_box` fail now on buildbot.
In the case of `test_1p2c_nonequilibrium_tpfa` an fv geometry cache is accessed which is not in the stencil.
```
Test command: /data/src/...After merging !1496 `test_1p2c_nonequilibrium_tpfa` `test_mpnc_kinetic_box` fail now on buildbot.
In the case of `test_1p2c_nonequilibrium_tpfa` an fv geometry cache is accessed which is not in the stencil.
```
Test command: /data/src/dumux/bin/testing/runtest.py "--script" "fuzzy" "--files" "/data/src/dumux/test/references/test_1p2c_nonequilibrium_tpfa-reference.vtu" "/data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa-00044.vtu" "--command" "/data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa params.input -Problem.Name test_1p2c_nonequilibrium_tpfa" "--zeroThreshold" "{"velocity_liq (m/s)_1":1e-15}"
Test timeout computed to be: 300
You idiot! You signed the order to destroy Earth!
- Douglas Adams, HGttG
Reading parameters from file params.input.
The H2O-N2 fluid system was configured with the following policy:
- use H2O density as liquid mixture density: true
- use ideal gas density: true
- use N2 viscosity as gas mixture viscosity: true
- use N2 heat conductivity as gas mixture heat conductivity: true
- use ideal gas heat capacities: true
-------------------------------------------------------------------------
Initializing tables for the H2O fluid properties (20000 entries).
Temperature -> min: 2.731e+02, max: 6.231e+02, n: 100
Pressure -> min: 0.000e+00, max: 2.000e+07, n: 200
-------------------------------------------------------------------------
problem uses mole fractions
Writing output for problem "test_1p2c_nonequilibrium_tpfa". Took 8.889e-01 seconds.
Assemble: r(x^k) = dS/dt + div F - q; M = grad rtest_1p2c_nonequilibrium_tpfa: /data/src/dumux/dumux/discretization/cellcentered/tpfa/fvelementgeometry.hh:536: const LocalIndexType Dumux::CCTpfaFVElementGeometry::findLocalIndex(Dumux::CCTpfaFVElementGeometry::GridIndexType, const std::vector::GridIndex>&) const [with GG = Dumux::CCTpfaFVGridGeometry > >, false, Dumux::CCTpfaDefaultGridGeometryTraits > >, Dumux::DefaultMapperTraits > >, Dune::MultipleCodimMultipleGeomTypeMapper > >, Dune::Impl::MCMGFailLayout>, Dune::MultipleCodimMultipleGeomTypeMapper > >, Dune::Impl::MCMGFailLayout> > > >; Dumux::CCTpfaFVElementGeometry::LocalIndexType = unsigned int; Dumux::CCTpfaFVElementGeometry::GridIndexType = unsigned int; typename Dumux::IndexTraits::GridIndex = unsigned int]: Assertion `it != indices.end() && "Could not find the scv/scvf! Make sure to properly bind this class!"' failed.
[behandla:19637] *** Process received signal ***
[behandla:19637] Signal: Aborted (6)
[behandla:19637] Signal code: (-6)
[behandla:19637] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f3fc9448890]
[behandla:19637] [ 1] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7f3fc9083e97]
[behandla:19637] [ 2] /lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7f3fc9085801]
[behandla:19637] [ 3] /lib/x86_64-linux-gnu/libc.so.6(+0x3039a)[0x7f3fc907539a]
[behandla:19637] [ 4] /lib/x86_64-linux-gnu/libc.so.6(+0x30412)[0x7f3fc9075412]
[behandla:19637] [ 5] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(+0xd0faf)[0x55c4b4287faf]
[behandla:19637] [ 6] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZNK5Dumux41NonEquilibriumLocalResidualImplementationINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaELb0EE11computeFluxERKNS_36OnePTwoCThermalNonequilibriumProblemIS3_EERKN4Dune6EntityILi0ELi2EKNS9_8YaspGridILi2ENS9_22EquidistantCoordinatesIdLi2EEEEENS9_10YaspEntityEEERKNS_23CCTpfaFVElementGeometryINS_20CCTpfaFVGridGeometryINS9_8GridViewINS9_25DefaultLeafGridViewTraitsISF_EEEELb0ENS_31CCTpfaDefaultGridGeometryTraitsISP_NS_19DefaultMapperTraitsISP_NS9_35MultipleCodimMultipleGeomTypeMapperISP_NS9_4Impl14MCMGFailLayoutEEESV_EEEEEELb0EEERKNS_28CCTpfaElementVolumeVariablesINS_21CCGridVolumeVariablesINS_38CCTpfaDefaultGridVolumeVariablesTraitsIS6_NS_43NonEquilibriumVolumeVariablesImplementationINS_27OnePNCVolumeVariablesTraitsINS9_11FieldVectorIdLi4EEENS_12FluidSystems11OnePAdapterINS19_5H2ON2IdNS19_18H2ON2DefaultPolicyILb1EEEEELi0EEENS_24NonEquilibriumFluidStateIdS1F_EENS_12SolidSystems15InertSolidPhaseIdNS_10Components8ConstantILi1EdEEEENS_15InertSolidStateIdS1N_EEdNS_25NonEquilibriumModelTraitsINS_30OnePNCUnconstrainedModelTraitsINS_17OnePNCModelTraitsILi2ELb1ELi2EEEEELb0ELb1ELi1ELi1ELNS_18NusseltFormulationE1ELNS_19SherwoodFormulationE0EEEEENS_21OnePNCVolumeVariablesIS1Y_EELb0ELb1ELi1EEEEELb0EEELb0EEERKNS_26CCTpfaSubControlVolumeFaceISP_NS_31CCTpfaDefaultScvfGeometryTraitsISP_EEEERKNS_31CCTpfaElementFluxVariablesCacheINS_28CCTpfaGridFluxVariablesCacheIS6_NS_44PorousMediumFluxVariablesCacheImplementationIS3_LNS_20DiscretizationMethodE2EEENS_50PorousMediumFluxVariablesCacheFillerImplementationIS3_LS2G_2EEELb0ENS_26CCTpfaDefaultGridFVCTraitsIS6_S2H_S2J_EEEELb0EEE+0x1713)[0x55c4b431b873]
[behandla:19637] [ 7] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZNK5Dumux15CCLocalResidualINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaEE8evalFluxERKNS_36OnePTwoCThermalNonequilibriumProblemIS3_EERKN4Dune6EntityILi0ELi2EKNS9_8YaspGridILi2ENS9_22EquidistantCoordinatesIdLi2EEEEENS9_10YaspEntityEEERKNS_23CCTpfaFVElementGeometryINS_20CCTpfaFVGridGeometryINS9_8GridViewINS9_25DefaultLeafGridViewTraitsISF_EEEELb0ENS_31CCTpfaDefaultGridGeometryTraitsISP_NS_19DefaultMapperTraitsISP_NS9_35MultipleCodimMultipleGeomTypeMapperISP_NS9_4Impl14MCMGFailLayoutEEESV_EEEEEELb0EEERKNS_28CCTpfaElementVolumeVariablesINS_21CCGridVolumeVariablesINS_38CCTpfaDefaultGridVolumeVariablesTraitsIS6_NS_43NonEquilibriumVolumeVariablesImplementationINS_27OnePNCVolumeVariablesTraitsINS9_11FieldVectorIdLi4EEENS_12FluidSystems11OnePAdapterINS19_5H2ON2IdNS19_18H2ON2DefaultPolicyILb1EEEEELi0EEENS_24NonEquilibriumFluidStateIdS1F_EENS_12SolidSystems15InertSolidPhaseIdNS_10Components8ConstantILi1EdEEEENS_15InertSolidStateIdS1N_EEdNS_25NonEquilibriumModelTraitsINS_30OnePNCUnconstrainedModelTraitsINS_17OnePNCModelTraitsILi2ELb1ELi2EEEEELb0ELb1ELi1ELi1ELNS_18NusseltFormulationE1ELNS_19SherwoodFormulationE0EEEEENS_21OnePNCVolumeVariablesIS1Y_EELb0ELb1ELi1EEEEELb0EEELb0EEERKNS_31CCTpfaElementFluxVariablesCacheINS_28CCTpfaGridFluxVariablesCacheIS6_NS_44PorousMediumFluxVariablesCacheImplementationIS3_LNS_20DiscretizationMethodE2EEENS_50PorousMediumFluxVariablesCacheFillerImplementationIS3_LS2A_2EEELb0ENS_26CCTpfaDefaultGridFVCTraitsIS6_S2B_S2D_EEEELb0EEERKNS_26CCTpfaSubControlVolumeFaceISP_NS_31CCTpfaDefaultScvfGeometryTraitsISP_EEEE+0x2e3)[0x55c4b431bf03]
[behandla:19637] [ 8] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZNK5Dumux15FVLocalResidualINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaEE17evalFluxAndSourceERKN4Dune6EntityILi0ELi2EKNS5_8YaspGridILi2ENS5_22EquidistantCoordinatesIdLi2EEEEENS5_10YaspEntityEEERKNS_23CCTpfaFVElementGeometryINS_20CCTpfaFVGridGeometryINS5_8GridViewINS5_25DefaultLeafGridViewTraitsISB_EEEELb0ENS_31CCTpfaDefaultGridGeometryTraitsISL_NS_19DefaultMapperTraitsISL_NS5_35MultipleCodimMultipleGeomTypeMapperISL_NS5_4Impl14MCMGFailLayoutEEESR_EEEEEELb0EEERKNS_28CCTpfaElementVolumeVariablesINS_21CCGridVolumeVariablesINS_38CCTpfaDefaultGridVolumeVariablesTraitsINS_36OnePTwoCThermalNonequilibriumProblemIS3_EENS_43NonEquilibriumVolumeVariablesImplementationINS_27OnePNCVolumeVariablesTraitsINS5_11FieldVectorIdLi4EEENS_12FluidSystems11OnePAdapterINS17_5H2ON2IdNS17_18H2ON2DefaultPolicyILb1EEEEELi0EEENS_24NonEquilibriumFluidStateIdS1D_EENS_12SolidSystems15InertSolidPhaseIdNS_10Components8ConstantILi1EdEEEENS_15InertSolidStateIdS1L_EEdNS_25NonEquilibriumModelTraitsINS_30OnePNCUnconstrainedModelTraitsINS_17OnePNCModelTraitsILi2ELb1ELi2EEEEELb0ELb1ELi1ELi1ELNS_18NusseltFormulationE1ELNS_19SherwoodFormulationE0EEEEENS_21OnePNCVolumeVariablesIS1W_EELb0ELb1ELi1EEEEELb0EEELb0EEERKNS_31CCTpfaElementFluxVariablesCacheINS_28CCTpfaGridFluxVariablesCacheIS12_NS_44PorousMediumFluxVariablesCacheImplementationIS3_LNS_20DiscretizationMethodE2EEENS_50PorousMediumFluxVariablesCacheFillerImplementationIS3_LS28_2EEELb0ENS_26CCTpfaDefaultGridFVCTraitsIS12_S29_S2B_EEEELb0EEERKNS_22CCElementBoundaryTypesE+0x341)[0x55c4b431c3e1]
[behandla:19637] [ 9] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZNK5Dumux20FVLocalAssemblerBaseINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaENS_11FVAssemblerIS3_LNS_10DiffMethodE0ELb1EEENS_16CCLocalAssemblerIS3_S6_LS5_0ELb1EEELb1EE17evalLocalResidualEv+0xd6)[0x55c4b431ccb6]
[behandla:19637] [10] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZN5Dumux16CCLocalAssemblerINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaENS_11FVAssemblerIS3_LNS_10DiffMethodE0ELb1EEELS5_0ELb1EE31assembleJacobianAndResidualImplERN4Dune10BCRSMatrixINS8_11FieldMatrixIdLi4ELi4EEESaISB_EEERNS_27NonEquilibriumGridVariablesIS3_EE+0x74d)[0x55c4b433ef4d]
[behandla:19637] [11] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_ZNK5Dumux11FVAssemblerINS_10Properties4TTag35OnePTwoCThermalNonequilibriumCCTpfaELNS_10DiffMethodE0ELb1EE9assemble_IZNS5_27assembleJacobianAndResidualINS_18PartialReassemblerIS5_EEEEvRKN4Dune11BlockVectorINSA_11FieldVectorIdLi4EEESaISD_EEEPKT_EUlRKNSA_6EntityILi0ELi2EKNSA_8YaspGridILi2ENSA_22EquidistantCoordinatesIdLi2EEEEENSA_10YaspEntityEEEE_EEvOSI_+0x132)[0x55c4b4340b52]
[behandla:19637] [12] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(main+0xeb3)[0x55c4b4282c53]
[behandla:19637] [13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f3fc9066b97]
[behandla:19637] [14] /data/build/dumux/test/porousmediumflow/1pnc/implicit/nonequilibrium/test_1p2c_nonequilibrium_tpfa(_start+0x2a)[0x55c4b4286a2a]
[behandla:19637] *** End of error message ***
63/186 Test #63: test_1p2c_nonequilibrium_tpfa .....................***Failed 1.82 sec
```
```
Test command: /data/src/dumux/bin/testing/runtest.py "--script" "fuzzy" "--files" "/data/src/dumux/test/references/test_mpnc_kinetic_box-reference.vtu" "/data/build/dumux/test/porousmediumflow/mpnc/implicit/kinetic/test_mpnc_kinetic_box-00011.vtu" "--command" "/data/build/dumux/test/porousmediumflow/mpnc/implicit/kinetic/test_mpnc_kinetic_box params.input -Problem.Name test_mpnc_kinetic_box"
Test timeout computed to be: 300
Chuck Norris has successfully compiled DuMuX.
Reading parameters from file params.input.
The H2O-N2 fluid system was configured with the following policy:
- use H2O density as liquid mixture density: true
- use ideal gas density: true
- use N2 viscosity as gas mixture viscosity: true
- use N2 heat conductivity as gas mixture heat conductivity: true
- use ideal gas heat capacities: true
-------------------------------------------------------------------------
Initializing tables for the H2O fluid properties (10000 entries).
Temperature -> min: 2.780e+02, max: 4.531e+02, n: 100
Pressure -> min: 7.500e+04, max: 2.250e+05, n: 100
-------------------------------------------------------------------------
Writing output for problem "test_mpnc_kinetic_box". Took 6.039e-01 seconds.
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.278e+00(4.768e+01%)/1.402e+00(5.231e+01%)/3.405e-04(1.270e-02%)
Writing output for problem "test_mpnc_kinetic_box". Took 4.812e-02 seconds.
[ 1%] Time step 1 done in 2.736643 seconds. Wall clock time: 2.785, time: 0.05000, time step size: 0.05000000
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 0.95099143(48.46939834%)/1.01091940(51.52376100%)/0.00013422(0.00684067%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04853347 seconds.
[ 1%] Time step 2 done in 2.051791 seconds. Wall clock time: 4.837, time: 0.12500, time step size: 0.07500000
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 0.94914820(48.59345643%)/1.00394319(51.39879041%)/0.00015144(0.00775316%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04807224 seconds.
[ 2%] Time step 3 done in 2.043512 seconds. Wall clock time: 6.880, time: 0.24375, time step size: 0.11875000
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 0.95115055(48.39749146%)/1.01398697(51.59480356%)/0.00015143(0.00770497%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04845110 seconds.
[ 4%] Time step 4 done in 2.055532 seconds. Wall clock time: 8.936, time: 0.43177, time step size: 0.18802083
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 0.95967631(48.69862390%)/1.01083155(51.29448896%)/0.00013572(0.00688714%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04814657 seconds.
[ 7%] Time step 5 done in 2.060660 seconds. Wall clock time: 10.996, time: 0.72947, time step size: 0.29769965
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.26521772(48.89266931%)/1.32233187(51.09977040%)/0.00019564(0.00756029%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04806234 seconds.
[ 12%] Time step 6 done in 2.691426 seconds. Wall clock time: 13.688, time: 1.20083, time step size: 0.47135778
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.27771621(48.82405213%)/1.33907903(51.16884610%)/0.00018585(0.00710177%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04817870 seconds.
[ 19%] Time step 7 done in 2.720932 seconds. Wall clock time: 16.409, time: 1.90786, time step size: 0.70703668
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.27635560(48.32649627%)/1.36457241(51.66663862%)/0.00018132(0.00686511%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04837157 seconds.
[ 30%] Time step 8 done in 2.745505 seconds. Wall clock time: 19.154, time: 2.96842, time step size: 1.06055501
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.28703688(48.70908916%)/1.35506024(51.28349543%)/0.00019594(0.00741542%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04841897 seconds.
[ 46%] Time step 9 done in 2.747992 seconds. Wall clock time: 21.902, time: 4.55925, time step size: 1.59083252
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.27011454(48.08293266%)/1.37121299(51.91023325%)/0.00018052(0.00683409%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04838746 seconds.
[ 69%] Time step 10 done in 2.745616 seconds. Wall clock time: 24.648, time: 6.94550, time step size: 2.38624878
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble: r(x^k) = dS/dt + div F - q; M = grad r
Assemble/solve/update time: 1.27372658(48.61208584%)/1.34627708(51.38099319%)/0.00018134(0.00692096%)
Writing output for problem "test_mpnc_kinetic_box". Took 0.04840041 seconds.
[100%] Time step 11 done in 2.725102 seconds. Wall clock time: 27.373, time: 10.00000, time step size: 3.05449874
Simulation took 27.37315323 seconds on 1 processes.
The cumulative CPU time was 27.37315323 seconds.
# Runtime-specified parameters used:
[ BoundaryConditions ]
TInject = "293"
massFluxInjectedPhase = "0.75"
percentOfEquil = ".1"
[ Component ]
SolidDensity = "2600"
SolidHeatCapacity = "817"
SolidThermalConductivity = "3"
[ FluidSystem ]
nPressure = "100"
nTemperature = "100"
[ Grid ]
Cells0 = "14"
Cells1 = "15 15"
Grading0 = "1.0"
Grading1 = "-0.833333 0.833333"
Positions0 = "0.0 1.0"
Positions1 = "0.0 0.25 0.5"
[ InitialConditions ]
SwFFInitial = "1e-4"
SwPMInitial = "0.8"
TInitial = "293"
pnInitial = "1e5"
pnInjection = "100003"
[ Problem ]
Name = "test_mpnc_kinetic_box"
[ SpatialParams ]
[ SpatialParams.FreeFlow ]
meanPoreSize = "1e-2"
permeability = "1e-6"
porosity = "0.99"
[ SpatialParams.PorousMedium ]
factorEnergyTransfer = "1"
factorMassTransfer = "1"
meanPoreSize = "1e-4"
permeability = "1e-11"
porosity = "0.4"
[ SpatialParams.soil ]
BCPd = "2.290e+03"
BClambda = "2.740e+00"
Snr = "0"
Swr = "0"
aNonWettingSolidA1 = "1.369e+03"
aNonWettingSolidA2 = "-3.782e+00"
aNonWettingSolidA3 = "1.063e-09"
aWettingNonWettingA1 = "-1.603e-01"
aWettingNonWettingA2 = "1.429e-05"
aWettingNonWettingA3 = "1.915e-01"
[ TimeLoop ]
DtInitial = "0.05"
TEnd = "10"
[ Vtk ]
AddVelocity = "1"
# Global default parameters used:
[ Assembly ]
NumericDifferenceMethod = "1"
[ Flux ]
UpwindWeight = "1.0"
[ LinearSolver ]
MaxIterations = "250"
PreconditionerIterations = "1"
PreconditionerRelaxation = "1.0"
ResidualReduction = "1e-13"
Verbosity = "0"
[ Newton ]
EnableAbsoluteResidualCriterion = "false"
EnableChop = "false"
EnablePartialReassembly = "false"
EnableResidualCriterion = "false"
EnableShiftCriterion = "true"
MaxAbsoluteResidual = "1e-5"
MaxRelativeShift = "1e-8"
MaxSteps = "18"
ResidualReduction = "1e-5"
SatisfyResidualAndShiftCriterion = "false"
TargetSteps = "10"
UseLineSearch = "false"
[ Problem ]
EnableGravity = "true"
[ TimeLoop ]
MaxTimeStepSize = "1e300"
[ Vtk ]
AddProcessRank = "true"
# Unused parameters:
SpatialParams.soil.VGAlpha = "3.512e-04"
SpatialParams.soil.VGN = "4.716e+00"
SpatialParams.soil.specificSolidsurface = "4022.994"
SourceSink.heatIntoSolid = "0"
Constants.nRestart = "100"
FluidSystem.hammer = "1e4"
Chuck Norris has compiled DuMuX even two times in a row!
Fuzzy comparison...
Comparing /data/src/dumux/test/references/test_mpnc_kinetic_box-reference.vtu and /data/build/dumux/test/porousmediumflow/mpnc/implicit/kinetic/test_mpnc_kinetic_box-00011.vtu
... with a maximum relative error of 0.01 and a maximum absolute error of 1.5e-07*max_abs_parameter_value.
Data differs in parameter: velocity_gas (m/s)_1
Difference is too large: 8.70% -> between: 1.91128e-06 and 1.74495e-06
Info for velocity_gas (m/s)_1: max_abs_parameter_value=0.564606 and min_abs_parameter_value=1.74495e-06.
Data differs in parameter: velocity_liq (m/s)_0
Difference is too large: 1.00% -> between: 6.90209e-08 and 6.97191e-08
Info for velocity_liq (m/s)_0: max_abs_parameter_value=7.2564e-08 and min_abs_parameter_value=8.35171e-16.
Data differs in parameter: x^H2O_gas
Difference is too large: 55.46% -> between: 0.023197 and 0.0103322
Info for x^H2O_gas: max_abs_parameter_value=0.0232059 and min_abs_parameter_value=0.00232059.
Data differs in parameter: x^N2_gas
Difference is too large: 1.30% -> between: 0.976803 and 0.989668
Info for x^N2_gas: max_abs_parameter_value=0.997679 and min_abs_parameter_value=0.976794.
Test #155: test_mpnc_kinetic_box .............................***Failed 29.19 sec
```3.1Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/696Move gravity to spatial parameters?2019-05-03T07:19:19ZTimo Kochtimokoch@math.uio.noMove gravity to spatial parameters?Gravity is part of the porous medium problem interface. I don't see why though..
Should we better move the interface to the spatial params?Gravity is part of the porous medium problem interface. I don't see why though..
Should we better move the interface to the spatial params?Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/697[shallowwater] Complete the doxygen documentation2019-05-13T14:33:48ZMartin Utz[shallowwater] Complete the doxygen documentationThe doxygen documentation for the shallow water part does not work properly, because the modules.txt is not updated. After fixing that, in general the shallowwater doxygen documentation shall be tested.
* [x] Add entry in modules.txt fo...The doxygen documentation for the shallow water part does not work properly, because the modules.txt is not updated. After fixing that, in general the shallowwater doxygen documentation shall be tested.
* [x] Add entry in modules.txt for ShallowWater
* [x] Check that all classes and functions have a docstring
* [x] Document ShallowWaterFlux classMartin UtzMartin Utzhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/698Installation2019-05-30T23:32:27ZLarry FranksInstallationGents I have just completed a DUMUX installation but it took a long time. The script on you web site did not work, it has errors. I eventually used the git method in your manual and the Dumux coarse finally installed everything and wor...Gents I have just completed a DUMUX installation but it took a long time. The script on you web site did not work, it has errors. I eventually used the git method in your manual and the Dumux coarse finally installed everything and worked. You also need to tell people that they need Paraview, gnuplot and gfortran installed before it all works, I only found this from the error files.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/699VTKReader can't read polydata with lines with more than 2 points2019-05-13T15:25:55ZTimo Kochtimokoch@math.uio.noVTKReader can't read polydata with lines with more than 2 pointsThe format allows to specify poly lines with many points. The reader currently expects each line to be a line element with two points.The format allows to specify poly lines with many points. The reader currently expects each line to be a line element with two points.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/700Test virtual interface for Problem2019-10-30T10:02:28ZTimo Kochtimokoch@math.uio.noTest virtual interface for ProblemGetting rid of the problem template would be a huge improvement in the code.
We should do performance measurement and check what run-time penalty a virtual problem interface would bring.
For that we have to first check which functions ac...Getting rid of the problem template would be a huge improvement in the code.
We should do performance measurement and check what run-time penalty a virtual problem interface would bring.
For that we have to first check which functions actually need to be virtual, add the virtual keyword, we could then exchange templates for a base class pointer one-by-one, and check for performance penalties.
The highest penalty is probably expected for a grid with a high boundary to internal cell ratio, and simple boundary and initial conditions so that the possible virtual function call would actually matter.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/701[fluidsystems] TwoPImmiscible returns the same phase name when used with two ...2019-05-17T13:46:02ZKilian Weishaupt[fluidsystems] TwoPImmiscible returns the same phase name when used with two OnePLiquid<ConstantComponent> systemsWhen using
```cpp
template<class TypeTag>
struct FluidSystem<TypeTag, TTag::MyProblem>
{
using Scalar = GetPropType<TypeTag, Properties::Scalar>;
using Component1 = Components::Constant<1, Scalar>;
using Component2 = Comp...When using
```cpp
template<class TypeTag>
struct FluidSystem<TypeTag, TTag::MyProblem>
{
using Scalar = GetPropType<TypeTag, Properties::Scalar>;
using Component1 = Components::Constant<1, Scalar>;
using Component2 = Components::Constant<2, Scalar>;
using Phase1 = Dumux::FluidSystems::OnePLiquid<Scalar, Component1>;
using Phase2 = Dumux::FluidSystems::OnePLiquid<Scalar, Component2>;
using type = Dumux::FluidSystems::TwoPImmiscible<Scalar, Phase1, Phase2>;
};
```
The phase name returned by `TwoPImmiscible` is always `napl` due to the trait
``` cpp
template <class Component>
struct IsAqueous : public std::false_type {};
```
defined in `dumux/material/components/constant.hh`
This makes the fluid system unusable, because ParaView segfaults when attempting to load to vtk file.
Should we include the choice to specify names as runtime parameters?3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/702[boxAssembly] Setting Dirichlet BCs fails for explicit box assembly2019-05-17T13:46:19ZKilian Weishaupt[boxAssembly] Setting Dirichlet BCs fails for explicit box assemblyFor box, Dirichlet BCs are applied in `BoxLocalAssemblerBase`
```cpp
res[scvI.dofIndex()][eqIdx] = this->curElemVolVars()[scvI].priVars()[pvIdx] - dirichletValues[pvIdx];
for (const auto& scvJ : scvs(this->fvGeom...For box, Dirichlet BCs are applied in `BoxLocalAssemblerBase`
```cpp
res[scvI.dofIndex()][eqIdx] = this->curElemVolVars()[scvI].priVars()[pvIdx] - dirichletValues[pvIdx];
for (const auto& scvJ : scvs(this->fvGeometry()))
{
jac[scvI.dofIndex()][scvJ.dofIndex()][eqIdx] = 0.0;
if (scvI.localDofIndex() == scvJ.localDofIndex())
jac[scvI.dofIndex()][scvI.dofIndex()][eqIdx][pvIdx] = 1.0;
}
```
The offending line is `jac[scvI.dofIndex()][scvJ.dofIndex()][eqIdx] = 0.0;` since in the explicit case, there are only diagonal entries in Jacobian. A dune-istl error will be raised.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/703Spatial parameters cannot be time dependent if not solution-dependent2023-02-22T08:58:07ZTimo Kochtimokoch@math.uio.noSpatial parameters cannot be time dependent if not solution-dependentIf we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass tha...If we compute the tracer model in combination with a fluid that changes properties over time, we
need the old properties to evaluate the storage.
The problem is, the volvars currently don't know anything about time, so we can't pass that information
to the spatial params. That's why we currently assume that all secondary variables are either constant
or solution-dependent but not time-dependent without being solution-dependent. This is a big drawback
in general and a bug or at least an imprecision in the tracer model.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/704Multiphase tracer produces singular matrix if saturation is zero2020-03-30T20:16:38ZTimo Kochtimokoch@math.uio.noMultiphase tracer produces singular matrix if saturation is zeroA case that is like in two-phase models is that one phase disappears. If the tracer only exists in this
phase, the tracer also disappear, however that means that the local equation/residual degenerates.
This is automatically the case fo...A case that is like in two-phase models is that one phase disappears. If the tracer only exists in this
phase, the tracer also disappear, however that means that the local equation/residual degenerates.
This is automatically the case for all dofs where saturation is zero (over the whole time integration interval, see #703).
A robust solution could be to check for zero saturation and replace the equation for those dofs with the Dirichlet constraint that the concentration is zero. For that it would need to be possible to set Dirichlet for every dof even when not on the boundary, see #704.3.2Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/705Additional Dirichlet constraints2019-07-15T12:06:44ZTimo Kochtimokoch@math.uio.noAdditional Dirichlet constraintsI would be nice to be able to set Dirichlet constraints for any dof in the problem.
The assembler could ask the problem if it defines additional constraints (constexpr bool func or by member function inspection (probably too magical)) an...I would be nice to be able to set Dirichlet constraints for any dof in the problem.
The assembler could ask the problem if it defines additional constraints (constexpr bool func or by member function inspection (probably too magical)) and if yes implement these constraints after the assembly.
This feature could fix e.g. #704. However I'm having problems to come up with other used cases, maybe some overlapping domain decomposition stuff.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/706Add turbulent diffusion to shallow water model2021-02-26T21:39:05ZFrank PlatzekAdd turbulent diffusion to shallow water modelThe preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.The preliminary turbulent diffusion implementation in the shallow water model from Issue #657
(Turbulent diffusion in shallow water equations), is to be merged in the new structure for the shallow water model as part of the Freeflow model.Frank PlatzekFrank Platzekhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/707Generic implementation of L2-norm calculation using generic L2-projection2024-01-18T09:27:15ZTimo Kochtimokoch@math.uio.noGeneric 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)
* [x] 3d-3d intersections (!29...With !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)
* [x] 3d-3d intersections (!2977)
That would be a great tool for convergence tests.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/708Follow-up from "Feature/projector"2019-07-01T09:44:53ZTimo Kochtimokoch@math.uio.noFollow-up from "Feature/projector"The following discussion from !1609 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1609#note_26603): (+1 comment)
> You could optimize this for the...The following discussion from !1609 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1609#note_26603): (+1 comment)
> You could optimize this for the different-grid case by only storing the parts of the projection that are non-zero. Then do the projection in the smaller spaces.Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/7092p2c water-air and fuelcell/remediation tests fail due to !16152019-05-28T08:54:20ZSimon Emmert2p2c water-air and fuelcell/remediation tests fail due to !1615The following tests fail on buildbot due to the changes in the viscosity calculation from !1615
dumux (some have a singular matrix and do not converge at all)
```
119 - test_2p2cni_waterair_box (Failed)
120 - test_2p2cni_waterair_buoyan...The following tests fail on buildbot due to the changes in the viscosity calculation from !1615
dumux (some have a singular matrix and do not converge at all)
```
119 - test_2p2cni_waterair_box (Failed)
120 - test_2p2cni_waterair_buoyancy_box (Failed)
121 - test_2p2cni_waterair_tpfa (Failed)
```
dumux-lecture (here only the reference solution does not match anymore)
```
11 - fuelcell (Failed)
22 - remediationscenariosexercise (Failed)
```https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/710Follow-up from "Feature/simplify effective laws"2020-03-26T18:18:56ZTimo Kochtimokoch@math.uio.noFollow-up from "Feature/simplify effective laws"The following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed w...The following discussion from !1605 should be addressed:
- [ ] @DennisGlaeser started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1605#note_26777): (+3 comments)
> I thought we removed wPhaseIdx from the Indices and made this a runtime-thing? How does this actually compile?
* [ ] Make wetting phase index retrievable from 2p volvars
* [ ] Use them in Johansen effective thermal conductivity law3.2Katharina HeckKatharina Heckhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/711Access to problem quantities (like thermal conductivity) model dependent2020-03-26T18:18:55ZAlexander 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) ...I 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 avoid3.2Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/712Add monotone cubic spline interpolation2019-05-29T10:08:34ZTimo Kochtimokoch@math.uio.noAdd monotone cubic spline interpolationFor interpolating material laws it might be better for Newton convergence to use a monotonicity preserving interpolation, than a natural cubic spline.For interpolating material laws it might be better for Newton convergence to use a monotonicity preserving interpolation, than a natural cubic spline.Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/713Generalize implementation of Beavers-Joseph(-Saffmann) slip condition2019-07-19T12:30:12ZKilian WeishauptGeneralize implementation of Beavers-Joseph(-Saffmann) slip conditionSo far ths BJS condition only considers $`du/dy`$. We should extend this to $`(du/dy`$ + $`dv/dx)`$So far ths BJS condition only considers $`du/dy`$. We should extend this to $`(du/dy`$ + $`dv/dx)`$3.1Kilian WeishauptKilian Weishaupthttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/714Calculate time derivatives by product rule and total derivative for compressi...2019-06-27T08:47:54ZMelanie 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} \approx \frac{\partial \left(...For 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} \approx \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} \approx \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/715Add implementation of linspace2019-05-30T20:11:16ZTimo Kochtimokoch@math.uio.noAdd implementation of linspaceSomething similar to the Python linspace would be nice for creating plots.
See e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/94d352a457077cfc7ba86426d0fb43968a81c2d8/test/common/spline/test_cubicspline.cc
for a simp...Something similar to the Python linspace would be nice for creating plots.
See e.g. https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/blob/94d352a457077cfc7ba86426d0fb43968a81c2d8/test/common/spline/test_cubicspline.cc
for a simple implementation. One could add something like the Kahan summation algorithm, for better precision.3.1Ned ColtmanNed Coltmanhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/716test adaptive2p2c3d fails2019-06-17T13:30:48ZSimon Emmerttest adaptive2p2c3d failsThe test fails on buildbot and we will document and investigate here why.
The fluidstate was adapted, and the reference solution changed accordingly. Apparently the test is very sensitive (which makes sense) and gives different solution...The test fails on buildbot and we will document and investigate here why.
The fluidstate was adapted, and the reference solution changed accordingly. Apparently the test is very sensitive (which makes sense) and gives different solutions on different machines (compilers). I will try to test it on other machines and see if I can find anything systematic.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/717SPE 10 as example2019-07-10T13:30:07ZTimo Kochtimokoch@math.uio.noSPE 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.There 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/718Optimize the output of the newton solver for piping into a file2019-05-29T12:48:39ZTimo Kochtimokoch@math.uio.noOptimize the output of the newton solver for piping into a fileIf you enable the verbose option of the newton solver, within each newton step the assemble/solve/update steps are first printed and then deleted again. This is handy for output to console, but leads to strange results for text output.
...If you enable the verbose option of the newton solver, within each newton step the assemble/solve/update steps are first printed and then deleted again. This is handy for output to console, but leads to strange results for text output.
Solve this problem by making the output of the assemble/solve/update steps optional.https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/719FVElementGeometry public alias FVGridGeometry is not generic enough2019-10-09T06:33:50ZTimo Kochtimokoch@math.uio.noFVElementGeometry 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.For 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.3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/720Merge of feature/improve-parameters breaks tests2019-06-04T09:25:06ZKilian WeishauptMerge of feature/improve-parameters breaks testsAfter the merge of 5c1c052467bbe86f903dac3f1de4990c41a03320, at least one test (test_ff_stokes_channel_3d) fails
because the output file changed its name from
`test_ff_stokes_channel_3d-00001.vtu` to `test_stokes_channel_3d-00001.vtu`
...After the merge of 5c1c052467bbe86f903dac3f1de4990c41a03320, at least one test (test_ff_stokes_channel_3d) fails
because the output file changed its name from
`test_ff_stokes_channel_3d-00001.vtu` to `test_stokes_channel_3d-00001.vtu`
`CMakeLists.txt` explicitly states
```
-Problem.Name test_ff_stokes_channel_3d
```
but somehow this is ignored and the name given in `parmas.input` is used.3.1Timo Kochtimokoch@math.uio.noTimo Kochtimokoch@math.uio.nohttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/721[Navier-Stokes] Revise definition of transporting velocity on boundary for mo...2019-07-25T06:30:47ZKilian Weishaupt[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 probab...The 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/722(Not) modifying parameter tree during simulation2020-03-18T10:03:11ZTimo Kochtimokoch@math.uio.no(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...I 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.2https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/723[Navier Stokes] Possibly revise initial condition of instationary channel test2019-06-27T07:39:35ZMelanie 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 every...I 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.Sina AckermannSina Ackermannhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/724[Navier Stokes] Gravity upwinding2019-11-27T10:27:16ZMelanie 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?Do we want to use the upwind-density for both half-cells instead of the currently used density of the corresponding half-cell?3.2Melanie LippMelanie Lipphttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/725[Navier Stokes] Upwinding of transporting velocity2019-06-27T07:32: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 ...We 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/726More tools for regression tests2023-12-13T11:13:07ZTimo Kochtimokoch@math.uio.noMore 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,...<!--
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/727Subgridmanager fails to compile with clang2019-06-26T13:15:05ZTimo Kochtimokoch@math.uio.noSubgridmanager fails to compile with clang<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
Compiling the sub grid manager with clang yields the following compiler error
```
FAILED: test/io/gridmanager/...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
Compiling the sub grid manager with clang yields the following compiler error
```
FAILED: test/io/gridmanager/CMakeFiles/test_gridmanager_subgrid.dir/test_gridmanager_subgrid.cc.o
/usr/bin/clang++ -DENABLE_MPI=1 -DENABLE_SUITESPARSE=1 -DENABLE_SUPERLU=1 -DENABLE_TBB=1 -DENABLE_UG=1 -DHAVE_CONFIG_H -DMPICH_SKIP_MPICXX -DMPIPP_H -DMPI_NO_CPPBIND -DModelP -DUG_USE_NEW_DIMENSION_DEFINES -D_TBB_CPP0X -I. -I/data/src/dumux -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/opal/mca/event/libevent2022/libevent/include -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/data/src/dune-common -I/data/src/dune-geometry -I/data/src/dune-uggrid -I/data/src/dune-uggrid/low -I/data/src/dune-uggrid/gm -I/data/src/dune-uggrid/dom -I/data/src/dune-uggrid/np -I/data/src/dune-uggrid/ui -I/data/src/dune-uggrid/np/algebra -I/data/src/dune-uggrid/np/udm -I/data/src/dune-uggrid/parallel -I/data/src/dune-uggrid/parallel/ddd -I/data/src/dune-uggrid/parallel/ppif -I/data/src/dune-uggrid/parallel/dddif -I/data/src/dune-uggrid/parallel/util -I/data/src/dune-uggrid/parallel/ddd/include -I/data/src/dune-grid -I/data/src/dune-alugrid -I/data/src/dune-spgrid -I/data/src/dune-subgrid -I/data/src/dune-foamgrid -I/data/src/dune-istl -I/data/src/dune-localfunctions -I/usr/include/scotch -I/usr/include/suitesparse -I/usr/include/superlu -std=c++17 -fdiagnostics-color=always -fno-strict-aliasing -fstrict-overflow -fno-finite-math-only -O3 -march=native -funroll-loops -g0 -Wall -Wunused -Wmissing-include-dirs -Wcast-align -Wno-missing-braces -Wmissing-field-initializers -Wno-sign-compare -fPIE -MD -MT test/io/gridmanager/CMakeFiles/test_gridmanager_subgrid.dir/test_gridmanager_subgrid.cc.o -MF test/io/gridmanager/CMakeFiles/test_gridmanager_subgrid.dir/test_gridmanager_subgrid.cc.o.d -o test/io/gridmanager/CMakeFiles/test_gridmanager_subgrid.dir/test_gridmanager_subgrid.cc.o -c /data/src/dumux/test/io/gridmanager/test_gridmanager_subgrid.cc
In file included from /data/src/dumux/test/io/gridmanager/test_gridmanager_subgrid.cc:31:
/data/src/dumux/dumux/io/grid/gridmanager_sub.hh:235:7: error: class template partial specialization contains a template parameter that cannot be deduced; this partial specialization will never be used [-Wunusable-partial-specialization]
class GridManager<Dune::SubGrid<HostGrid::dimension,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/data/src/dumux/dumux/io/grid/gridmanager_sub.hh:234:16: note: non-deducible template parameter 'HostGrid'
template<class HostGrid>
^
```
**How to reproduce it (as minimally and precisely as possible)**:
Compile test_gridmanager_subgrid3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/728Switch to C++14 standard deprecation attribute2019-06-27T12:01:54ZTimo Kochtimokoch@math.uio.noSwitch to C++14 standard deprecation attributeSince C++14 there is a portable way of marking entities as deprecated(https://en.cppreference.com/w/cpp/language/attributes/deprecated) using a standard attribute. This means we no longer need to use the macro from the Dune header dune/c...Since C++14 there is a portable way of marking entities as deprecated(https://en.cppreference.com/w/cpp/language/attributes/deprecated) using a standard attribute. This means we no longer need to use the macro from the Dune header dune/common/deprecated.hh.
I think it makes sense to switch to the new standard C++ way.Farid MohammadiFarid Mohammadihttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/729Timeout with grid data communication and parallel alugrid (Dune master only)2019-09-10T12:19:37ZTimo Kochtimokoch@math.uio.noTimeout with grid data communication and parallel alugrid (Dune master only)<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
test_gridmanager_gmsh_3d_alu_parallel fails on dune master with a timeout.
**Environment**:
- Dune version: mas...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
test_gridmanager_gmsh_3d_alu_parallel fails on dune master with a timeout.
**Environment**:
- Dune version: master
- DuMux version: master
- Others: gcc and clang3.1Bernd FlemischBernd Flemischhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/730Partial numerical differentiation2020-03-16T20:37:52ZMartin SchneiderPartial numerical differentiationIt would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is indepen...It would be nice to have the possibility in Dumux to choose which equation
is differentiated with respect to which variable.
For example if we solve a richardsni problem where we assume that the solution of richards equation
is independent of the temperature (e.g. if densities and viscosities are constant)
we do not need to calculate the derivatives of richards equation with respect to temperature.
This could be realized by introducing some table that lists if `eqIdx` should be differentiated
with respect to `pvIdx`. Furthermore, this could also help to decouple problems or to implement other solvers than Newton's method.Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/731sincos-test fails because numpy is not available on buildbot2019-06-27T18:07:59ZSimon Emmertsincos-test fails because numpy is not available on buildbot<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `test_ff_navierstokes_sincos` fails (only!) on buildbot
**What happened / Problem description**:
The `conver...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
The `test_ff_navierstokes_sincos` fails (only!) on buildbot
**What happened / Problem description**:
The `convergencetest.py` includes numpy, but numpy is not available on buildbot. We should try to get rid of numpy in this case. I did not look into the files yet, but the other convergence tests do not need numpy and were desigend to work without numpy.
According to @timok installing numpy on buildbot is not wanted because it is quite large.
**Environment**:
- Dune version: master
- DuMux version: master
- Others: gcc, Python version: 2.7.93.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/732test_ff_stokes_channel_3d fails with different velocity2019-07-01T07:32:34ZSimon Emmerttest_ff_stokes_channel_3d fails with different velocity<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
`test_ff_stokes_channel_3d fails`with different velocity
**What happened / Problem description**:
!1637 changed ...<!--
This form is for bug reports ONLY!
If you're looking for help check out the [readme](/README.md).
-->
**Bug report**
`test_ff_stokes_channel_3d fails`with different velocity
**What happened / Problem description**:
!1637 changed the handling of inflow/outflow BC and adapted the reference solution, yet the test fails on buildbot with
```
Data differs in parameter: velocity_liq (m/s)_1
Difference is too large: 199.76% -> between: -1.65925e-12 and 1.6632e-12
Info for velocity_liq (m/s)_1: max_abs_parameter_value=6.83831e-12 and min_abs_parameter_value=0.0.
For parameter velocity_liq (m/s)_1 a zero value threshold of 1e-12 was given.
Data differs in parameter: velocity_liq (m/s)_2
Difference is too large: 127.12% -> between: -4.17537e-13 and 1.53955e-12
Info for velocity_liq (m/s)_2: max_abs_parameter_value=1.89138e-12 and min_abs_parameter_value=0.0.
For parameter velocity_liq (m/s)_2 a zero value threshold of 1e-12 was given.
Test #17: test_ff_stokes_channel_3d ...............................***Failed 1.62 sec
```
**How to reproduce it (as minimally and precisely as possible)**:
Dune and DuMuX master, compiling and running the test.
**Anything else we need to know?**:
Maybe @melaniel can state the version & compiler details she used when generating the reference. I will be trying to reproduce a result tomorrow morning, too. Maybe it is compiler/machine dependent.
**Environment**:
- Dune version: master
- DuMux version: master
- Others: gcc 5.3 & gcc 7.4.4 (but with vel_1: 196.66% and vel_2: 135.84% difference) 3.1https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/733Make MPFA handle zero coefficients (like effective diffusion coefficient)2020-03-26T18:18:57ZTimo Kochtimokoch@math.uio.noMake MPFA handle zero coefficients (like effective diffusion coefficient)The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix ...The following discussion from !1648 should be addressed:
- [ ] @timok started a [discussion](https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/merge_requests/1648#note_27837):
> before we merge this I think we have to fix first that MPFA can handle zero coefficients.3.2Dennis GläserDennis Gläserhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/734Make cakegridcreator work for the case that the well is not excluded from the...2019-11-11T20:40:11ZMartin SchneiderMake cakegridcreator work for the case that the well is not excluded from the gridAt the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the...At the moment it seems that the cakegridcreator only works if the well is
excluded from the grid. This allows to use cubic cells.
However, if the well is for example modelled using a line source, the well
should not be excluded from the grid.
Thus, it would be nice if this gridcreator could generate a grid where the well is not excluded.
This could be done by using prism cells at the well location.3.2Martin SchneiderMartin Schneiderhttps://git.iws.uni-stuttgart.de/dumux-repositories/dumux/-/issues/735How to document weaknesses/uncertainties2019-07-19T12:57:17ZMelanie LippHow to document weaknesses/uncertaintiesWe would like to find a common way of documenting code parts, that we are uncertain about how to do something. We do not want to use \TODO, as the case is to unlikely to put more time and effort into it. But we would like to keep in mind...We would like to find a common way of documenting code parts, that we are uncertain about how to do something. We do not want to use \TODO, as the case is to unlikely to put more time and effort into it. But we would like to keep in mind (and preferentially be able to create a list) those weaknesses for the case of future problems.