There are some statements from MUMPS user manual http://mumps.enseeiht.fr/doc/userguide_5.3.5.pdf
" A full 64-bit integer version can be obtained compiling MUMPS with C preprocessing flag -DINTSIZE64 and Fortran compiler option -i8, -fdefault-integer-8 or something equivalent depending on your compiler, and compiling all libraries including MPI, BLACS, ScaLAPACK, LAPACK and BLAS also with 64-bit integers. We refer the reader to the “INSTALL” file provided with the package for details and explanations of the compilation flags controlling integer sizes. " It seems possible to build a full-64-bit-integer version of MUMPS. However, I do not understand how to build MPI with 64-bit integer support. From my understanding, MPI is hard coded with an integer type (int), and there is no way to make "int" become "long" . Thanks, Fande On Tue, Mar 23, 2021 at 12:20 PM Sanjay Govindjee <[email protected]> wrote: > I agree. If you are mixing C and Fortran, everything is *nota bene. *It > is easy to miss argument mismatches. > -sanjay > > On 3/23/21 11:04 AM, Barry Smith wrote: > > > 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]> > wrote: > > > > > On Mon, Mar 22, 2021 at 1:39 PM Barry Smith <[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]> 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 >> >> 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 >> >> >> > > > >
