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<double,
Dumux::RegularizedBrooksCoreyParams<double> >::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<double> (__a=@0x7fffffffae00: 6.9319619419652626e-17,
__b=@0x7fffffffae10: -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 &) @0x7fffffffae10: -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<double,
Dumux::RegularizedBrooksCoreyVParams<double> >::krw (params=...,

    swe=6.9319619419652626e-17, iS=4.2262753399999999) 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<double> (__a=@0x7fffffffade0: 6.9319619419652626e-17,
__b=@0x7fffffffadf8: 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<double, Dumux::RegularizedBrooksCoreyVParams<double>
>::krw (params=..., swe=6.9319619419652626e-17, iS=4.2262753399999999)

    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 -DSIMPLIFIED -DUMF   -pthread -rdynamic
CMakeFiles/lswf-chem11.dir/lswf-chem11.cc.o  -o lswf-chem11
-Wl,-rpath,/usr/lib/openmpi /opt/dune/lib64/libdunefem.a
/opt/dune/lib64/libdunealugrid.a /opt/dune/lib64/libdunegrid.a
/opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a
/opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a
/opt/dune/lib64/libdunecommon.a -lumfpack -lspqr -lldl -lcholmod -lamd
-lcamd -lcolamd -lccolamd -lsuitesparseconfig -pthread
/usr/lib/openmpi/libmpi.so -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so
-lz -lldl -lspqr -lumfpack -lcholmod -lamd -lcamd -lcolamd -lccolamd
-lsuitesparseconfig -lsuperlu -lblas -lparmetis -lmetis -lm -pthread
/usr/lib/openmpi/libmpi.so -lmetis -lm -lpsurface
/opt/dune/lib64/libdunegrid.a /opt/dune/lib64/libugS3.a
/opt/dune/lib64/libugS2.a /opt/dune/lib64/libugL.a
/opt/dune/lib64/libdunegeometry.a /opt/dune/lib64/libdunecommon.a
-lparmetis -lmetis -lm -pthread /usr/lib/openmpi/libmpi.so -lmetis -lm
-Wl,-Bstatic -lVc -Wl,-Bdynamic -lgmp -lgmpxx -llapack -lblas -pthread
/usr/lib/openmpi/libmpi.so /opt/dune/lib64/libdunefem.a
/opt/dune/lib64/libdunealugrid.a /opt/dune/lib64/libdunegrid.a
/opt/dune/lib64/libugS3.a /opt/dune/lib64/libugS2.a
/opt/dune/lib64/libugL.a /opt/dune/lib64/libdunegeometry.a
/opt/dune/lib64/libdunecommon.a -pthread -lpsurface -lmetis -lm -lz
-Wl,-Bstatic -lVc -Wl,-Bdynamic -lgmp -lgmpxx /usr/lib/openmpi/libmpi.so
-llapack -lblas



Any pointer would be greatly appreciated.



kind 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

Reply via email to