Actually, I don't think this would require DM to know that much than it does now: DMDA has GlobalToLocal as well as VecGetArray, which provides both "restriction to local" (a coarse-granularity, heavy-weight operation), and "restrict to (a bunch of) stencil(s)" (a fine granularity lightweight "scatter"). This encapsulates your notions of a "local space" and an "extended space", which, clearly, require different access patterns.
On Tue, Dec 7, 2010 at 3:49 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > This would require the analog of MatMatMult for scatters. > It shouldn't be that hard (if only MatScatter supported some way of getting > out the "values"). > > > On Tue, Dec 7, 2010 at 3:47 PM, Jed Brown <jed at 59a2.org> wrote: > >> On Tue, Dec 7, 2010 at 22:37, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: >> >>> I may be out on a limb here, but the column DM could also encapsulate the >>> scatter >>> that currently sits in the Mat object. By default the row DM could have >>> an identity (noop) scatter. >>> >>> Note that this is very natural from the DD standpoint: >>> ASM/GASM/FieldSplit already define scatters that >>> scatter to a "subdomain" on which a matrix/pc operate. Currently, the >>> VecScatter inside the subdomain Mat >>> will further scatter the Vec to the "local" part, on which the matrix >>> then operates locally. If the scatter is moved >>> out of Mat and into its column DM, than this double scatter can be >>> avoided. >>> >> >> Hmm, now the DM is starting to know a lot. There are times where I think >> fusing scatters is good, but this one sounds tricky. How would you >> implement this? >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101207/bd3c49d5/attachment.html>
