<div dir="ltr">Hello Jose, thanks for your answer.<br><br><div class="gmail_quote"><div dir="ltr">El mar., 23 oct. 2018 a las 12:59, Jose E. Roman (<<a href="mailto:jroman@dsic.upv.es" target="_blank">jroman@dsic.upv.es</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There is an undocumented option:<br>
<br>
  -bv_reproducible_random<br>
<br>
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.<br></blockquote><div><br></div><div>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?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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? <br></div><div>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?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jose<br>
<br>
<br>
<br>
> El 23 oct 2018, a las 12:13, Ale Foggia <<a href="mailto:amfoggia@gmail.com" target="_blank">amfoggia@gmail.com</a>> escribió:<br>
> <br>
> Hello, <br>
> <br>
> 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:<br>
> <br>
> # procs   # iters<br>
> 960          157<br>
> 992          189<br>
> 1024        338<br>
> 1056        190<br>
> 1120        174<br>
> 2048        136<br>
> <br>
> 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).<br>
> <br>
> 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.<br>
> <br>
> Ale<br>
<br>
</blockquote></div></div>