<br><font size=2 face="sans-serif">Hi Dave,</font>
<br>
<br><font size=2 face="sans-serif">Strangely, it only occurs when we use
ML. Other preconditioners we have tested so far include BoomerAMG from
Hypre and a homemade preconditioner based on a single precision factorization
with MUMPS. Both are OK.</font>
<br>
<br><font size=2 face="sans-serif">Thomas</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>dave.mayhem23@gmail.com</b></font>
<p><font size=1 face="sans-serif">27/06/2013 11:21</font>
<td><font size=1 face="Arial">        </font>
<br><font size=1 face="sans-serif">        Pour
:        thomas.de-soza@edf.fr</font>
<br><font size=1 face="sans-serif">        cc
:        petsc-users@mcs.anl.gov</font>
<br><font size=1 face="sans-serif">        Objet
:        Re: [petsc-users] Unreproducible number
of iterations for consecutives solves (GCR + ML)</font></table>
<br>
<br>
<br><font size=3>Hi Thomas,</font>
<br><font size=3>Does this behaviour only occur when using ml, or do you
see this with other preconditioners as well?</font>
<br>
<br><font size=3><br>
<br>
On Thursday, 27 June 2013, Thomas DE-SOZA wrote:</font>
<br><font size=3 face="sans-serif"><br>
Dear PETSc users,</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
We've been using the Krylov solvers in PETSc for a while in our software
package for implicit structural mechanics and recently added algebraic
multigrid preconditioning through the ML and Hypre libraries provided as
part of PETSc.</font><font size=3> </font><font size=3 face="sans-serif"><br>
Though we're quite happy with this new feature, we've encountered a strange
behaviour when using KSPGCR in conjunction with the PCML preconditioner.
<br>
Indeed, identical and  consecutives solves inside the same run do
not display the same number of Krylov iterations even in sequential and
we were wondering why :</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
1st solve</font><font size=3> </font><font size=3 face="sans-serif"><br>
723 KSP unpreconditioned resid norm 2.911385065051e-02 true resid norm
2.911385065051e-02 ||r(i)||/||b|| 9.979426047969e-09</font><font size=3>
<br>
</font><font size=3 face="sans-serif"><br>
2nd solve</font><font size=3> </font><font size=3 face="sans-serif"><br>
787 KSP unpreconditioned resid norm 2.896035212670e-02 true resid norm
2.896035212670e-02 ||r(i)||/||b|| 9.926810982197e-09</font><font size=3>
<br>
</font><font size=3 face="sans-serif"><br>
3rd solve</font><font size=3> </font><font size=3 face="sans-serif"><br>
721 KSP unpreconditioned resid norm 2.913123687343e-02 true resid norm
2.913123687343e-02 ||r(i)||/||b|| 9.985385566274e-09</font><font size=3>
<br>
<br>
</font><font size=3 face="sans-serif"><br>
Would you say this case requires a great number of iterations and therefore
reproductibility is not ensured (indeed it is ill-conditioned and is not
very suited for algebraic multigrid) ?</font><font size=3> </font><font size=3 face="sans-serif"><br>
Or is there a seed somewhere in ML that would explain this ? I searched
the ML manual for that and couln't find any. We're using the uncoupled
coarsening scheme in ML (call PetscOptionsSetValue('-pc_ml_CoarsenScheme',
'Uncoupled', ierr)).</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
Final notes : several consecutive runs of the program do display identical
behaviour (that is the 1st solve always require 723 iterations, the 2nd
787, etc). Moreover other cases that are well-conditioned require the same
number number of iterations for each consecutive solve (though the converged
residual differs a bit).</font><font size=3> <br>
</font><font size=3 face="sans-serif"><br>
Thanks for any hints,</font><font size=3> </font><font size=3 face="sans-serif"><br>
Thomas</font>
<br>