Barry,
I am curious about your statement "does not work generically". If I
compile with -fdefault-integer-8,
I would assume that this produces objects/libraries that will use 64bit
integers. As long as I have not declared
explicit kind=4 integers, what else could go wrong.
-sanjay
PS: I am not advocating this as a great idea, but I am curious if there
or other obscure compiler level things that could go wrong.
On 3/22/21 8:53 PM, Barry Smith wrote:
On Mar 22, 2021, at 3:24 PM, Junchao Zhang <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Mar 22, 2021 at 1:39 PM Barry Smith <[email protected]
<mailto:[email protected]>> wrote:
Version of PETSc and MUMPS? We fixed a bug in MUMPs a couple
years ago that produced error messages as below. Please confirm
you are using the latest PETSc and MUMPS.
You can run your production version with the option
-malloc_debug ; this will slow it down a bit but if there is
memory corruption it may detect it and indicate the problematic
error.
One also has to be careful about the size of the problem
passed to MUMPs since PETSc/MUMPs does not fully support using
all 64 bit integers. Is it only crashing for problems near 2
billion entries in the sparse matrix?
"problems near 2 billion entries"? I don't understand. Should not
be an issue if building petsc with 64-bit indices.
MUMPS does not have proper support for 64 bit indices. It relies on
add-hoc Fortran compiler command line options to support to converting
integer to 64 bit integers and does not work generically. Yes, Fortran
lovers have been doing this for 30 years inside their applications but
it does not really work in a library environment. But then a big
feature of Fortran is "who needs libraries, we just write all the code
we need" (except Eispack,Linpack,LAPACK :=-).
valgrind is the gold standard for detecting memory corruption.
Barry
On Mar 22, 2021, at 12:56 PM, Chris Hewson <[email protected]
<mailto:[email protected]>> wrote:
Hi All,
I have been having a problem with MUMPS randomly crashing in our
program and causing the entire program to crash. I am compiling
in -O2 optimization mode and using --download-mumps etc. to
compile PETSc. If I rerun the program, 95%+ of the time I can't
reproduce the error. It seems to be a similar issue to this thread:
https://lists.mcs.anl.gov/pipermail/petsc-users/2018-October/036372.html
<https://lists.mcs.anl.gov/pipermail/petsc-users/2018-October/036372.html>
Similar to the resolution there I am going to try and increase
icntl_14 and see if that resolves the issue. Any other thoughts
on this?
Thanks,
*
*
*Chris Hewson*
Senior Reservoir Simulation Engineer
ResFrac
+1.587.575.9792
