[petsc-users] MUMPS failure

[Matthew Knepley]

On Sat, Mar 27, 2021 at 10:55 AM Fande Kong <fdkong.jd at gmail.com> 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 <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
>>>
>>>
>>>
>>
>>
>>
>>

-- 
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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20210327/55798d4b/attachment-0001.html>