[petsc-users] MUMPS failure

[Sanjay Govindjee]

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 
>> <mailto: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 
>>>> <mailto:junchao.zhang at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Mar 22, 2021 at 1:39 PM Barry Smith <bsmith at petsc.dev 
>>>> <mailto: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
>>>>>     <mailto: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
>>>>>     <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/20210323/8c6c3396/attachment.html>