On 24/03/2009, Vijay S. Mahadevan wrote: > Great to hear that the interface for slepc-3.0.0 is being upgraded. I > am another one of the users currently interfacing to slepc through > libmesh, although not entirely through libmesh classes. And so, I am > very interested in the coupling between these codes. > > Anyway, I was curious about this statement by Jose: > >> The Krylov-Schur method is mathematically equivalent to implicitly >> restarted >> Arnoldi, the method of Arpack, so there is currently no point in >> using SLEPc >> with Arpack. > > I have noticed in my past experience that for many problems, they > basically required the same number of operator applications but IRAM > (from arpack) is far superior when the dominance ratio of the linear > system becomes closer to 1. So they might be mathematically equivalent > in some limit but I do not think it is fair to go far enough to say > that KrylovSchur=IRAM. My 2 cents. > > PS: I would love to be proved wrong though because I have not looked > in to the math of this but am talking purely based on my experiments.
Well, the two methods are mathematically equivalent if they use the same parameters. The main parameters are: - The number of eigenvalues to compute (nev). - The maximum dimension of the subspace (ncv). - The number of shifts used in each restart. If you are using Arpack via SLEPc then the first two parameters should coincide. However, the last parameter cannot be set by the user, because it is chosen dynamically at each restart, depending on the number of eigenpairs converged so far. Both SLEPc and Arpack set the number of shifts to be roughly ncv/2, but the heuristic is not exactly the same. This means that the behaviour of SLEPc's Krylov-Schur may be different from that of Arpack, especially for problems with irregular convergence. In such cases, it is generally recommended to increase the dimension of the subspace (ncv) to improve convergence, and then the two methods will likely behave similarly again. I will be happy to provide more details if necessary. Jose ------------------------------------------------------------------------------ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
