<div dir="ltr">Quick notes: you need to give the true null space as a "near null space" also.  The two methods don't try to talk to each other.  IT sounds like you are doing 2D so you want to add 3 near null space vectors.  Also, its not clear what interlaced is.  AMG really wants the order to be not makor and not equation major.<div>
Mark</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 11:27 AM, Stephan Kramer <span dir="ltr"><<a href="mailto:s.kramer@imperial.ac.uk" target="_blank">s.kramer@imperial.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, Mark and Jed for your comments. I have tried improving the eigenvalue bounds but that didn't seem to help much (the eigenvalues didn't change much either). Largest eigenvalues are indeed in the range 2-3. I also tried with richardson+sor smoothing instead of chebychev+sor and there I'm seeing the same thing: without calling MatSetBlockSizes() it converges in 57 iterations, if I do set the block size it takes an order more iterations (~600). So it looks like the problem is not in the eigenvalue estimates. Note that it is exactly the same matrix (so interlaced in both cases), only difference is me commenting out the calls to MatSetBlockSizes().<br>

<br>
The problem we're solving is a Stokes velocity solve in 2D in a cylindrical (annulus) domain with rapidly varying viscosity. The thing I should probably have mentioned before is that it's applying free slip on the sides, so the system is ill-posed. We supply a near-null space with the 3 different modes but also set a "true" nullspace (KSPSetNullSpace) with only the rotational mode. We did test the supplied vectors indeed using MatNullSpaceTest.<br>

<br>
It's quite possible of course we have a bug - so we'll continue investigating. On the other hand the performance without setting the block size is good so we're happy to continue with that as well. What I actually wanted to ask about - the previous was actually a bit tangent to that - is that we'd be quite keen to get a fix for the "zero-pivot on coarsened levels" problem merged in (e.g. the mark/gamg-zerod branch) as we have had better performance with cheby+sor than cheby+jacobi in cases we've looked at (this includes other cases than the above). Let us know if there's any way we can be helpful with that.<br>

<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
Stephan Kramer</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 17/08/14 16:10, Mark Adams wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
    The most common cause of this is inaccurate eigenvalue bounds.  You can<br>
    try using more iterations for estimation.<br>
<br>
<br>
I have also found that CG converges much faster than GMRES (default) so<br>
if you are SPD, I would always use:  '-gamg_est_ksp_type cg' .  Also,<br>
'-pc_gamg_verbose 2' will print out the eigenvalues that GAMG computes<br>
for smoothing.  With -ksp_view you will see the eigenvalues that Cheby<br>
is using (GAMG sets these so they should be the same if you use GAMG<br>
with pc_gamg_nsmooths>0). The largest eigenvalue should be around 2-3.<br>
  If it is too low (<2) then the instability that Jed is referring to<br>
would be the problem.<br>
<br>
You can also use more iterations, and see if it has converged, with<br>
-gamg_est_ksp_max_it N.  I think the default is 5.<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>