Completely copy from:
https://caendkoelsch.wordpress.com/2018/11/29/direct-vs-iterative-solvers-in-fem/
Direct vs. iterative solvers in FEM
November 29, 2018 caendkoelschLeave a comment
In FEM we usually solve for the equation [K]{u} = {f}
Here [K] is referred to as the stiffness matrix; {f} as the force vector and {u} as the set of unknowns.
The classification of solvers into direct and iterative mainly depends on the method of getting {u} in the linear equation. The selection of the solver depends on the process mechanics and problem size and is nowadays automatically chosen by most of the commercially available FE tools.
But as an engineer and analyst, it is good to know the back-end of what’s happening with respect to the solver selection. So here we go with a non-mathematical explanation of the differences between direct and iterative solvers used in FEM.
Direct Solver:
In the case of direct solver, you find the inverse of matrix [K] and then multiply with {f}. As this method involves inverting the matrix, it is mostly preferred for computationally less expensive problems. From literature, I understand that the direct solvers are effective for problems with less than 100,000 unknowns. And the memory requirements are higher and the ability to solve the equations in parallel is difficult but not impossible.
Usually the direct solvers can be thought of as a variant of LU decomposition method where the [K] matrix is decomposed into a lower and upper triangular matrix (L and U respectively) in such a way that
[K] = [L][U]
More details about the method can be found here.
FE developers exploit the sparsity patterns in the stiffness matrix to increase the computational efficiency in the case of direct solvers by using established algorithms for solving sparse matrices.
What is a sparse matrix? – Read here.
Iterative Solver:
In the case of iterative solver, since finding inverse of a matrix is very time consuming if it is a very big matrix, they start with an initial solution(guess) and then gradually move towards the correct solution for {u}. Till a reasonably solution that satisfies the stop criterion (a tolerance value, usually) is obtained, the solver keeps iterating.
So, this is also not an exact solution but an educated guess which is approximate. The search direction, i.e. the direction in which the initial guess moves towards the final solution is verified by using a variant of conjugate gradient method.
Iterative solvers are suitable for computationally big problems as they often can be parallelized more efficiently using algorithms. But there is a catch. For solving the linearized equations using the iterative solvers, your matrix needs to be properly conditioned. To quote Prof. Wolfgang Bangerth’s words, “The art of devising a good iterative solver is to devise a good preconditioner!”.
Report this ad
Report this ad
In the case of iterative solvers, sometimes oscillatory behavior might be observed. This means the initial solution does not move gradually towards the correct approximate solution and rather diverge. As an end user, you can find this by constantly checking the numerical output that is written by the solver. Unusually long computational times can also be a good indicator for this kind of a problem.
So how can you fix it?
Again, this method is something that has worked for me most of the time. My approach would be to check the model thoroughly if it is constrained properly. As in, try to fix the dofs in your analysis domain that might not have an impact on the simulation results. By doing this, you are reducing the potential errors gradually and assisting the solver converge fast.
And this is a very simplified and non-mathematical explanation of the topic which could be useful for a beginner or an application engineer who just wants to know which solver to use based on the problem context.
For a detailed and mathematical explanation, I would recommend going through this link. https://link.springer.com/chapter/10.1007%2F978-3-319-59038-7_5
Prost!
~ Renga
Other references:
[1] http://www.math.colostate.edu/~bangerth/videos/676/slides.34.pdf