<br><br><div class="gmail_quote">2012/9/19 Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Sep 19, 2012, at 8:42 AM, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
><br>
> > Uh, the PC shouldn't be putting any contribution in the null space of the operator.<br>
> ><br>
><br>
> The partially subassembled problem which defines the BDDC preconditioner inherits the kernel from the problem. This null space should propagate completely to the coarse problem and not on the dual space. To take care of, you only need to use a pseudo-inverse for the coarse solution, thus the choice of removing the coarse null space before and after the coarse solution step. At present, the outcome of PCApply_BDDC could have a nonzero component on the null space. In my experiences, this does not have an impact on the Krylov convergence, except for the fact that you need to use KSP_NORM_NATURAL for KSP tests (see src/ksp/ksp/examples/tutorials/ex59.c).<br>

<br>
</div>   This KSP_NORM_NATURAL  is a symptom of the problem,  I think you really do want to also have the usual removal of the null space after applying the preconditioner (for left preconditioning) like all other pre conditioners.<br>

<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br>Sorry to be misleading: I didn't already test ex59 in the pure neumann case using information passed in via PCBDDCSetNullSpace. I checked and now KSP_NORM_NATURAL is not needed anymore. But, sure, something can be missing in the implementation.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
   Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> ><br>
> > You have to do basically the same thing on coarse levels of multigrid. I guess what you're saying is that a side-effect of this treatment in BDDC is that the preconditioner already has zero component in the direction of the null space so the explicit removal is not necessary? If we're just trying to avoid the explicit projection in KSP_PCApply*, I would prefer to add an attribute to PC saying that it "handles the null space internally".<br>

> ><br>
> > (I hate having new implementation-specific interfaces that basically do the same thing from the user's perspective, thus I want to find a way for MatSetNullSpace() to do the right thing.)<br>
><br>
>    We could modify KSP_RemoveNullSpace() to inquire of the PC inside the KSP if the null space should be applied and BDDC could simply say no.<br>
><br>
><br>
> I agree with your solution. I was already inclined to do that, but I decided to don't change by myself the KSP interface; thus I temporary pass the null space info using PCBDDC APIs.<br>
><br>
>  --<br>
> Stefano<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Stefano<br>