subject:"Re\: \[Wien\] lapw1 vs lapwso speed"

Re: [Wien] lapw1 vs lapwso speed

2023-06-16 Thread pluto via Wien


Dear All,

Thank you for the answers.

Just to clarify, this questions was regarding a large case.klist_band 
file. For the scf run, I always use much smaller case.klist, especially 
for a large slab that has no out-of-plane dispersion.


Best,
Lukasz





On 2023-06-11 21:47, Peter Blaha wrote:

This is usually not true, except when EMAX is set to 100 Ry or so.

We use for lapwso  as basisset the lapw1 eigenstates, thus the
dimension of the lapwso eigenvalue problem is only  2 * NE, where NE
is typically (depending on EMAX) 20-30% of NMAT of lapw1.

Am 11.06.2023 um 16:33 schrieb Yundi Quan via Wien:
The matrix that lapw1 -up solves is the spin up part of the 
Hamiltonian and it should be much smaller than the matrix that lapwso 
solves.


On Sunday, June 11, 2023, Peter Blaha > wrote:


The speed of lapwso depends on EMAX in case.in1, which limits the
number of eigenvalues calculated in lapw1 and used as basis for 
lapwso.


With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
With larger emax lapwso may take much more time.

Am 11.06.2023 um 12:36 schrieb pluto via Wien:

Dear All,

When calculating bands for a large slab I have following 
sequence:


Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h
vs 2h). Is this normal for band calculations?

I have 128 GB of RAM in this computer, so this is not a RAM
issue. Here is what top shows for the lapwso calculation (I 
have
4 parallel localhost processes in .machines, OMP=2 and no 
mpi):


Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 
zombie
%Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi, 
0.0 si, 0.0 st
MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 
58.6

buff/cache
MiB Swap:  32088.0 total,  31471.5 free,    616.5 used. 
111238.1

avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU   
  %MEM TIME+ COMMAND
1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   
   1294:13 lapwso
1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   
   1295:30 lapwso
1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   
   1304:23 lapwso
1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   
   1288:06 lapwso


.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
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
Email: peter.bl...@tuwien.ac.at   
 WIEN2k: http://www.wien2k.at 

WWW: http://www.imc.tuwien.ac.at 

-

___
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

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:

Re: [Wien] lapw1 vs lapwso speed

2023-06-11 Thread Peter Blaha


This is usually not true, except when EMAX is set to 100 Ry or so.

We use for lapwso  as basisset the lapw1 eigenstates, thus the dimension 
of the lapwso eigenvalue problem is only  2 * NE, where NE is typically 
(depending on EMAX) 20-30% of NMAT of lapw1.


Am 11.06.2023 um 16:33 schrieb Yundi Quan via Wien:
The matrix that lapw1 -up solves is the spin up part of the Hamiltonian 
and it should be much smaller than the matrix that lapwso solves.


On Sunday, June 11, 2023, Peter Blaha > wrote:


The speed of lapwso depends on EMAX in case.in1, which limits the
number of eigenvalues calculated in lapw1 and used as basis for lapwso.

With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
With larger emax lapwso may take much more time.

Am 11.06.2023 um 12:36 schrieb pluto via Wien:

Dear All,

When calculating bands for a large slab I have following sequence:

Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h
vs 2h). Is this normal for band calculations?

I have 128 GB of RAM in this computer, so this is not a RAM
issue. Here is what top shows for the lapwso calculation (I have
4 parallel localhost processes in .machines, OMP=2 and no mpi):

Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 zombie
%Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi, 
0.0 si, 0.0 st

MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 58.6
buff/cache
MiB Swap:  32088.0 total,  31471.5 free,    616.5 used. 111238.1
avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU 
%MEM TIME+ COMMAND
1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8  
1294:13 lapwso
1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9  
1295:30 lapwso
1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9  
1304:23 lapwso
1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9  
1288:06 lapwso


.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
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
Email: peter.bl...@tuwien.ac.at    
WIEN2k: http://www.wien2k.at 

WWW: http://www.imc.tuwien.ac.at 
-
___
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


--
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

Re: [Wien] lapw1 vs lapwso speed

2023-06-11 Thread Laurence Marks

Let me make a different comment. If you have 2hr for lapw1, 9 hr for
lapwso, it will be almost impossible to get results in less than weeks.

Therefore I suggest looking more carefully:
1) Do you need all the kpoints?
2) Are your RMTs too small?
3) Is your RKMAX too large?

Think.

Then add -so with at first a smaller EMAX to converge, then increase. It is
frequently better to preconverge with decent RKMAX, kpts etc before doing a
final step with better parameters.

If it is really ~ 14 hr per iteration, get access to better
(super)computers.

--
Professor Laurence Marks (Laurie)
Department of Materials Science and Engineering, Northwestern University
www.numis.northwestern.edu
"Research is to see what everybody else has seen, and to think what nobody
else has thought" Albert Szent-Györgyi

On Sun, Jun 11, 2023, 17:29 Peter Blaha  wrote:

