
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 5, 2012, at 6:41 PM, Jed Brown wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Jan 5, 2012 at 17:13, Ravi Kannan <span dir="ltr"><<a href="mailto:rxk@cfdrc.com">rxk@cfdrc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Files are attached.</blockquote></div><br><div>Could you try attaching a debugger to get stack traces?</div><div><br></div><div>It is reducing to a smaller communicator for the coarse level. The processes are likely both hung later in gamg.c:createLevel(). Mark, the appearance is that all procs that call MPI_Comm_create() are also doing things on the newly created communicator, even though it will be MPI_COMM_NULL on processes that are not part of the subgroup. Also, I'm skeptical that you can get correct results with MatPartitioningSetAdjacency(mpart,adj) when mpart and adj are on different communicators. Those other rows of adj are not moved by MatPartitioningApply_Parmetis().</div></blockquote><div><br></div><div>This is scary having two communicators running around but the processors that are dropped out of the new communicator have no rows -- that is why they are dropped out.</div><div><br></div><div>There are several logical paths through this code and I fixed a bug looks like this one a few weeks ago, but looks like you have a configuration that I have not debugged yet.</div><div><br></div><div>It would be very useful if you could give me the lines that each processor is hung on.</div><div><br></div><div>Mark</div><br><blockquote type="cite">

<div><br></div><div>I must be confused about what is actually happening.</div>

</blockquote></div><br></body></html>