Re: [DuMux] Oil-gas compositional simulation in DuMux
Yes, Dmitry, please do consider Bernd's suggestions. It would be appreciated by more than one. Best regards On Fri, Mar 18, 2022, 2:24 AM Dmitry Pavlov wrote: > Bernd, > > > Thank you. I will check with my managers regarding what I can do about > publishing the code. The completeFluidState in my code is not a branch, but > a method in a dedicated VolumeVariables variant which is assigned to the > Problem via TypeTag. One "potential complication" that I can see is that > the code in its present form is not going to be accepted into DuMux source > because it does not comply with DuMux's C++ guidelines (that happened > before with my merge requests). So either I will have to re-write it, or > someone else will, or it will stay as an example/prototype outside DuMux > source tree. > > > To elaborate on my statement about complications with 2pnc PVS model: > imagine that at one moment, you have a two-phase configuration: > > > pressure, saturation, (n-2) mole fractions in one of the phases > > > and then you run the Newton method, and then the Newton method orders to > increase the pressure, leaving other variables intact: > > > pressure + delta, saturation, (n-2) mole fractions in one of the phases > > > It can happen that with the increased pressure, the two-phase > configuration is to become one-phase. It is very hard, if possible, to > figure that basing just on (n-2) mole fractions and the saturation. The > saturation without the (original, two-phase-compatible) pressure is > meaningless. And the old value or pressure is "lost" at this point. How to > even guess the total mole fractions in this situation? I do not know. > > > I imagine that a very intricate relay between the Newton method and > PrimaryVariableSwitch could, in principle, allow to slowly approach the > phase transition point and then change the primary variables... but there > is no need to do that in presence of "classic" flash that works so well and > converges so well. (I also have to say that figuring out the fluid state > from the "pressure, saturation, n-2 mole fractions" is a big convergence > pain). > > > > Best regards, > > > Dmitry > > > > > On 3/18/22 09:57, Flemisch, Bernd wrote: > > Hi Dmitry, > > > thank you for your report, this is very valuable! > > > It would be even more valuable and highly appreciated if you decide to add > your model to DuMux. As far as I can see, this would in essence add the > Michelsen test and your flash calculation. And the completeFluidState > method would branch depending on whether the traditional "PVS" or the new > "flash" model is used. Right? Or do you see potential complications? > > > I consider your statement > > "The primary variables. Those must be the pressure and n-1 (overall) mole > fractions. I do not think that it is possible at all to implement a > two-phase compositional model with the usual primary variables of the 2pnc > model" > > very bold. The 2pnc PVS model is standard which has been used > successfully not only in DuMux to simulate two-phase compositional flow for > many years. > > > Nevertheless, I certainly acknowledge the fact that a flash-based model > might be superior for particular applications. With the drawback on > computational performance due to the more expensive flash calculations for > one Newton step. > > > In total, I would heartily encourage you to contribute your model! > > > Kind regards > > Bernd > > > -- > _ > > Bernd Flemisch > IWS, Universität Stuttgart phone: +49 711 685 69162 > Pfaffenwaldring 61 email: be...@iws.uni-stuttgart.de > D-70569 Stuttgart url: www.iws.uni-stuttgart.de/en/lh2/ > _ > -- > *Von:* DuMux > im Auftrag von Dmitry Pavlov > > *Gesendet:* Donnerstag, 17. März 2022 23:20:09 > *An:* dumux@listserv.uni-stuttgart.de > *Betreff:* [DuMux] Oil-gas compositional simulation in DuMux > > > Hello, > > This is for anybody who will be wondering someday whether the two-phase > oil-gas compositional model is doable in DuMux. The short answer is yes. > > The numerical algorithms required for such a model are described in many > sources (e.g. [1]) and implemented in ECLIPSE and a lot of other programs, > including the open-source MRST [2]. > > > Now, what is required for implementing the two-phase compositional model > in DuMux: > > 1. The primary variables. Those must be the pressure and n-1 (overall) > mole fractions. I do not think that it is possible at all to implement a > two-phase compositional model with the usual primary variables of the 2pnc > model [3] (pressure, saturation, n-2 mole fractions). But the good news is > that DuMux, for the most part, does not care about what is stored in the > primary variables. So it is possible to just treat 2pnc's primary variables > as the pressure and n-1 (overall) mole fractions. The only thing that must
[DuMuX] question for dumux-gentoo users
Hi, I just updated my gentoo box to 17.1 desktop profile and everything works fine, except for dumux. I get a crash which seems to be an invalid pointer to a basic string. This crash did not occur with gcc-8.2 but is now happening with gcc-9.2. Does anyone have a similar problem with gcc-9.2? Or maybe it is just an issue in my problem isource code which is handled differently in 9.2 versus 8.2? Opinions? Below I list the crash output which occurs in the pthread library (which works fine with other programs). best regards and happy new year! [cancer:23561] *** Process received signal *** [cancer:23561] Signal: Segmentation fault (11) [cancer:23561] Signal code: Address not mapped (1) [cancer:23561] Failing at address: 0x3 [cancer:23561] [ 0] /lib64/libpthread.so.0(+0x14680)[0x7fcb327ce680] [cancer:23561] [ 1] /lib64/libc.so.6(+0xa9f85)[0x7fcb31823f85] [cancer:23561] [ 2] /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/libstdc++.so.6(_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEaSEOS4_+0x98)[0x7fcb31c1dd48] [cancer:23561] [ 3] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux11EpisodeDataINS_10Properties4TTag14LSWFBoxTypeTagEE12getStageDataEiPPKc+0x307)[0x55765072a4c3] [cancer:23561] [ 4] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux11EpisodeDataINS_10Properties4TTag14LSWFBoxTypeTagEE4initEPPKc+0x8f)[0x557650719a7b] [cancer:23561] [ 5] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux8LswiDataINS_10Properties4TTag14LSWFBoxTypeTagEEC1Ev+0x86)[0x557650706328] [cancer:23561] [ 6] /home/GIT/LSWF/projects/lswi-dumux-n//build-cmake/src/lswi-dumux-n(_ZN5Dumux21LSWF2pncSpatialParamsINS_10Properties4TTag14LSWFBoxTypeTagEEC1ESt10shared_ptrIKNS_17BoxFVGridGeometryIdN4Dune8GridViewINS7_25DefaultLeafGridViewTraitsIKNS7_8YaspGridILi2ENS7_22EquidistantCoordinatesIdLi2ELb0ENS_28BoxDefaultGridGeometryTraitsISG_NS_19DefaultMapperTraitsISG_NS7_35MultipleCodimMultipleGeomTypeMapperISG_NS7_4Impl14MCMGFailLayoutEEESM_EEE+0x2c)[0x55765074514e] -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] replacing outflow BC condition in legacy 2.12 code
Hello all, I understand the the boundary type specification"outflow" has been removed from the current version of DuMux. I see that an outflow is now to be specified by constructiong the element solution, evaluating the gradient and calculating the flux. In an example I see that the templates for elementSolution and evalGradients are used. I am quite sure that a similar approach can be used somehow in 2.12 if I knew exactly where to start looking. Am I right? If so, where should I start looking? best regards, Edscott I -- ---- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] SOLVED memory corruption in brookscorey.hh?
The problem seems to be a bug in gcc or gdb, because it happens with gcc-6.3.1/gdb-7.12.1 and no longer occurs in gcc-8.2./gdb-8.1.1. And it seems to only be related to gdb since when the program runs without gdb, the results of the simulation are identical to that which results from the executable created with gcc-8.2. Anyways I've created and uploaded a docker image with dumux-2.12 with gcc-8.2 at the docker hub, The image is impmx/dumux-2.12:20180823 if anyone is interested. The docker files for the creation can be accessed at url = g...@github.com:edscott/dumux.git best regards! El mié., 22 de ago. de 2018 a la(s) 16:33, Christoph Grüninger ( f...@grueninger.de) escribió: > Hi Edscott, > you are right, you have to recompile the complete Dune stack with Clang > and the flags for the desired saninitzer. When you use a different build > directory, it is easy to switch back to your GCC-built stack. > > Hope this helps, > Christoph > > Am 22.08.2018 um 18:23 schrieb Edscott Wilson: > > Hi, Christoph, > > > > clang sounds good. I'll give it a try, But will I have to recompile dune > > with clang or will it be compatible with gcc generated .a libraries? > > > > Best Regards, > > > > Edscott > > -- > Unfortunately, plots are notoriously hard to get right. Partly, the > default settings of programs like gnuplot or Excel are to blame for > this since these programs make it very convenient to create bad plots. > -- Till Tantau, "The TikZ and PGF Packages" > ___ > Dumux mailing list > Dumux@listserv.uni-stuttgart.de > https://listserv.uni-stuttgart.de/mailman/listinfo/dumux > -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi, Christoph, clang sounds good. I'll give it a try, But will I have to recompile dune with clang or will it be compatible with gcc generated .a libraries? Best Regards, Edscott El mar., 21 de ago. de 2018 a la(s) 17:10, Christoph Grüninger ( f...@grueninger.de) escribió: > Hi Edscott, > give AddressSanitizer a try, it is a great tool to find such thing you > describe. Further MemorySanitizer and Undefined Behavior Sanitizer might > turn out to be helpful, too. My best experience with these tools were > when I used the latest Clang compiler. Some of them work with recent > versions of GCC very well, too. > Valgrind might be worth a try. But it has more false positives and the > output is more difficult to understand. > > Kind regards, > Christoph > > Am 21.08.2018 um 18:10 schrieb Edscott Wilson: > > OK. > > I'll dig into the matter a bit further to see if I can solve where the > > problem arises. It might be an incorrect cast somewhere that screws up > > memory locations. > > > > Best regards, > > > > Edscott > > > > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd > > > <mailto:bernd.flemi...@iws.uni-stuttgart.de>>: > > > > Hi Edscott, > > > > can you please open an issue at > > https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues > > <https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues> ? > > Due to holiday season, it might take us some time to look at this. > > By opening an issue, it won't be forgotten. > > > > Kind regards > > Bernd > > > > Von: Edscott Wilson > > Gesendet: Donnerstag, 16. August, 23:47 > > Betreff: [DuMuX] memory corruption in brookscorey.hh? > > An: DuMuX User Forum > > > > > > This is weird and should not be happening. I explain. > > > > While debugging a generalized Dirichlet type problem, I am > > encountering a problem with the BrooksCorey material law > > (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). > > > > Here is the code from brookscorey.hh: > > > > 181 using std::min; > > 182 using std::max; > > 183 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > 185 > > 186 return pow(swe, 2.0/params.lambda() + 3); > > 187 } > > > > Inserting a break before the min(max()) call, I examine the value of > > swe: > > > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey > Dumux::RegularizedBrooksCoreyParams >::krw (params=..., > > swe=6.9319619419652626e-17) at > > > > /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 > > 184 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defined for 0.0 <= sw <= 1.0 > > (gdb) print swe > > $11 = 6.9319619419652626e-17 > > > > > > Then I step over the min(max() call and re-examine swe and get a > > corrupted value: > > > > (gdb) next > > 186 return pow(swe, 2.0/params.lambda() + 3); > > (gdb) print swe > > $12 = -3.9159195083267944e+240 > > > > Stepping into the min(max()) function I see that the value which > > should be "1.0" arrives corrupted: > > > > (gdb) > > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > > __b=@0x7fffae10: -3.9159195083267944e+240) > > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > > 200 if (__b < __a) > > (gdb) print __b > > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > > > > Looks like the "1.0" is being placed on the stack and being > > optimized away after the max() part completes. > > > > Doing some changes to the code and doing the simple eff2abs law > > conversion within the regularizedbrooksCorey class template, the > > problem disappears, as the following gdb output shows: > > > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV > Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > > swe=6.9319619419652626e-17, iS=4.22627533) at > > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > > 91 swe = min(max(swe, 0.0), 1.0); // the equation below > > is only defin
Re: [DuMuX] memory corruption in brookscorey.hh?
Hi Timo, Problem occurs exactly the same way with or without -O0. In order to test whether problem only occurs with gdb, I add line 185 and run. brookscorey.hh: 184swe = min(max(swe, 0.0), 1.0); // the equation below is only defined for 0.0 <= sw <= 1.0 185std::cerr<<"swe returns with: "< Dear Edscott, > > what was your actual problem you are trying to solve? Is this a problem > with Dumux? The code you are showing looks perfectly fine to me. > > Or was this just occurring during debugging? Your comments sound like you > are debugging optimized code. If yes, is there any problem if the code is > compiled with -O0? Not all symbols are always defined if there are > optimized away so it might look like this. > > Timo > > > > Viele Grüße, > Timo > Am 21.08.2018 um 20:40 schrieb Edscott Wilson < > edscott.wilson.gar...@gmail.com>: > > OK. > I'll dig into the matter a bit further to see if I can solve where the > problem arises. It might be an incorrect cast somewhere that screws up > memory locations. > > Best regards, > > Edscott > > > 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < > bernd.flemi...@iws.uni-stuttgart.de>: > >> Hi Edscott, >> >> can you please open an issue at >> https://git.iws.uni-stuttgart.de/dumux-repositories/dumux/issues ? Due >> to holiday season, it might take us some time to look at this. By opening >> an issue, it won't be forgotten. >> >> Kind regards >> Bernd >> >> Von: Edscott Wilson >> Gesendet: Donnerstag, 16. August, 23:47 >> Betreff: [DuMuX] memory corruption in brookscorey.hh? >> An: DuMuX User Forum >> >> >> This is weird and should not be happening. I explain. >> >> While debugging a generalized Dirichlet type problem, I am encountering a >> problem with the BrooksCorey material law >> (dumux/material/fluidmatrixinteractions/2p/brookscorey.hh). >> >> Here is the code from brookscorey.hh: >> >> 181 using std::min; >> 182 using std::max; >> 183 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> 185 >> 186 return pow(swe, 2.0/params.lambda() + 3); >> 187 } >> >> Inserting a break before the min(max()) call, I examine the value of swe: >> >> Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey> Dumux::RegularizedBrooksCoreyParams >::krw (params=..., >> swe=6.9319619419652626e-17) at >> /opt/dune/include/dumux/material/fluidmatrixinteractions/2p/brookscorey.hh:184 >> 184 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) print swe >> $11 = 6.9319619419652626e-17 >> >> >> Then I step over the min(max() call and re-examine swe and get a >> corrupted value: >> >> (gdb) next >> 186 return pow(swe, 2.0/params.lambda() + 3); >> (gdb) print swe >> $12 = -3.9159195083267944e+240 >> >> Stepping into the min(max()) function I see that the value which should >> be "1.0" arrives corrupted: >> >> (gdb) >> std::min (__a=@0x7fffae00: 6.9319619419652626e-17, >> __b=@0x7fffae10: -3.9159195083267944e+240) >> at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 >> 200 if (__b < __a) >> (gdb) print __b >> $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 >> >> >> Looks like the "1.0" is being placed on the stack and being optimized >> away after the max() part completes. >> >> Doing some changes to the code and doing the simple eff2abs law >> conversion within the regularizedbrooksCorey class template, the problem >> disappears, as the following gdb output shows: >> >> Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV> Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., >> swe=6.9319619419652626e-17, iS=4.22627533) at >> /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 >> 91 swe = min(max(swe, 0.0), 1.0); // the equation below is >> only defined for 0.0 <= sw <= 1.0 >> (gdb) step >> std::max (__a=@0x7fffade0: 6.9319619419652626e-17, >> __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 >> 224 if (__a < __b) >> (gdb) next >> 226 return __a; >> (gdb) >> 227 } >> (gdb) >> Dumux::BrooksCoreyV >> >::krw (params=..., swe=6.93
Re: [DuMuX] memory corruption in brookscorey.hh?
OK. I'll dig into the matter a bit further to see if I can solve where the problem arises. It might be an incorrect cast somewhere that screws up memory locations. Best regards, Edscott 2018-08-17 15:31 GMT-05:00 Flemisch, Bernd < bernd.flemi...@iws.uni-stuttgart.de>: > Hi Edscott, > > can you please open an issue at https://git.iws.uni-stuttgart. > de/dumux-repositories/dumux/issues ? Due to holiday season, it might take > us some time to look at this. By opening an issue, it won't be forgotten. > > Kind regards > Bernd > > Von: Edscott Wilson > Gesendet: Donnerstag, 16. August, 23:47 > Betreff: [DuMuX] memory corruption in brookscorey.hh? > An: DuMuX User Forum > > > This is weird and should not be happening. I explain. > > While debugging a generalized Dirichlet type problem, I am encountering a > problem with the BrooksCorey material law (dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh). > > Here is the code from brookscorey.hh: > > 181 using std::min; > 182 using std::max; > 183 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > 185 > 186 return pow(swe, 2.0/params.lambda() + 3); > 187 } > > Inserting a break before the min(max()) call, I examine the value of swe: > > Thread 1 "lswf-chem11" hit Breakpoint 2, Dumux::BrooksCorey RegularizedBrooksCoreyParams >::krw (params=..., > swe=6.9319619419652626e-17) at /opt/dune/include/dumux/material/ > fluidmatrixinteractions/2p/brookscorey.hh:184 > 184 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) print swe > $11 = 6.9319619419652626e-17 > > > Then I step over the min(max() call and re-examine swe and get a corrupted > value: > > (gdb) next > 186 return pow(swe, 2.0/params.lambda() + 3); > (gdb) print swe > $12 = -3.9159195083267944e+240 > > Stepping into the min(max()) function I see that the value which should be > "1.0" arrives corrupted: > > (gdb) > std::min (__a=@0x7fffae00: 6.9319619419652626e-17, > __b=@0x7fffae10: -3.9159195083267944e+240) > at /usr/include/c++/6.3.1/bits/stl_algobase.h:200 > 200 if (__b < __a) > (gdb) print __b > $16 = (const double &) @0x7fffae10: -3.9159195083267944e+240 > > > Looks like the "1.0" is being placed on the stack and being optimized away > after the max() part completes. > > Doing some changes to the code and doing the simple eff2abs law conversion > within the regularizedbrooksCorey class template, the problem disappears, > as the following gdb output shows: > > Thread 1 "lswf-chem11" hit Breakpoint 3, Dumux::BrooksCoreyV Dumux::RegularizedBrooksCoreyVParams >::krw (params=..., > swe=6.9319619419652626e-17, iS=4.22627533) at > /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:91 > 91 swe = min(max(swe, 0.0), 1.0); // the equation below is > only defined for 0.0 <= sw <= 1.0 > (gdb) step > std::max (__a=@0x7fffade0: 6.9319619419652626e-17, > __b=@0x7fffadf8: 0) at /usr/include/c++/6.3.1/bits/stl_algobase.h:224 > 224 if (__a < __b) > (gdb) next > 226 return __a; > (gdb) > 227 } > (gdb) > Dumux::BrooksCoreyV > >::krw (params=..., swe=6.9319619419652626e-17, iS=4.22627533) > at /home/edscott/GIT/LSWF/include/2pncs/materiallaw/brookscoreyV.hh:92 > 92 return pow(swe, 2.0/params.lambda(iS) + 3); > (gdb) print swe > $18 = 6.9319619419652626e-17 > > > Opinions? > > Could there be something amiss in the EffToAbsLaw class template? > > Or could it be a gcc bug? (using "gcc (GCC) 6.3.1 20170109" and "GNU gdb > (GDB) 7.12.1"). > > I tried to use gdb within a docker container with "gcc (GCC) 7.3.1 > 20180312" and "GNU gdb (GDB) 8.1" but I get: > > (gdb) run > Starting program: /home/dumux/projects/lswf-chem11-USE_BC-CACO3_CASO4_ > MGCO3-SIMPLIFIED-UMF/build-cmake/src/lswf-chem11 -ParameterFile > ../SW-b.input > warning: Error disabling address space randomization: Operation not > permitted > warning: Could not trace the inferior process. > Error: > warning: ptrace: Operation not permitted > During startup program exited with code 127. > > Has anybody had luck debugging with gdb within a docker container? > > > The full g++ compiler command is as follows: > > /usr/bin/c++ -Wno-deprecated -ggdb -I/home/dumux/problems/lswf-chem11 > -I/home/dumux/include -I/home/dumux -I/opt/dune/include -DUSE_BC > -DCACO3_CASO4_MGCO3 -DSIMPL
[DuMuX] bug in 2.12 constraintsolvers/CMakeFiles.txt
Hi Timo, Seems like a mistake in dumux/dumux/material/constraintsolvers/CMakeFiles.txt, because files that were present in 2.11 are gone in 2.12 but not removed from CMakeFiles.txt, which causes the make install to fail when the dumux repository is cloned from branch releases/2.12 during construction of the docker image. I worked around it with: sed 's/computefromreferencephase2pnc.hh//' dumux/dumux/material/constraintsolvers/CMakeLists.txt | sed 's/computefromreferencephase2pncmin.hh//' | sed 's/compositionfromfugacities2pncmin.hh//' Best regards, Edscott -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
[DuMuX] new archlinux based docker images
Hi all, I've just uploaded docker images for dumux-2.12 based on archlinux in the docker hub repository https://hub.docker.com/r/impmx/dumux-2.12. Later I will be uploading an image with an example on how to work an example by means of python script, which I have now fully tested. In the full description of the impmx/docker-2.12 you will find the script with which to fire the containers. Sandboxed users should use the tag latest or user, while modifications to the system should be done with the root tag. Docker files to create the images are also included in /usr/local/src for reference. BTW, Timo, I've tested the paraview in the dumux/release-2.12 image on an Ubuntu12.04 box, and the initial window opens, but on mouse action the application crashes. I suppose it is because paraview wants to access the video card directly and this is different on different boxes. Anyways, we prefer to run paraview after the simulation is done on the host machine, and that is where the shared directory comes into play. best regards, Edscott -- Dr. Edscott Wilson Garcia Reservoir Engineering Mexican Petroleum Institute ___ Dumux mailing list Dumux@listserv.uni-stuttgart.de https://listserv.uni-stuttgart.de/mailman/listinfo/dumux
Re: [DuMuX] DuMux and Docker
Hi Timo,
I can now access dumux-repositories/dumux-docker without any problems,
thanks!. What I find is that graphics support is mostly defined in the
dumux start script. But graphics does not start on an archlinux box unless
XAUTHORITY permission is granted for the docker container. This can be done
by applying the following patch to the startup script.
--- dumux.sh2018-01-17 15:43:42.818240499 -0600
+++ dumux-new.sh2018-01-17 15:43:58.718209994 -0600
@@ -29,11 +29,14 @@
open()
{
IMAGE="$1"
-
+XAUTH=/tmp/.docker.xauth
+`xauth nlist $DISPLAY | sed 's/^//' | xauth -f $XAUTH nmerge -`
COMMAND="docker create -i -t \
-e HOST_UID=$(id -u $USER) \
-e HOST_GID=$(id -g $USER) \
-e DISPLAY=$DISPLAY \
+ -v $XAUTH:$XAUTH \
+ -e XAUTHORITY=$XAUTH \
--device /dev/dri \
-v $SHARED_DIR_HOST:$SHARED_DIR_CONTAINER \
-v /tmp/.X11-unix:/tmp/.X11-unix:rw \
With that, paraview with initially opens, but then crashes with the
following:
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 394
vtkXOpenGLRenderWindow (0x20978a0): Could not find a decent visual
ERROR: In
/build/paraview-arsa8T/paraview-5.0.1+dfsg1/VTK/Rendering/OpenGL/vtkXOpenGLRenderWindow.cxx,
line 613
vtkXOpenGLRenderWindow (0x20978a0): GLX not found. Aborting.
Aborted (core dumped)
I guess that's because the host is an Archlinux box which is quite a deal
more updated than the debian container, maybe?
Nonetheless, since vtk files are shared and viewed after simulation
completes, we have no problem with using paraview on the docker host.
What we really want is to view gnuplot graphics as the simulation proceeds,
and that is now possible.
Using the shared X11 socket and XAUTHORIZATION stuff, we can now open
xterms from our container and view simulation graphs with gnuplot as the
computation proceeds. Still, installing gnuplot from package brings in too
much stuff to the container and fonts are missing. As soon as I fix those
details I will upload the docker image to the docker hub.
What follows is to create a dumux-3.0r1 image because we are very
interested in seeing how the assembler has been improved (the assembler
takes the lion's share of cpu time in our problem).
best regards,
Edscott
2018-01-17 3:49 GMT-06:00 Timo <koch_t...@hotmail.com>:
>
>
> Am 16.01.2018 um 20:58 schrieb Edscott Wilson <
> edscott.wilson.gar...@gmail.com>:
>
> Hi all,
>
> I've removed the docker container I mentioned in the previous post, as
> there was a mistake in the build. In that build the dune version was 2.6,
> which means it does compile with dumux-2.12, but when you try to link a
> problem, errors occur due to changes in the vtkwriter and other places.
> I've now uploaded a new docker with dumux-2.12 and dune-2.5 and tested it
> correctly. The "standard" way to enter this docker container is with the
> following script:
>
>
> Hi Edscott,
>
> Dune 2.6 was not released yet when Dumux 2.12 was released so it is not
> supported. The Dumux 3.0-alpha release however is compatible.
>
>
> #!/bin/sh
> version='dumux-2.12c'
> default=`pwd`
> echo "Welcome to $version (docker)"
> #read -p " Please specify src directory [$default]: " SRC
> if test x$SRC = x; then
> SRC=$default
> fi
> echo "Shared directory /home/dumux set to $SRC"
> echo "Creating docker container"
> docker rm $version-container
> docker create -ti -e USER=$USER -e HOST_GID=$(id -g $USER) -e
> HOST_UID=$(id -u $USER) -e SRC=$SRC -v $SRC:/home/dumux
> --name=$version-container --hostname=docker impmx/lswf:$version
> #mkdir "$SRC/output"
> exec docker start -a -i $version-container
>
> This opens the docker container with the same user as the invoker with
> read/write privileges in the current and shared directory. If you open the
> container without the enironment defined in the script, the user will be
> root and no shared directories. Dune and dumux are installed in /opt and
> the path and compile flags are ser accordingly. This is to keep user
> problems separate from dune/dumux core, as is customary for distributed
> software.
>
>
> This is one approach especially when you are only working with release
> versions. Another approach that is by far the more popular in the Dune
> community is creating your own dune-module. This way the user files are
> always separated from the main program. Then it doesn't matter if you
> decide to compile Dune from source (the you can keep up with the newest
> changes) or even install Dune with the Debian packages.
>
> User does not have write permissions in opt, but since the include path
> can be defi
Re: [DuMuX] DuMux and Docker
Hi all, I've removed the docker container I mentioned in the previous post, as there was a mistake in the build. In that build the dune version was 2.6, which means it does compile with dumux-2.12, but when you try to link a problem, errors occur due to changes in the vtkwriter and other places. I've now uploaded a new docker with dumux-2.12 and dune-2.5 and tested it correctly. The "standard" way to enter this docker container is with the following script: #!/bin/sh version='dumux-2.12c' default=`pwd` echo "Welcome to $version (docker)" #read -p " Please specify src directory [$default]: " SRC if test x$SRC = x; then SRC=$default fi echo "Shared directory /home/dumux set to $SRC" echo "Creating docker container" docker rm $version-container docker create -ti -e USER=$USER -e HOST_GID=$(id -g $USER) -e HOST_UID=$(id -u $USER) -e SRC=$SRC -v $SRC:/home/dumux --name=$version-container --hostname=docker impmx/lswf:$version #mkdir "$SRC/output" exec docker start -a -i $version-container This opens the docker container with the same user as the invoker with read/write privileges in the current and shared directory. If you open the container without the enironment defined in the script, the user will be root and no shared directories. Dune and dumux are installed in /opt and the path and compile flags are ser accordingly. This is to keep user problems separate from dune/dumux core, as is customary for distributed software. User does not have write permissions in opt, but since the include path can be defined by the user, local user versions of model.hh or components or fluidsystems can be redefined on a problem by problem basis. One of the goals of having this docker container is to have more dumux users in our workgroup where these users do not have to fret with the issue of downloading, compiling and installing, which does require a certain level of sophistication which has nothing to do with solving a PDE system. Thus if you run this docker image.and provide any comments or feedback, it will be greatly appreciated. Otherwise, if you find it useful, that makes us happy too. This container still does not have graphic support enabled yet, but that is coming soon. In case you missed it, the image is at the docker hub, repository impmx/lswf with tag dumux-2.12c. The docker file is very much similar to the previous post, but if you want to see the differences, just let me know. Best regards, Edscott 2018-01-11 17:05 GMT-06:00 Ed Scott Wilson Garcia <edsc...@imp.mx>: > Hi Timo, > > > > The Dockerfile at (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux-docker) is not available for the general public, 404 > error (file not found or insufficient permissions). > > > > But I’ve now build a new Dumux docker image with a dockerfile, which is > much more efficient than what I was doing previously. I’m attaching the > dockerfile if you want to use it for the DockerHub group for DuMux. The > docker image dumux-2.12 built thus at https://hub.docker.com/r/ > impmx/lswf/tags/ > > Has the following characteristics: > > > Built with base/archlinux (jan-11-18) Dune-2.5 and Dumux-2.12.0. > compiled with gcc-7.2.1, cmake-3.10.1, > Dune release/2.5 modules: dune-common, dune-geometry, dune-uggrid, > dune-grid, dune-istl, dune-localfunctions, dune-spgrid, dune-alugrid (head). > With openmpi-3.0.0, superLU, UMFpack, SuiteSparse and many other optional > packages. > > > > Next I will see how to enable graphics support by studying the information > you mention in your post. > > > > Best regards, > > > > Edscott > > > > > > > > *De:* Dumux [mailto:dumux-boun...@listserv.uni-stuttgart.de] *En nombre > de *Timo Koch > *Enviado el:* miércoles, 3 de enero de 2018 10:47 a. m. > *Para:* DuMuX User Forum; Edscott Wilson > *Asunto:* [DuMuX] DuMux and Docker > > > > Hi Edscott, > > > > I'm writing you as a follow-up on your post on the DUNE mailing list. > > You mention that you use DuMux with Docker. I just wanted to mention a > couple of things you might find useful: > > * There is a Dockerfile (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux-docker) available to build a docker container with > graphic support. I must warn though that it is a bit old. I will update as > soon as I get to it. > > * There is a script (https://git.iws.uni-stuttgart.de/dumux- > repositories/dumux/blob/master/bin/moduleutil/createdockerimage.sh) that > creates a Docker container of an extracted DUNE module which is new in the > dumux-pub project (https://git.iws.uni-stuttgart.de/dumux-pub). The > Docker container built in this script also fixes the user permissions for > transferring files in and out of containers and has graphic support