> The speed of lapwso depends on EMAX in case.in1, which limits the number
> of eigenvalues calculated in lapw1 and used as basis for lapwso.
>
> With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
> With larger emax lapwso may take much more time.
>
> Am 11.06.2023 um 12:36 schrieb pluto via Wien:
> > Dear All,
> >
> > When calculating bands for a large slab I have following sequence:
> >
> > Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
> > Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
> > Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
> > Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
> > Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
> > Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
> > Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn
> >
> > As you can see lapwso takes much longer than lapw1 (approx. 9h vs 2h).
> > Is this normal for band calculations?
> >
> > I have 128 GB of RAM in this computer, so this is not a RAM issue. Here
> > is what top shows for the lapwso calculation (I have 4 parallel
> > localhost processes in .machines, OMP=2 and no mpi):
> >
> > Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 zombie
> > %Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi,  0.0 si,
> > 0.0 st
> > MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 58.6
> buff/cache
> > MiB Swap:  32088.0 total,  31471.5 free,616.5 used. 111238.1 avail
> Mem
> >
> >  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
> > COMMAND
> > 1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   1294:13
> > lapwso
> > 1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   1295:30
> > lapwso
> > 1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   1304:23
> > lapwso
> > 1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   1288:06
> > lapwso
> >
> > .machines file:
> >
> > omp_global:8
> > omp_lapw1:2
> > omp_lapw2:2
> > omp_lapwso:2
> > 1:localhost
> > 1:localhost
> > 1:localhost
> > 1:localhost
> > granularity:1
> >
> > Best,
> > Lukasz
> > ___
> > 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
> Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at
> -
> ___
> 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] lapw1 vs lapwso speed

2023-06-11 Thread sjalali

Dear Lukasz,

The difference in computation time between lapw1 and lapwso
calculations is expected in band calculations. The lapwso step
involves the calculation of spin-orbit coupling, which can be
computationally more demanding compared to the lapw1 step that
calculates the bands without spin-orbit coupling.

The lapwso calculation includes additional interactions between the
spin of the electron and its orbital motion, which requires more
computational resources and time. Therefore, it is normal to observe a
longer runtime for lapwso compared to lapw1.

In your case, the lapwso process is utilizing a significant portion
of the CPU resources, as indicated by the high CPU usage percentages
(%CPU) in the top output. The memory usage (%MEM) is also relatively
high for the lapwso processes.

It appears that you have allocated sufficient resources (OMP=2) for
the lapwso step, and your system has ample memory available.
Therefore, the longer runtime can be attributed to the inherent
complexity of the spin-orbit coupling calculations rather than a
resource limitation.

If you need to optimize the performance further, you may consider
adjusting the OMP settings or exploring parallelization options with
k-points or MPI to distribute the workload across multiple cores or
processors. However, it's important to note that the total runtime for
the lapwso step will inherently be longer due to the nature of the
calculations involved.

Suggestions for trying:
omp_global:4
#omp_lapw1:2
#omp_lapw2:2
#omp_lapwso:2

In WIEN2k, k-points parallelization can be more efficient. You can use
the testpara_lapw command to assess if increasing the number of
"1:localhost" lines in your .machines file is necessary. testpara_lapw
is a utility program in the WIEN2k package that helps determine the
optimal number of lines (k-points) needed for accurate calculations.

Compiling the code with appropriate optimization flags can
significantly improve the performance and speed of calculations. Here
are some additional suggestions related to code compilation:
Experiment with different optimization levels. Most compilers provide
different optimization levels, such as -O1, -O2, -O3. Higher
optimization levels generally provide better performance but may
increase compilation time. Use the suggestion of the siteconfig_lapw
for the right balance of the code.
Ensure that you are using the latest version of the code, i.e.,
WIEN2k_23.2. The respectful Developers have recently released
significant updates and bug fixes that can improve performance, super
thanks to Peter Blaha and all the developers.

Best regards,
Saeid

Quoting pluto via Wien :

Dear All,

When calculating bands for a large slab I have following sequence:

Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h vs
2h). Is this normal for band calculations?

I have 128 GB of RAM in this computer, so this is not a RAM issue.
Here is what top shows for the lapwso calculation (I have 4 parallel
localhost processes in .machines, OMP=2 and no mpi):

Tasks: 505 total, 2 running, 503 sleeping, 0 stopped, 0 zombie
%Cpu(s): 24.0 us, 0.2 sy, 0.0 ni, 75.7 id, 0.0 wa, 0.1 hi, 0.0
si, 0.0 st
MiB Mem : 128047.1 total, 1845.8 free, 16809.0 used, 58.6 buff/cache
MiB Swap: 32088.0 total, 31471.5 free, 616.5 used. 111238.1 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1336417 lplucin 20 0 6417856 4.8g 15840 R 199.3 3.8 1294:13 lapwso
1336392 lplucin 20 0 2848204 2.3g 15880 S 146.8 1.9 1295:30 lapwso
1336391 lplucin 20 0 2848188 2.4g 15916 S 130.6 1.9 1304:23 lapwso
1336396 lplucin 20 0 2848060 2.3g 15816 S 99.7 1.9 1288:06 lapwso

.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wienSEARCH 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] lapw1 vs lapwso speed

