In a pure Fortran code using -fdefault-integer-8 is probably fine. But MUMPS is a mixture of Fortran and C code and PETSc uses MUMPs C interface. The -fdefault-integer-8 doesn't magically fix anything in the C parts of MUMPS. I also don't know about MPI calls and if they would need editing.
I am not saying it is impossible to get it to work but one needs are to insure the C portions also switch to 64 bit integers in a consistent way. This may be all doable bit is not simply using -fdefault-integer-8 on MUMPS. Barry > On Mar 23, 2021, at 12:07 AM, Sanjay Govindjee <[email protected]> wrote: > > 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 >>> >> >
