Hello Jose, thanks for your answer. El mar., 23 oct. 2018 a las 12:59, Jose E. Roman (<jro...@dsic.upv.es>) escribió:
> There is an undocumented option: > > -bv_reproducible_random > > It will force the initial vector of the Krylov subspace to be the same > irrespective of the number of MPI processes. This should be used for > scaling analyses as the one you are trying to do. > What about when I'm not doing the scaling? Now I would like to ask for computing time for bigger size problems, should I also use this option in that case? Because, what happens if I have a "bad" configuration? Meaning, I ask for some time, enough if I take into account the "correct" scaling, but when I run it takes double the time/iterations, like it happened before when changing from 960 to 1024 processes? > > An additional comment is that we strongly recommend to use the default > solver (Krylov-Schur), which will do Lanczos with implicit restart. It is > generally faster and more stable. > I will be doing Dynamical Lanczos, that means that I'll need the "matrix whose rows are the eigenvectors of the tridiagonal matrix" (so, according to the Lanczos Technical Report notation, I need the "matrix whose rows are the eigenvectors of T_m", which should be the same as the vectors y_i). I checked the Technical Report for Krylov-Schur also and I think I can get the same information also from that solver, but I'm not sure. Can you confirm this please? Also, as the vectors I want are given by V_m^(-1)*x_i=y_i (following the notation on the Report), my idea to get them was to retrieve the invariant subspace V_m (with EPSGetInvariantSubspace), invert it, and then multiply it with the eigenvectors that I get with EPSGetEigenvector. Is there another easier (or with less computations) way to get this? > Jose > > > > > El 23 oct 2018, a las 12:13, Ale Foggia <amfog...@gmail.com> escribió: > > > > Hello, > > > > I'm currently using Lanczos solver (EPSLANCZOS) to get the smallest real > eigenvalue (EPS_SMALLEST_REAL) of a Hermitian problem (EPS_HEP). Those are > the only options I set for the solver. My aim is to be able to > predict/estimate the time-to-solution. To do so, I was doing a scaling of > the code for different sizes of matrices and for different number of MPI > processes. As I was not observing a good scaling I checked the number of > iterations of the solver (given by EPSGetIterationNumber). I've encounter > that for the **same size** of matrix (that meaning, the same problem), when > I change the number of MPI processes, the amount of iterations changes, and > the behaviour is not monotonic. This are the numbers I've got: > > > > # procs # iters > > 960 157 > > 992 189 > > 1024 338 > > 1056 190 > > 1120 174 > > 2048 136 > > > > I've checked the mailing list for a similar situation and I've found > another person with the same problem but in another solver ("[SLEPc] GD is > not deterministic when using different number of cores", Nov 19 2015), but > I think the solution this person finds does not apply to my problem > (removing "-eps_harmonic" option). > > > > Can you give me any hint on what is the reason for this behaviour? Is > there a way to prevent this? It's not possible to estimate/predict any time > consumption for bigger problems if the number of iterations varies this > much. > > > > Ale > >