On Sat, Mar 27, 2021 at 10:55 AM Fande Kong <[email protected]> wrote:
> 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" . > We had a long conversation with the MUMPs developers about this and are aware of what it does. Thanks, Matt > 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 >>> >>> >>> >> >> >> >> -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
