Bah, nevermind.  That was evidently a bug in GDB (debugging intel-compiled executable).  The argument is non-null in idbc.<br><br>John<br><br><div class="gmail_quote">On Mon, Feb 20, 2012 at 1:01 PM, John Fettig <span dir="ltr"><<a href="mailto:john.fettig@gmail.com">john.fettig@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<br>Thanks,<br>John<div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Mon, Feb 20, 2012 at 12:48 PM, John Fettig <span dir="ltr"><<a href="mailto:john.fettig@gmail.com" target="_blank">john.fettig@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>



<br>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.<br><br>



Thanks,<br>John<br><br>
</blockquote></div><br>
</div></div></blockquote></div><br>