I've just seen your remark on presentation, here it is for the last run:
The case is with 154 atoms (matrix-size 19000), without inversion
symmetry; 500 k-points. It is running on a single PC (Intel Xeon 5650
with 24 GB RAM and 2 cores for this run) and I use WIEN2k_19.1 with
ifort/mkl
Dear all,
This is a long thread by now, and it comes because of insufficient
information from the beginning. I guess we all were thinking of a huge
mpi-calculation
The tread should start like:
I'm running a case with XX atoms (matrix-size Y), with/without
inversion symmetry; NN
The easiest solution to reduce memory pressure is to reduce the number
of k-points run in parallel... You should experiment with other
parallelization options. If running 4 kpoints in parallel does not fit
in your memory (or is slow), try to run for example just with two but
with 2 OpenMP threads
If I remember right, the largest piece of memory is the vector file so this
should be a reasonable estimate.
During the scf convergence you can reduce this by *carefully* changing the
numbers at the end of case.in1(c). You don't really need to go to 1.5 Ryd
above E_F (and similarly reduce nband
Yes, I have shared memory. Swap on disk is disabled, so the system must
manage differently here.
I just wonder now: is there a way to estimate the memory needed for the
lapw2s, without running scf up to these ? Is this the total .vector size ?
___
Aaaah, it sounds like you are swapping, either each core or the different
cores (assuming that you have shared memory). That is, since all four cores
cannot run at the same time due to the memory available, they are being
swapped to and from swap space (which is probably on disc).
Wien2k is not
I think it is unlikely related to a specific machine or OS problem: I
encountered the same situation with different machines types, different
OS (Redhat Sci. Linux, Ubuntu), different Intel compilers versions (from
2017 to 2019). But it could be some common configuration problem.
I don't use
How much RAM do you have?
It sounds to me as if on your system the active memory is being paged out,
i.e. you are using swap space and/or you have issues with cached memory not
being released. If you only have 1 9Gb file then there should be no
problem; if you have many there might be. You may
So, my understanding of the situation is that lapw1 may create .vector
files that are larger than the amount of memory needed by the lapw1 step.
At the lapw2 step, the program must handle these files with less memory
than needed, hence these physical / cached unefficient readings.
This sounds
I was however intrigued by this heavy load of the system, with very
little CPU use (which means unefficient computation).
Actually, lapw2 routines are still blocked for some I/O most of the
time. This I/O is however no longer a physical reading from the hard
disk (and so does not show up in
I expect it was the Ubuntu update.
The synchronous CPU will be some combination of:
a) Multiple cores running lapack commands
b) Openmp code in some subroutines (if you are not using mpi)
c) Data communications and/or cores waiting for others if you are using
mpi. When they are all in step there
I changed to Wien2k 19.1 version, latest Intel ifort compiler (2019.4)
and latest Ubuntu (18.04.2), shared memory, 4 CPUs, same case with 154
atoms :
- no more anomalous reading of the disk from parallel lapw2c
- the system is however slowed down a lot (as seen from switching
between
The Intel 2017/2 version of the compiler did not help.
To fix the ideas, lapw2c has read ~ 800 GiB during 13 hours, which makes
at 20 MB/s, 11 hours spent reading disk.
The lapw2c routine will finally end, without any error, after it has
read Tbites of data from the disk. We could not detect
I really doubt this has anything to do with the compiler or Wien2k. Have
you looked at the system logs? You may also be able to look at nfs or
similar logs.
---
Prof Laurence Marks
"Research is to see what everyone else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
Finally, I have the same problem with Intel 2019.4.243 compiler.
My cases are 50 and 150 atoms.
I will try the 2017.2 / Intel-tested Linux version.
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
I am presently trying 2019.4.243 Intel version on the machines that were
problematic with 2018 version. Up to now, I haven't encountered problems.
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
The Intel compilers will most likely work fine under Sci. Linux, but I'm
not seeing the operating system in Intel's list of tested distributions
under System Requirements in their Release Notes. Since Sci. Linux seems
to be an "other" distribution, you may want to take note of the
disclaimer
FYI, you might want to try falling back on the previously mentioned
2017.2.174.
If you do update to a newer version, the 2019 update 3 (and perhaps 2018
versions) have a serious memory leak issue:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18404.html
Intel implemented a
The cumulated amount of disk reading per process may be obtained using
the 'system monitor' / 'processes' tool (provided in Sci. Linux in my case).
Here, this is not a swap problem: I always disable swap, as large memory
overflow would almost freeze the system - I much prefer that it crashes.
Just out of curiosity, how do you measure the current disc usage per
process?
Also, how large is your memory consumption? Very high disc IO (and bad
speed in general) can also be associated with swapping. lapw2 can be
the most memory intensive part of the scf cycle.
Best regards
Pavel
On Tue,
Indeed, I am using ifort 208.3.222 with the options:
-O2 -FR -mp1 -w -prec_div -pc80 -pad -ip -DINTEL_VML -traceback -assume
buffered_io -I$(MKLROOT)/include
I will try to change the options / update ifort to a newer version.
___
Wien mailing list
I am facing a problem with lapw2c on a machine running the 18.2 version
of Wien2k. I suspect this is a machine problem, rather than a Wien2k
one, but would like to be sure:
As lapw2c runs in parallel in a cycle, the lapw2c processes will all try
to read a very large amount of data from the
22 matches
Mail list logo
