[Wien] apw2c tries to read an anomalous amount of data

Pavel Ondračka pavel.ondracka at email.cz
Mon Jul 29 13:36:36 CEST 2019


If you see a linear scaling for maximum used memory of lapw1c process
as a number of threads even at low thread number than there is
something strange going on. In fact the most memory consuming
diagonalization part should more or less take the same amount of memory
independent of the number of threads. The only part in which memory
consumption scales roughly with number of threads is the hamilt routine
at the beginning of lapw1, however unless you use more than ~10
threads, it should still consume less than the later diagonalization.
Therefore it should not increase the max memory footprint and in fact
at small number of threads the max memory consumption of both lapw1 and
lapw2 shouln't depend much on the number of threads. If you see
something different than please provide some specific numbers so I can
check it.

You are also right that the vector size is unchanged, and therefore the
total amount of IO is of course the same with and without OpenMP.
However, with the k-point parallelization, the issues can be caused by
all the processes running at the same time and accessing the vector
files simultaneously, therefore when you reduce the number of processes
the peak I/O access should be more balanced/reduced. Prof. Blaha
already explained this in his email on Friday.

Another stuff which can unexpectedly influence the results is the
filesystem cache. The linux kernel is usually quite clever with caching
the latest accessed files in the unused memory, so this can help
significantly as well (and again depends on the overall memory
pressure).

Hope this helps to explain it.
Pavel


On Mon, 2019-07-29 at 12:19 +0200, Luc Fruchter wrote:
> What comes out as a surprise (for me), is that the memory needed for 
> lapw2s does not scale with the number of CPUs, while it does for
> lapw1s: 
> when I reduce the number of CPUs, lapw1s memory scales down 
> proportionaly, while total .vector files size is unchanged, and so
> there 
> is no improvement in handling them with lapw2s.
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:  
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html



More information about the Wien mailing list