2023-06-11 Thread Yundi Quan via Wien

The matrix that lapw1 -up solves is the spin up part of the Hamiltonian and
it should be much smaller than the matrix that lapwso solves.

On Sunday, June 11, 2023, Peter Blaha  wrote:

> The speed of lapwso depends on EMAX in case.in1, which limits the number
> of eigenvalues calculated in lapw1 and used as basis for lapwso.
>
> With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
> With larger emax lapwso may take much more time.
>
> Am 11.06.2023 um 12:36 schrieb pluto via Wien:
>
>> Dear All,
>>
>> When calculating bands for a large slab I have following sequence:
>>
>> Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
>> Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
>> Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
>> Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
>> Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
>> Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
>> Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn
>>
>> As you can see lapwso takes much longer than lapw1 (approx. 9h vs 2h). Is
>> this normal for band calculations?
>>
>> I have 128 GB of RAM in this computer, so this is not a RAM issue. Here
>> is what top shows for the lapwso calculation (I have 4 parallel localhost
>> processes in .machines, OMP=2 and no mpi):
>>
>> Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 zombie
>> %Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi,  0.0 si,
>> 0.0 st
>> MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 58.6
>> buff/cache
>> MiB Swap:  32088.0 total,  31471.5 free,616.5 used. 111238.1 avail Mem
>>
>>  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+
>> COMMAND
>> 1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   1294:13
>> lapwso
>> 1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   1295:30
>> lapwso
>> 1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   1304:23
>> lapwso
>> 1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   1288:06
>> lapwso
>>
>> .machines file:
>>
>> omp_global:8
>> omp_lapw1:2
>> omp_lapw2:2
>> omp_lapwso:2
>> 1:localhost
>> 1:localhost
>> 1:localhost
>> 1:localhost
>> granularity:1
>>
>> Best,
>> Lukasz
>> ___
>> 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/wi
>> e...@zeus.theochem.tuwien.ac.at/index.html
>>
>
> --
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300
> Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at
> -
> ___
> 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/wi
> e...@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] lapw1 vs lapwso speed

2023-06-11 Thread Peter Blaha

The speed of lapwso depends on EMAX in case.in1, which limits the number 
of eigenvalues calculated in lapw1 and used as basis for lapwso.


With EMAX=5.0 the speed of lapw1 and lapwso is usually similar.
With larger emax lapwso may take much more time.

Am 11.06.2023 um 12:36 schrieb pluto via Wien:

Dear All,

When calculating bands for a large slab I have following sequence:

Sun May 14 12:33:03 PM CEST 2023> (x) lapw1 -band -up -p
Sun May 14 02:25:26 PM CEST 2023> (x) lapw1 -band -dn -p
Sun May 14 04:17:22 PM CEST 2023> (x) lapwso -up -p
Mon May 15 01:30:05 AM CEST 2023> (x) qtl -up -p -band -so
Mon May 15 01:30:05 AM CEST 2023> (x) lapw2 -p -fermi -so -up
Mon May 15 01:51:51 AM CEST 2023> (x) qtl -dn -p -band -so
Mon May 15 01:51:51 AM CEST 2023> (x) lapw2 -p -fermi -so -dn

As you can see lapwso takes much longer than lapw1 (approx. 9h vs 2h). 
Is this normal for band calculations?


I have 128 GB of RAM in this computer, so this is not a RAM issue. Here 
is what top shows for the lapwso calculation (I have 4 parallel 
localhost processes in .machines, OMP=2 and no mpi):


Tasks: 505 total,   2 running, 503 sleeping,   0 stopped,   0 zombie
%Cpu(s): 24.0 us,  0.2 sy,  0.0 ni, 75.7 id,  0.0 wa,  0.1 hi,  0.0 si, 
0.0 st

MiB Mem : 128047.1 total,   1845.8 free,  16809.0 used, 58.6 buff/cache
MiB Swap:  32088.0 total,  31471.5 free,    616.5 used. 111238.1 avail Mem

     PID USER  PR  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ 
COMMAND
1336417 lplucin   20   0 6417856   4.8g  15840 R 199.3   3.8   1294:13 
lapwso
1336392 lplucin   20   0 2848204   2.3g  15880 S 146.8   1.9   1295:30 
lapwso
1336391 lplucin   20   0 2848188   2.4g  15916 S 130.6   1.9   1304:23 
lapwso
1336396 lplucin   20   0 2848060   2.3g  15816 S  99.7   1.9   1288:06 
lapwso


.machines file:

omp_global:8
omp_lapw1:2
omp_lapw2:2
omp_lapwso:2
1:localhost
1:localhost
1:localhost
1:localhost
granularity:1

Best,
Lukasz
___
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
Email: peter.bl...@tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at
-
___
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] lapw1 vs lapwso speed

Re: [Wien] lapw1 vs lapwso speed

Re: [Wien] lapw1 vs lapwso speed

Re: [Wien] lapw1 vs lapwso speed

Re: [Wien] lapw1 vs lapwso speed

Re: [Wien] lapw1 vs lapwso speed

6 matches

Site Navigation

Mail list logo

Footer information