[petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED

[Dmitry Karpeev]

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>