[petsc-dev] DMDA_*PERIODIC and DMDA_XYZGHOSTED

[Dmitry Karpeev]

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.

The pattern "scatter to the local part, then apply the local matrix there"
becomes part of a more general pattern:
"scatter to a subdomain, apply the subdomain matrix there", where "local" is
an instance of "subdomain".

On Tue, Dec 7, 2010 at 3:27 PM, Jed Brown <jed at 59a2.org> wrote:

> On Tue, Dec 7, 2010 at 22:00, Barry Smith <bsmith at mcs.anl.gov> wrote:
>
>> PetscLayout is like the DMSliced, there is simply no interconnectivity
>> information because it is not needed or not available. It tells enough
>> information to serve as a factory for Flat Euclidean space in the same way
>> that DMDA serves as a factory for slightly more complicated layout.
>
>
> Okay, I agree now.  And Mat would then naturally have a "row" and "column"
> DM (making MatGetVecs for non-standard DMs trivial).  It's not clear to me
> what this semantic information allows, but a linear transformation, in an
> abstract sense, is a map between spaces, so it's mathematically sound to
> have the linear transformation (Mat) know about the spaces.)
>
> There is that little detail of PetscLayout currently being an "open"
> object.
>
> Jed
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101207/23575ffa/attachment.html>