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>
