<div dir="ltr"><div dir="ltr"><div>Thank you both for your answers :)<br></div><div><br></div><div>Matt: <br></div><div>-Yes, sorry I forgot to tell you that, but I've also called PetscMemorySetGetMaximumUsage()  right after initializing SLEPc. Also I've seen a strange 
behaviour: if I ran the same code in my computer and in the cluster 
*without* the command line option -malloc_dump, in the cluster the 
output of <span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos">PetscMallocGetCurrentUsage and <span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos">PetscMallocGetMaximumUsage is always zero, but that doesn't happen in my computer.</span></span></div><div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><br></span></span></div><div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos">- This
 is the output of the code for the solving part (after EPSCreate and 
after EPSSolve), and I've compared it with the output of *top* during 
those moments of peak memory consumption. *top* provides in one of the 
columns the resident set size (RES) and the numbers are around 1 GB per 
process, while, considering the numbers reported by the PETSc functions,
 the one that is more similar to that is given by <span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"> MemoryGetCurrentUsage and is </span></span>only
 800 MB in the solving stage. Maybe, we can consider that those numbers 
are the same plus/minus something? Is it safe to say that <span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"> MemoryGetCurrentUsage is measurin<code>g<font face="arial,helvetica,sans-serif"> the "ru_maxss" member of "rusage"</font></code></span></span></span></span><code><span class="gmail-pln"></span></code> <span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><code><font face="arial,helvetica,sans-serif">(or something similar)? If that's the case, what do the other functions report? <br></font></code></span></span></span></span></div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"></span></span></div><div dir="ltr"><br><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"></span></span><div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos">==================== SOLVER INIT ====================<br>MallocGetCurrent (init): 396096192.0 B<br>MallocGetMaximum (init): 415178624.0 B<br>MemoryGetCurrent (init): 624050176.0 B<br>MemoryGetMaximum (init): 623775744.0 B<br>==================== SOLVER ====================<br>MallocGetCurrent (solver): 560320256.0 B<br>MallocGetMaximum (solver): 560333440.0 B<br>MemoryGetCurrent (solver): 820961280.0 B<br>MemoryGetMaximum (solver): 623775744.0 B<br></span></span></div><div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><br></span></span></div><div>Jose: <br></div><div>- By each step I mean each of the step of the the program in order to 
diagonalize the matrix. For me, those are: creation of basis, 
preallocation of matrix, setting values of matrix, initializing solver, 
solving/diagonalizing and cleaning. I'm only diagonalizing once. <br></div><div><br></div><div>- Regarding
 the information provided by -log_view, it's confusing for me: for 
