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>