Talk:Successive over-relaxation/Archive 1
This is an archive of past discussions about Successive over-relaxation. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
For future reference
in case anyone gets up the gumption to add a section on convergence analysis, rewriting the iteration:
in the corrector form:
is useful. (the residual is .) since the error and residual are related by , we get:
- .
also, perhaps SSOR should be made into a redirect that points here, and a section should be added. that is, SSOR is just two applications of different flavors of SOR one right after the other. one, in the "forward" direction, is as above; the other, in the "backward" direction, is as above but with U in place of L. the two iterations of SOR can be combined in a multiplicative (the usual) or additive fasion. even though SSOR is usually slower than SOR (each with its own optimal damping ; see, for instance, Young's "Iterative solution of large linear systems," p462, 1971), there is the advantage that SSOR is a symmetric procedure and allows it to be used as a preconditioner in methods that respect symmetry. Lunch 05:52, 15 September 2006 (UTC)
Rewrite sentence?
Quote: As in the Gauss–Seidel method, it is not necessary to solve a linear system in order to implement the iteration (∗); indeed, given that the goal is to solve the linear system Aφ = b in the first place, it would be silly to use an iterative method in which a linear system must be solved in each step.
(*) has no "real" linear system, since the matrix on the left side is a (non-strict) lower triangular matrix, so the usual stepwise substitution can be used - this sentence implies something different. Change? -- anonymous
- I think it's quite clear, but that doesn't mean it can't be improved. Go for it. -- Jitse Niesen (talk) 01:27, 2 February 2007 (UTC)
External Link http://www.physics.drexel.edu/~tim/open/sor/
The programs are a "good" examples of horrible code. They implement SOR in a highly inefficient way and the programming styles is a night mare. The calculation of v[i][j] is not(!) done in place as it would follow naturally from the algorithm. Copying around the data between two arrays is unnecessary, slows down and complicates the algorithm.
And they are buggy (nothing serious, e.g. wrong counting of the number of iterations).
It took me a over an hour to understand what the progams do. But if you write them properly they would turn out to be quite simple.
I cannot recommend this link. —Preceding unsigned comment added by 89.54.131.228 (talk) 10:13, 13 January 2008 (UTC)
- Thanks for your post. I removed the link. -- Jitse Niesen (talk) 17:32, 13 January 2008 (UTC)