<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">A type independent scatter would make my code simpler, faster, shorter. I reuse Mat scatters for all sorts of stuff and currently have to call scatter on each variable (stuffing ints in floats). <div><br></div><div><div><div><div>On Sep 20, 2011, at 12:22 PM, Matthew Knepley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Sep 20, 2011 at 8:43 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><div class="gmail_quote">On Tue, Sep 20, 2011 at 01:05, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@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">
It may very well be limiting with MatGetSubMatrix() for VI solvers.</blockquote></div><br></div><div>As I recall, the gather is used to identify which global columns out of the off-diagonal block are needed. Well, the process owning that part of the index set knows, so why not use the scatter for the off-diagonal block to mark the needed columns?</div>
<div><br></div><div>This seems quite straightforward when the submatrix is taking a local subset (not moving rows to different processes). This also takes care of the most common use case in fieldsplit.</div><div><br></div>
<div><br></div><div>This would be even nicer if we could move indices over the same channels as scalars. This comes up so frequently that I think we should build a type-independent scatter, something like</div><div><br></div>
<div>PetscScatterCreate(PetscLayout from,IS isfrom,PetscLayout to,IS isto,PetscScatter*);</div><div><br></div><div>PetscScatterBegin(PetscScatter,void *from,MPI_Datatype,void *to,MPI_Datatype,MPI_Op,ScatterMode);</div><div>
<br></div><div><br></div><div>The VecScatter API could be preserved, but the implementation would become a thin wrapper over this thing.</div>
</blockquote></div><br>Wait, a type-independent Scatter? The one I have been begging for for 7 years, and finally coded myself (see ParallelMapping.hh) suboptimally. I<div>would like to see VecScatter completely refactored. We need</div>
<div><br></div><div> - Flexible types</div><div> - Flexible combination function</div><div> - Better linkage to DM</div><div><br></div><div> Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>
</blockquote></div><br></div></div></body></html>