[petsc-users] MUMPS failure

[Fande Kong]

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 <s_g at berkeley.edu> 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 <s_g at berkeley.edu> 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 <junchao.zhang at gmail.com>
> wrote:
>
>
>
>
> On Mon, Mar 22, 2021 at 1:39 PM Barry Smith <bsmith at petsc.dev> 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 <chris at resfrac.com> 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
>>
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20210327/8abe223f/attachment-0001.html>