[petsc-dev] Parallel Gauss - Seidel

[Barry Smith]

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.
>