[petsc-dev] METIS update -> MUMPS crash

[Garth N. Wells]

On 1 September 2013 19:51, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
> On Sep 1, 2013, at 1:44 PM, "Garth N. Wells" <gnw20 at cam.ac.uk> wrote:
>
>> On 1 September 2013 19:27, Matthew Knepley <knepley at gmail.com> wrote:
>>> On Sun, Sep 1, 2013 at 1:07 PM, Satish Balay <balay at mcs.anl.gov> wrote:
>>>>
>>>> I see the errors with valgrind - and I don't know the reason.  Perhaps
>>>> we should revert the metis/parmetis upgrade.. [unless someone can debug
>>>> this..]
>>>>
>>>> valgrind doesn't give errors with the older metis-5.0.2
>>>
>>>
>>> This looks like a MUMPS bug. I guess we should report to them that they are
>>> not
>>> actually compatible with the latest METIS release.
>>>
>>
>> MUMPS releases take place on glacial time scales. METIS is not a
>> required dependency for MUMPS, so to move the METIS version forward in
>> PETSc and not break MUMPS you could just configure MUMPS with only
>> SCOTCH, instead of with METIS and SCOTCH as is presently the case.
>
>    Yes but what if, for some reason, metis does a much better job for MUMPS on someone's problem than scotch; now we've made it hard for them to use metis with mumps.
>

Then they can build their own METIS ;)

Garth

>    Was there really a strong reason to upgrade metis the last time, beside "oh they made a release, let's upgrade PETSc to use it"?
>
>     Yes, this is going to be a constant pain if some packages are slow in upgrading to releases in other packages.
>
>    Barry
>
>>
>> Garth
>>
>>>    Matt
>>>
>>>>
>>>> Satish
>>>> -----------
>>>>
>>>>
>>>> On Sun, 1 Sep 2013, Garth N. Wells wrote:
>>>>
>>>>> I've been having trouble with MUMPS crashing since METIS was recently
>>>>> updated in
>>>>>
>>>>>    https://bitbucket.org/petsc/petsc/commits/67125ba
>>>>>
>>>>> The problem does not appear for very small problems, but for other
>>>>> problems it does. I can reproduce a crash with ex55
>>>>> (src/ksp/ksp/examples/tutorials/ex55.c):
>>>>>
>>>>>    ./ex55 -ksp_type preonly -pc_type lu -pc_factor_mat_solver_package
>>>>> mumps -ksp_view -ne 128
>>>>>
>>>>> For 'ne' less than about 50 it runs fine but crashes for anything
>>>>> bigger. Changing the LU solver to another package it runs fine.
>>>>> Backtrace below. The message
>>>>>
>>>>>    http://www.mail-archive.com/petsc-users@mcs.anl.gov/msg17695.html
>>>>>
>>>>> looks to be related.
>>>>>
>>>>> Garth
>>>>>
>>>>> ======= Backtrace: =========
>>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7f877c6f4a46]
>>>>>
>>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(gk_gkmcorePop+0x81)[0x7f877be7fcae]
>>>>>
>>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(gk_malloc_cleanup+0x3f)[0x7f877be6c418]
>>>>>
>>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(METIS_NodeND+0x6de)[0x7f877be9fa02]
>>>>>
>>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(metis_nodend_+0x48)[0x7f877be94ba8]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_195_+0x3720)[0x7f877e67ac40]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_26_+0x279c)[0x7f877e553d30]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_+0x2022)[0x7f877e638756]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_f77_+0x16eb)[0x7f877e51a567]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_c+0x12a5)[0x7f877e4f2fed]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(MatLUFactorSymbolic_AIJMUMPS+0xa88)[0x7f877dc00d11]
>>>>>
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(MatLUFactorSymbolic+0xb61)[0x7f877db6a82f]
>>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.soAborted (core dumped)
>>>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>