example, it reports the creation of Vecs scattered across the various 
stages that I've set up (with PetscLogStageRegister and 
PetscLogStagePush/Pop), but almost all the deletions are presented in 
the "Main Stage". What does that "Main Stage" consider? Why are more 
deletions in there that creations? It's nor completely for me clear how 
things are presented there.</div><div><br></div><div>- Thanks for the 
suggestion about the solver. Does "faster convergence" for Krylov-Schur 
mean less memory and less computation, or just less computation? <br></div><div><br></div><div><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos"><span class="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwcot gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-gsrt" id="gmail-m_-6530702778478325633gmail-m_9133745105299418601gmail-m_4385345135988555384gmail-m_-8870074427492245809gmail-cwos">Ale</span></span></div></div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">El jue., 4 oct. 2018 a las 13:12, 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">Regarding the SLEPc part:<br>
- What do you mean by "each step"? Are you calling EPSSolve() several times?<br>
- Yes, the BV object is generally what takes most of the memory. It is allocated at the beginning of EPSSolve(). Depending on the solver/options, other memory may be allocated as well.<br>
- You can also see the memory reported at the end of -log_view<br>
- I would suggest using the default solver Krylov-Schur - it will do Lanczos with implicit restart, which will give faster convergence than the EPSLANCZOS solver.<br>
<br>
Jose<br>
<br>
<br>
> El 4 oct 2018, a las 12:49, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> escribió:<br>
> <br>
> On Thu, Oct 4, 2018 at 4:43 AM Ale Foggia <<a href="mailto:amfoggia@gmail.com" target="_blank">amfoggia@gmail.com</a>> wrote:<br>
> Hello all,<br>
> <br>
> I'm using SLEPc 3.9.2 (and PETSc 3.9.3) to get the EPS_SMALLEST_REAL of a matrix with the following characteristics:<br>
> <br>
> * type: real, Hermitian, sparse<br>
> * linear size: 2333606220 <br>
> * distributed in 2048 processes (64 nodes, 32 procs per node)<br>
> <br>
> My code first preallocates the necessary memory with *MatMPIAIJSetPreallocation*, then fills it with the values and finally it calls the following functions to create the solver and diagonalize the matrix:<br>
> <br>
> EPSCreate(PETSC_COMM_WORLD, &solver);<br>
> EPSSetOperators(solver,matrix,NULL);<br>
> EPSSetProblemType(solver, EPS_HEP);<br>
> EPSSetType(solver, EPSLANCZOS);<br>
> EPSSetWhichEigenpairs(solver, EPS_SMALLEST_REAL);<br>
> EPSSetFromOptions(solver);<br>
> EPSSolve(solver);<br>
> <br>
> I want to make an estimation for larger size problems of the memory used by the program (at every step) because I would like to keep it under 16 GB per node. I've used the "memory usage" functions provided by PETSc, but something happens during the solver stage that I can't explain. This brings up two questions.<br>
> <br>
> 1) In each step I put a call to four memory functions and between them I print the value of mem:<br>
> <br>
> Did you call PetscMemorySetGetMaximumUsage() first?<br>
> <br>
> We are computing <a href="https://en.wikipedia.org/wiki/Resident_set_size" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Resident_set_size</a> however we can. Usually with getrusage().<br>
> From this (<a href="https://www.binarytides.com/linux-command-check-memory-usage/" rel="noreferrer" target="_blank">https://www.binarytides.com/linux-command-check-memory-usage/</a>), it looks like top also reports<br>
> paged out memory.<br>
> <br>
>    Matt<br>
>  <br>
> mem = 0;<br>
> PetscMallocGetCurrentUsage(&mem);<br>
> PetscMallocGetMaximumUsage(&mem);<br>
> PetscMemoryGetCurrentUsage(&mem);<br>
> PetscMemoryGetMaximumUsage(&mem);<br>
> <br>
> I've read some other question in the mailing list regarding the same issue but I can't fully understand this. What is the difference between all of them? What information are they actually giving me? (I know this is only a "per process" output). I copy the output of two steps of the program as an example:<br>
> <br>
> ==================== step N ====================<br>
> MallocGetCurrent: 314513664.0 B<br>
> MallocGetMaximum: 332723328.0 B<br>
> MemoryGetCurrent: 539996160.0 B<br>
> MemoryGetMaximum: 0.0 B<br>
> ==================== step N+1 ====================<br>
> MallocGetCurrent: 395902912.0 B<br>
> MallocGetMaximum: 415178624.0 B<br>
> MemoryGetCurrent: 623783936.0 B<br>
> MemoryGetMaximum: 623775744.0 B<br>
> <br>
> 2) I was using this information to make the calculation of the memory required per node to run my problem. Also, I'm able to login to the computing node while running and I can check the memory consumption (with *top*). The memory used that I see with top is more or less the same as the one reported by PETSc functions at the beginning. But during the inialization of the solver and during the solving, *top* reports a consumption two times bigger than the one the functions report. Is it possible to know from where this extra memory consumption comes from? What things does SLEPc allocate that need that much memory? I've been trying to do the math but I think there are things I'm missing. I thought that part of it comes from the "BV" that the option -eps_view reports:<br>
> <br>
> BV Object: 2048 MPI processes<br>
>   type: svec<br>
>   17 columns of global length 2333606220<br>
>   vector orthogonalization method: modified Gram-Schmidt<br>
>   orthogonalization refinement: if needed (eta: 0.7071)<br>
>   block orthogonalization method: GS<br>
>   doing matmult as a single matrix-matrix product<br>
> <br>
> But "17 * 2333606220 * 8 Bytes / #nodes" only explains on third or less of the "extra" memory.<br>
> <br>
> Ale<br>
> <br>
> <br>
> <br>
> -- <br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
> <br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br>
<br>
</blockquote></div>