[petsc-dev] Parallel Gauss - Seidel

[Jed Brown]

I think he wants to manage the messages at a higher level and call a matrix
kernel for the partial sweeps.

I would prefer to write the communication primitives so that GS for each
matrix format is simple.
On Jun 9, 2012 8:21 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:

>
> On Jun 9, 2012, at 8:18 PM, Jed Brown wrote:
>
> > He is going to alternate between smoothing some points and sending
> messages.
>
>  Fine but that is all INSIDE a single SOR sweep? So I was wrong to say
> PCSORSetIS() maps to MatSORSetIS() it is PCSORSSetISs() maps to
> MatSORSetISs() he won't be calling MatSOR() for each piece but ONCE for the
> whole process (yes the MatSOR_SeqAIJ() is more complicated in this case.
>
>   Barry
>
> >
> > On Jun 9, 2012 8:07 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> >
> > On Jun 9, 2012, at 8:01 PM, Jed Brown wrote:
> >
> > > Parallel Gauss-Seidel.
> >
> >   But if you know in advance the IS that you are providing (that
> determines the order of the nodes smoothed) then why would you change it
> the next iteration?  That is, if you are providing the IS then it is in no
> way asynchronous so that the fact that it is "parallel" Gauss-Seidel
> doesn't affect the ordering. Hence I consider your response humorous but
> non responsive :-)
> >
> >   Barry
> >
> >
> >
> >
> > >
> > > On Jun 9, 2012 7:56 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > >
> > > On Jun 9, 2012, at 7:47 PM, Jed Brown wrote:
> > >
> > > > Fine, but I think Mark is going to change the IS every time MatSOR
> is called.
> > >
> > >   Surely not.  What kind of weird-ass algorithm would that be?
> > >
> > >   Barry
> > >
> > > > Either will work, but a separate call is awkward if it's not useful
> to be persistent.
> > > >
> > > > On Jun 9, 2012 7:45 PM, "Barry Smith" <bsmith at mcs.anl.gov> wrote:
> > > >
> > > > On Jun 9, 2012, at 6:51 PM, Jed Brown wrote:
> > > >
> > > > > On Sat, Jun 9, 2012 at 6:43 PM, Mark F. Adams <
> mark.adams at columbia.edu> wrote:
> > > > > 1) I need a G-S kernel that takes an IS of indices to process and
> a flag to process them in forward or reverse order.  How should I proceed
> to do this.  Should I just clone sor?
> > > > >
> > > > > You are going to have several of these index sets? You could have
> a PCSORSetIS(). Probably need to add a MatOp for MatSORIS(). Barry might
> have other ideas.
> > > >
> > > >   PCSORSetIS() would then go down to MatSORSetIS() and then the call
> to MatSOR() would using the IS ordering if provided, otherwise use the
> default natural ordering?
> > > >
> > > >    I don't see  a need to add a MatSORIS().
> > > >
> > > >   Barry
> > > >
> > > >
> > > > >
> > > > > 2) I don't want to use Richardson iterations for G-S.  Should I
> make a G-S KPS method?  I don't want to take a residual in the iterator
> (KSP) and if symmetric G-S is requested then it should drive this I think.
> > > > >
> > > > > Look at PCApplyRichardson_SOR().
> > > > >
> > > > >  SOR does two sweeps in each application; I'm not wild about that
> because a good way to run G-S in a V(1,1) cycle is to do a forward sweep in
> pre smoothing and a backward sweep in post smoothing.
> > > > >
> > > > > Well, MatSOR() has this flag MatSORType that can specify forward
> and reverse. You have one PC for the down-smoother and another for the
> up-smoother, then configure one to be a forward sweep and the other to be
> reverse.
> > > >
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120609/ec5787f4/attachment.html>