<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Sorry for getting to this late.  I think you have figured it out basically but there are a few things:</div><div><br></div><div>1) You must set the block size of A (bs=2) for the null spaces to work and for aggregation MG to work properly. SA-AMG really does not make sense unless you work at the vertex level, for which we need the block size.</div>
<div><br></div><div>2) You must be right that the zero column is because the aggregation produced a singleton aggregate.  And so the coarse grid is low rank.  This is not catastrophic, it is like a fake BC equations.  The numerics just have to work around it.  Jacobi does this.  I will fix SOR.</div>
<div><br></div><div>Mark</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"></div></div>
Ok, I found out a bit more. The fact that the prolongator has zero columns appears to arise in petsc 3.4 as well. The only reason it wasn't flagged before is that the default for the smoother (not the aggregation smoother but the standard pre and post smoothing) changed from jacobi to sor. I can make the example work with the additional option:<br>

<br>
$ ./ex49 -elas_pc_type gamg -mx 100 -my 100 -mat_no_inode -elas_mg_levels_1_pc_type jacobi<br>
<br>
Vice versa, if in petsc 3.4.4 I change ex49 to include the near nullspace (the /* constrain near-null space bit */) at the end, it works with jacobi (the default in 3.4) but it breaks with sor with the same error message as above. I'm not entirely sure why jacobi doesn't give an error with a zero on the diagonal, but the zero column also means that the related coarse dof doesn't actually affect the fine grid solution.<br>

<br>
I think (but I might be barking up the wrong tree here) that the zero columns appear because the aggregation method typically will have a few small aggregates that are not big enough to support the polynomials of the near null space (i.e. the polynomials restricted to an aggregate are not linearly independent). A solution would be to reduce the number of polynomials for these aggregates (only take the linearly independent). Obviously this has the down-side that the degrees of freedom per aggregate at the coarse level is no longer a constant making the administration more complicated. It would be nice to find a solution though as I've always been taught that jacobi is not a robust smoother for multigrid.<br>

<br>
Cheers<span class="HOEnZb"><font color="#888888"><br>
Stephan<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>