<div class="gmail_quote">On Thu, Nov 18, 2010 at 23:12, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1yz">I'm not disagreeing, but I also don't see a general way of figuring<br>
out the off-rank<br>
columns for a submatrix that is destined to live on a subcomm.<br></div></blockquote><div><br></div><div>VecScatter figures out who is sending to who without allgathering everyone's indices. I realize it's a slightly different problem and I don't have a complete solution right now. And iscol often has some structure (even if just block).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":1yz">
Another point is that since we anticipate a submatrix is extracted on a subcomm,<br>
the size of the submatrix and the subcomm might not grow in the weak<br>
scaling case.<br></div></blockquote><div><br></div><div>That depends whether the subdomains are different materials or just solver-friendly subdomains (e.g. to reduce iterations in ASM and make overlap less expensive in 3D). Consider getting submatrices for Fluid and </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":1yz">The names are definitely an stop-gap fix: for consistency we'd have to change<br>
ISGetIndices --> ISGetLocalIndices, ISGetTotalIndices --><br>
ISGetIndices, VecGetArray --> VecGetLocalArray, etc.<br>
Maybe this will be done one day :-)</div></blockquote></div><br><div>I don't know, I like to endorse the domain decomposition philosophy and make the simple things (and in particular, storage) local by default, with parallel semantics where appropriate. In particular, you should have to spell out a word with non-scalable connotations in order to call a blatantly non-scalable function.</div>
<div><br></div><div>Jed</div>