Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-26 Thread Peter Blaha 

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 k-points.
It is running on a single PC (Intel XX with 24 GB RAM and 4 cores) and I 
use WIEN2k_19.1 with ifort/mkl compilation.


I'm running 4 k-parallel jobs and lapw1 runs fine. However, in lapw2 .


Size: lapw2 reads the vector files k-point by k-point (one at the time), 
so if you have more k-points than the size of the vector file has 
nothing to do with the memory of lapw2.
This size will be NMAT*NUME only. There are other large arrays with 
(NMAT,lm, NUME) (Alms,BLMs, CLMs,..).


However, lapw2 runs with a loop about atoms, so when you have more then 
1 k-point, it needs to read these vector files NATOM times.
And with 4 k-parallel threads this is a lot of PARALLEL disk-I/O for a 
poor SATA disk. I can imagine that this is the bottleneck.


Disk I/O can be reduced in at least 2 ways:

As Laurence Marks suggested, reduce E-top in case.in1 such that you have 
only few unoccupied states included.


The second, even more efficient way was suggested by Pavel Ondracka: Use 
OMP-parallelization, eg. export OMP_NUM_THREAD 2 and only 2 k-parallel 
jobs. If this is still too much parallel I/O, you could also use 4 
OpenMP parallel threads and no k-parallelization at all, but this will 
be a little slower.


You may also try the mpi-parallel version, but definitely ONLY if you 
have a recent ELPA installed. Otherwise it will be much slower. However, 
the mpi-version of lapw1 needs more memory (but still less than 4 
k-parallel lapw1) ...


Regards


Am 26.07.2019 um 10:37 schrieb Laurence Marks:
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 for ELPA). For DOS etc 
later you increase these and rerun lapw1 etc.


On Fri, Jul 26, 2019 at 9:27 AM Luc Fruchter > wrote:


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 ?
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at 

https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=f2IY4a60LXX2_8DTCObJe-nnPgNcIVqZRBsqpTqrRQU=
SEARCH the MAILING-LIST at:

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=g-rsFk4xC7uHaddVQZCS2nKpLz-AyX4WWPpytDCUObI=



--
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 
Corrosion in 4D: www.numis.northwestern.edu/MURI 


Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what 
nobody else has thought"

Albert Szent-Gyorgi

___
Wien mailing list
Wien@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



--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW: 
http://www.imc.tuwien.ac.at/tc_blaha- 


___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-26 Thread Pavel Ondračka 
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 per process. Using MPI is another option and also
reduces memory required per CPU.

On Fri, 2019-07-26 at 09:37 +0100, Laurence Marks wrote:
> 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 for ELPA). For DOS etc
> later you increase these and rerun lapw1 etc.
> 
> On Fri, Jul 26, 2019 at 9:27 AM Luc Fruchter 
> wrote:
> > 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 ?
> > ___
> > Wien mailing list
> > Wien@zeus.theochem.tuwien.ac.at
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=f2IY4a60LXX2_8DTCObJe-nnPgNcIVqZRBsqpTqrRQU=
> > SEARCH the MAILING-LIST at:  
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=g-rsFk4xC7uHaddVQZCS2nKpLz-AyX4WWPpytDCUObI=
> 
> 
> ___
> Wien mailing list
> Wien@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

___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-26 Thread Laurence Marks 
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 for ELPA). For DOS etc later you
increase these and rerun lapw1 etc.

On Fri, Jul 26, 2019 at 9:27 AM Luc Fruchter  wrote:

> 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 ?
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=f2IY4a60LXX2_8DTCObJe-nnPgNcIVqZRBsqpTqrRQU=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=xDusGo0KphXQ04Dl6Wf9xCaKVxoL-U4kVBCyrmtP_J4=g-rsFk4xC7uHaddVQZCS2nKpLz-AyX4WWPpytDCUObI=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-26 Thread Laurence Marks 
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 well optimized for this type of issue, and often memory can
be an issue. At one time one of my students was running a large problem on
a supercomputer with 32 cores/node but only 64Gb memory, and ended up only
being able to use 16-20 cores.

The mpi versions may work better for you as they somewhat (not perfectly)
split the code so can use less memory. Whether this is faster will depend
upon your hardware; I have always found mpi to be faster but I know that on
some of Peter's computers this is not true.

Or buy some more RAM!

On Fri, Jul 26, 2019 at 8:58 AM Luc Fruchter  wrote:

> 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 mpi, and yes there four 9.6 Gb .vector files (there is 4
> CPUs used), the total of which exceeds the total memory (24 Gb), while
> the four lapw1 processes only used 20 Gb.
>
> I still have to figure out what is the memory needed for lapw2s, even
> when it is sufficient for lapw1s. I will try to reduce the number of
> CPUs, to see if the total .vector files size is the problem for lapw2s.
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=fcFIgKmYRAO8A2zFk34GnDZgH1eK_jzQR5SB1CChREg=vyk6-KXz2YNM7jt-nsE5U5BhgFy4BcxpGmN_R53kC50=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=fcFIgKmYRAO8A2zFk34GnDZgH1eK_jzQR5SB1CChREg=nAvHikfKYok4yQR0vMVV_Fa44nkoxISiC4Oj7CusDDw=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Laurence Marks 
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 want to try
lapw2_vector_split:2 if you are using mpi.

