[Trilinos-Users] AztecOO Convergence

[Randall Bramley]

Mike is (as usual) right.  A minor tweak or two here:

When preconditioning is used, you just have to change his statements to
reference inv(M)*A instead of A, where M is the preconditioner. And I've
often found this case where the matrix is analytically singular because
there's some perceived degree of freedom that is actually pinned down by
the other variables in x. Sometimes in that case you can find what is
happening by forming the vector that almost is an eigenvector for the
eigenvalue 0.  Using Mike's notation, that vector would be x1-x2,
preferably normalized so that not all of its values are tiny.  Of course,
sometimes this gives absolutely no information, it's just a gamble.

Also, if you're using just 1 or 2 processors, the results should be
similar. But when you use 3 or more, large variations can occur because
of the different order that global dot products in particular are summed.
Especially for near-singular systems this can make the numbers of
iterations vary wildly.

I hope this adds a little to Mike's response and helps!

-Randall Bramley


On Mon, 21 Nov 2005, Mike Heroux wrote:

> Ammar,
>
> Note that, if your matrix is singular, then there are two basic
> possibilities:
>
> 1) Your right-hand-side b is in the range of the operator A.  In other
> words, there is an x such that A*x = b.  Furthermore, there are many vectors
> that are solutions, since any vector y from the null space of A can be added
> to x and A(x+y) = b.  If you are getting two solutions to your problem in
> this case, say x1 and x2, and both have a small residual (norm(b-A*x1) and
> norm(b-A*x2) are both small) then you might check the norm of A*(x1-x2).  If
> this value is small, then x1 and x2 are two particular solutions to the
> singular problem and x1-x2 is a vector in the null space of A.
>
> 2) Your right-hand-side b is not in the range of A.  Then there is NO x such
> that A*x = b.  This second case can happen in a partial way due to floating
> point arithmetic errors.  In these cases, b may be analytically in the range
> but numerically slightly out of the range.  This might explain why you
> cannot get your error below a certain tolerance.
>
>
> If you are using unpreconditioned GMRES, there is little chance that you are
> getting two wildly different particular solutions, so if you are seeing very
> different results on 1 and 2 processors, it suggests a coding error (at
> least to me).
>