On Sep 1, 2013, at 1:57 PM, "Garth N. Wells" <[email protected]> wrote:

> On 1 September 2013 19:51, Barry Smith <[email protected]> wrote:
>> 
>> On Sep 1, 2013, at 1:44 PM, "Garth N. Wells" <[email protected]> wrote:
>> 
>>> On 1 September 2013 19:27, Matthew Knepley <[email protected]> wrote:
>>>> On Sun, Sep 1, 2013 at 1:07 PM, Satish Balay <[email protected]> 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 ;)

   Of course, but by doing this we "we've made it hard for them to use metis 
with mumps." So what is gained by making it harder, if nothing is gained in 
some other respect then we shouldn't make it harder just to chase some other 
packages higher version number.

   As I said, this kind of thing is going to be a constant pain.

   Barry

> 
> 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/[email protected]/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
>> 

Reply via email to