Since nobody else to my knowledge has reported a similar problem, and I for
one have never seen anything similar it seems to be very specific to
whatever you are doing and your OS.

I suspect some incorrect OS parameters, maybe some noisy memory and/or disc.

On Thu, Jul 25, 2019 at 7:12 PM Luc Fruchter  wrote:

> 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 annoying, as one cannot immediately detect the memory need
> for the case, from a try with the beginning of a scf cycle, as I use to do.
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=zVyRqNsJ3IaYoIt3zsG4BuXlCqwyCWaFWNojNEOe1TY=MkBuvyViyVHKizcxYYtmvWcFcmRVDxNVimYKD_pygww=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=zVyRqNsJ3IaYoIt3zsG4BuXlCqwyCWaFWNojNEOe1TY=9INzrH6X_5PrnK3FqMOUluUo3eDgBEtwFhBSZShfG1I=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-25 Thread Laurence Marks 
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 will be an apparent burst.

On Thu, Jul 25, 2019 at 12:25 PM Luc Fruchter 
wrote:

> 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 applications), although there is very little use of the CPUs.
> The usage of the Cpus looks strange, compared to lpaw1c : quasi idle
> state, interrupted by burst of synchronous CPU use for a few seconds
> (why are lpaw2c synchronous: exchange data ?).
>
> - no log warnings
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=woK5GmXj7EmuNvmeBZLERexqEYJ1Gxy7yjF4sV2H1IA=oN_y0PMTBGFDfTY5zWM_ytb0zN4xIIl55vcWkefWV-0=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=woK5GmXj7EmuNvmeBZLERexqEYJ1Gxy7yjF4sV2H1IA=alo9IkAiLLoUEnci7rmpmEVQUQzGDBtDYqmIufVhB2g=
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: www.numis.northwestern.edu/MURI
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-05 Thread Laurence Marks 
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
www.numis.northwestern.edu

On Fri, Jul 5, 2019, 11:51 Luc Fruchter  wrote:

> 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
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__zeus.theochem.tuwien.ac.at_mailman_listinfo_wien=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=r__-qtRu9i1WG2G9-SjPJ--xauafvz2wFaDTtif1ZcY=tCMhRb3jpVm8-Ci_5vVezaVFmfhpFMhWVp26thEutIA=
> SEARCH the MAILING-LIST at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mail-2Darchive.com_wien-40zeus.theochem.tuwien.ac.at_index.html=DwICAg=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws=U_T4PL6jwANfAy4rnxTj8IUxm818jnvqKFdqWLwmqg0=r__-qtRu9i1WG2G9-SjPJ--xauafvz2wFaDTtif1ZcY=PvDgZ2lhtfvteTnsoRGbAFH4lMqv28e2bEQ0keELRc8=
>
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-03 Thread Gavin Abo 
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 they give for that at [1], which is:


/other distributions may or may not work and are not recommended/

[1] 
https://software.intel.com/en-us/articles/intel-fortran-compiler-190-for-linux-release-notes-for-intel-parallel-studio-xe-2019#sysreq


On 7/3/2019 6:23 AM, Luc Fruchter wrote:
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.


I'll keep you posted with my compiler tries.
___
Wien mailing list
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-03 Thread Gavin Abo 
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 fix for that in the 2019 update 4 that you might 
want to try. However, it seems that the fix hasn't been confirmed if it 
working as mentioned in the Intel forum here:


https://software.intel.com/en-us/comment/1930019

Also, if you use 2019 update 4 and have any issues with mpirun (or 
mpiexec.hydra), you might need to configure it to use the old legacy 
version of it, refer to:


https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/topic/812229

On 7/3/2019 2:02 AM, Luc Fruchter wrote:

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
Wien@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

Re: [Wien] lapw2c tries to read an anomalous amount of data

2019-07-03 Thread Pavel Ondračka 
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, 2019-07-02 at 19:10 +0200, Luc Fruchter wrote:
> 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 disk (several hundred
> Gb), 
> so keeping the system busy endless.
> 
> As the input files for lapw2c (.energy, .vector) are only a few Gb,
> this 
> reading of hundred Gb seems suspect, and rather a disk problem.
> However, 
> all lapw2c routines experience the same problem when run in
> parallel, 
> which I would not expect if the reading of one file was problematic.
> 
> On the other hand, the first cycles ran without any trouble.
> 
> Thanks
> ___
> Wien mailing list
> Wien@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

___
Wien mailing list
Wien@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