June 2012 - petsc-dev - mailman3.cels.anl.gov

Re: [petsc-dev] Parallel Gauss - Seidel
by Barry Smith 09 Jun '12

09 Jun '12

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(a)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(a)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(a)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(a)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. > > > > > >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Jed Brown 09 Jun '12

09 Jun '12

He is going to alternate between smoothing some points and sending messages. On Jun 9, 2012 8:07 PM, "Barry Smith" <bsmith(a)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(a)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(a)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(a)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. > > > > > > >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Barry Smith 09 Jun '12

09 Jun '12

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(a)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(a)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(a)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. > > >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Jed Brown 09 Jun '12

09 Jun '12

Parallel Gauss-Seidel. On Jun 9, 2012 7:56 PM, "Barry Smith" <bsmith(a)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(a)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(a)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. > > > >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Barry Smith 09 Jun '12

09 Jun '12

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(a)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(a)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. >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Jed Brown 09 Jun '12

09 Jun '12

Fine, but I think Mark is going to change the IS every time MatSOR is called. 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(a)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(a)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. > >

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Barry Smith 09 Jun '12

09 Jun '12

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(a)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.

1 0

Re: [petsc-dev] Parallel Gauss - Seidel
by Jed Brown 09 Jun '12

09 Jun '12

On Sat, Jun 9, 2012 at 6:43 PM, Mark F. Adams <mark.adams(a)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. > 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.

1 0

Parallel Gauss - Seidel
by Mark F. Adams 09 Jun '12

09 Jun '12

I would like a parallel G-S to PETSc. I have to design questions: 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? 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. 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. Any thoughts? (that's a rhetorical question Jed). Mark

1 0

Re: [petsc-dev] Fwd: Heaps
by Jed Brown 09 Jun '12

09 Jun '12

On Sat, Jun 9, 2012 at 5:19 PM, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > Yup, there are truckloads of cool possibilities of alternatives here. Unfortunately, raising the arity doesn't seem to help, though it exposes more potential for optimization. http://petsc.cs.iit.edu/petsc/petsc-dev/rev/b06db6113ba9

1 0