[petsc-dev] Problem with MUMPS+metis
    John Fettig 
    john.fettig at gmail.com
       
    Mon Feb 20 12:04:49 CST 2012
    
    
  
Bah, nevermind.  That was evidently a bug in GDB (debugging intel-compiled
executable).  The argument is non-null in idbc.
John
On Mon, Feb 20, 2012 at 1:01 PM, John Fettig <john.fettig at gmail.com> wrote:
> As a follow-up, if I break at the call to metis inside mumps
> (metis_nodend_), the argument adjncy=0x0.  I guess I'll be emailing the
> mumps list about this.
>
> Thanks,
> John
>
>
> On Mon, Feb 20, 2012 at 12:48 PM, John Fettig <john.fettig at gmail.com>wrote:
>
>> When I run MUMPS in parallel with parmetis ordering (icntl(28)=2,
>> icntl(29)=2), everything seems to work fine.  However, if I try to run it
>> serially it reverts back to metis ordering and seems to get caught in some
>> kind of infinite recursion.  I've run it through valgrind and attached the
>> output.  Also I attached it to a debugger and the stack is enormous when it
>> hangs, something like 10,000 frames deep.  You can sort of see that from
>> the valgrind output towards the end.
>>
>> My question is: who do you suspect to be at fault here?  Is it a bug in
>> MUMPS, metis, or PETSc?  My suspicion is MUMPS.  This is with the
>> PETSc-automatically compiled MUMPS, metis, and parmetis, retrieved today.
>>
>> Thanks,
>> John
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120220/a5d6598a/attachment.html>
    
    
More information about the petsc-dev
mailing list