Closed jpfoley closed 10 years ago
This must be an issue with the random gauge field that the internal tests use, as I'm not sure what else could be different.
Remember that CG only minimizes <e|A|e> = <e | r>, where e is the error and r is the residual with Ae = r. In general, we do not have access to e throughout the course of the solve, so cannot check how convergence is really going. Instead we only print <r, r>, for which we cannot ascribe a particular convergence behavior to.
To test the CG solver, we should:
Take a source b and multiply by A: c = A b
Solve Ax = c using CG. Now here, we know that the true solution is b, so that the error at iteration i is given by e_i = b – x_i. This let's us examine the value of <e, r> throughout the course of the solve, to check that convergence is occurring as it should be.
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by
Yes, I agree that it's a problem with the random field. Your point about the matrix norm is a good one, so it's possible that the residual L2 norms would not decrease monotonically. I was thinking that there might be a mild violation of hermiticity, in the long links, say, that was leading to the erratic behaviour, but wasn't strong enough to completely break the test. At any rate, the staggered dirac operator is actually a special case, where the residual norm should decrease monotonically. Philippe de Forcrand discusses this point in the proceedings for his plenary at Lattice 95. Basically, one can show that for staggered quarks, CG generates the same sequence of approximate solutions as GMRES, hence the monotonic convergence. I think what we can say here is that the dirac operator used in the test is significantly different from the "real" staggered dirac operator, for which vanilla CG must converge monotonically.
On 10/10/2012 04:16 AM, mikeaclark wrote:
This must be an issue with the random gauge field that the internal tests use, as I'm not sure what else could be different.
Remember that CG only minimizes <e|A|e> = <e | r>, where e is the error and r is the residual with Ae = r. In general, we do not have access to e throughout the course of the solve, so cannot check how convergence is really going. Instead we only print <r, r>, for which we cannot ascribe a particular convergence behavior to.
To test the CG solver, we should:
Take a source b and multiply by A: c = A b
Solve Ax = c using CG. Now here, we know that the true solution is b, so that the error at iteration i is given by e_i = b – x_i. This let's us examine the value of <e, r> throughout the course of the solve, to check that convergence is occurring as it should be.
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
— Reply to this email directly or view it on GitHub https://github.com/lattice/quda/issues/88#issuecomment-9296406.
Closing issue since it is no longer an issue:
I have noticed that the staggered CG routine in the test suite doesn't always converge monotonically. I've run some full double-precision tests with reliable updating switched off, and I see the residual norms hopping about pretty early on in the iteration count. Of course, monotonic convergence is not guaranteed with reliable updating. However, when I switch off the reliable updating and call the double-precision QUDA routine from MILC, I do see monotonic convergence. We need to check the Dirac operator in the staggered test, to make sure it is always hermitian positive definite