<p>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.</p>
<div class="gmail_quote">On Jun 9, 2012 7:45 PM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Jun 9, 2012, at 6:51 PM, Jed Brown wrote:<br>
<br>
> On Sat, Jun 9, 2012 at 6:43 PM, Mark F. Adams <<a href="mailto:mark.adams@columbia.edu">mark.adams@columbia.edu</a>> wrote:<br>
> 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?<br>
><br>
> 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.<br>
<br>
   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?<br>
<br>
    I don't see  a need to add a MatSORIS().<br>
<br>
   Barry<br>
<br>
<br>
><br>
> 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.<br>

><br>
> Look at PCApplyRichardson_SOR().<br>
><br>
>  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.<br>
><br>
> 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.<br>

<br>
</blockquote></div>