[petsc-users] unreliable AMG in PETSc

[Barry Smith]

> On Oct 23, 2014, at 2:54 AM, Arne Morten Kvarving <arne.morten.kvarving at sintef.no> wrote:
> 
>> 
>>    I ran you tests using the PETSc AMG solver -pc_type gamg (written largely by Mark Adams) using its default options and it converged for all your cases from 1 to 32 processes with no failure of positive definiteness etc.
> i can confirm it works fine with the default options. however, i can easily fault gamg as well - turn on richardson ksps and poof.
> 
> 27 - amg_14 (Failed)
> 
> 
> seems the use of chebyshev is a part of the cure, not just the agglomerator. in particular if i run ml with chebyshev the failures are reduced to
> 
> 43 - amg_22 (Failed)
> 45 - amg_23 (Failed)
> 53 - amg_27 (Failed)
> 61 - amg_31 (Failed)
> 63 - amg_32 (Failed)
> 
> unless my memory fails me, chebyshev is used to ensure the linear dependency of the preconditioner on the residual.

  No, both Richardson and Chebyshev are linear operators so this is not the issue.

> in particular it's a suitable iterative solver for the coarse solve.
> 
> so i think the fact that it cures things indicates that something breaks the linear property.

  No. 

   The problem in your cases is that the preconditioner operator (which is a V cycle of multigrid) with Richardson smoothing is an indefinite operator. That is inside the CG algorithm the computation of  R’ * B *R (where B is an application of the preconditioner) results in a negative number sometimes and sometimes a positive number. The CG algorithm requires that the preconditioner operator be positive definite (or negative definite) but it cannot be indefinite. 

   Now since your original matrix A is positive definite (and hence its inverse is positive definite), one would hope that a significantly close preconditioner would preserve the property of being positive definite (otherwise it is not a close approximation to the inverse). So loosely speaking using Richardson smoothing in this case results in a preconditioner that is not close enough to the inverse of A to preserve the positive definiteness and hence CG breaks down. Of course running with GMRES or any method that allows an indefinite preconditioner is fine. 

  Now I’ve never seen anybody write any analysis for why a preconditioner is not positive definite and how to fix it without just using a “stronger” preconditioner. That is, I don’t know how to “fix” an application of a preconditioner that is not positive definite in a general way. Note that for MG there are a variety of ways you can try to make the preconditioner “stronger” besides changing the smoother to Chebyshev. You could try 

1) using more smoothing steps
2) you could try a W cycle instead of V. -pc_mg_cycle_type w
3) you could use 2 V cycles for the preconditioner instead of 1 -pc_mg_multiplicative_cycles 2
4) you could try other GAMG options.

BTW: if you get segmentation violation type crashes in GAMG please report them so we can fix the problem. We cannot build a GAMG that will always converge for any problem but we really really really don’t want it crashing due to bugs in the code.


  Barry



> 
> hopefully the eigenvalue estimates aren't too expensive and i can run this setup on the real deal. will play.
> 
>> 
>>    That said the convergence rate is not super-great, around 70+ iterations and I did not run for timing comparisons. But
>> 
>> 75 iterations on 1 processors
>> 76 iterations on 16 processors
>> 78 iterations on 32 processors
> yes, as i said do not pay much attention to this. the real code uses line / plane smoothers due to the large cell aspect ratios of the mesh (10^3-10^4). when it works it uses ~ 15 iterations.
> 
>>   Do not run it with PETSc 3.4, only with PETSc 3.5
> i played with gamg a year or so ago and concluded that it was a crashfest, divergencefest etc.
> i interpret your reponse here to mean that it has gotten quite some attention lately?
>> 
>>   I would suggest you run with gamg and send us reports on problems that come up and drop ml. We are actively interested in improving gamg based on your feedback.
> good stuff. you have my first report above :)
> 
> cheers
> 
> arnem