subject:"\[Wien\] lapw1"

Re: [Wien] lapw1.def failed

2023-12-17 Thread Gavin Abo

A possible cause of the "Killed" message is the operating system 
terminating the program.  For example, the user or queue system might 
have initiated a kill to the operating system for the job while it was 
still in the process of running.  The operating system might also 
automatically kill the running process if all memory (or queue system 
memory limit [1]) on the system has been exhausted.


You might want to check the system log.  Refer to [2].

[1] https://doc.hpc.iter.es/2023.08/en/slurm/slurm_memory_limits/
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg19703.html


Kind Regards,

Gavin
WIEN2k user

On 12/17/2023 6:11 AM, shamik chakrabarti wrote:

Dear Madam & Sir,
                         The error appeared at the first cycle itself 
with the following error;

STOP  LAPW0 END
Killed
grep: lapw2*.error: No such file or directory

>   stop error

What could be the remedy?

Looking forward to your reply.

with regards,___
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.def failed

2023-12-17 Thread shamik chakrabarti

Dear Madam & Sir,

 The error appeared at the first cycle itself with
the following error;
STOP  LAPW0 END
Killed
grep: lapw2*.error: No such file or directory

>   stop error

What could be the remedy?

Looking forward to your reply.

with regards,

On Sat, 16 Dec 2023 at 17:08, Fecher, Gerhard  wrote:

> Not to forget: where is the structure coming from ?
>
> Ciao
> Gerhard
>
> DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
> "I think the problem, to be quite honest with you,
> is that you have never actually known what the question is."
>
> 
> Dr. Gerhard H. Fecher
> Institut of Physics
> Johannes Gutenberg - University
> 55099 Mainz
> 
> Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von
> Lyudmila Dobysheva via Wien [wien@zeus.theochem.tuwien.ac.at]
> Gesendet: Samstag, 16. Dezember 2023 12:02
> An: wien@zeus.theochem.tuwien.ac.at
> Cc: Lyudmila Dobysheva
> Betreff: Re: [Wien] lapw1.def failed
>
> 16.12.2023 10:37, shamik chakrabarti wrote:
> > At the 7th cycle I got the following error;
> > stop error
> > error: command   /home/akt/Desktop/Shamik_Installation/Wien2k/lapw1c
> > lapw1.def   failed
> >  >   lapw1 -c (02:25:39) 737.008u 71.143s 5:39.69 237.9% 0+0k
> > 1064+165016io 8pf+0w
> >  >   lapw0 (02:24:23) 176.006u 3.565s 1:16.19 235.6% 0+0k
> > 4264+103984io 22pf+0w
> > In error file it is written as "Error in LAPW1"
>
> Failed here not lapw1.def, but command lapw1c with a standard argument
> lapw1.def
> You gave too little information. There should be some info, maybe in
> case.dayfile, or .output1, :log
> Is it in parallel mode or not?
> Try to repeat in terminal the command
> x lapw1 -c
> sometimes its output is more informative.
> What are other settings? case.in* files?
> Check what happened in the first six iterations and compare the outputs
> with those in the 7th.
> Was computer well at that time? maybe some accident problem occurred?
> Does the stop repeat at the same place?
> and so long, and so forth...
>
> Best wishes
> Lyudmila Dobysheva
> --
> http://ftiudm.ru/content/view/25/103/lang,english/
> Institute of Physics and Technology,
> Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.
> 426000 Izhevsk Kirov str. 132
> Russia
> ---
> Tel. +7 (34I2)43-24-59 (office), +7 (9I2)OI9-795O (home)
> Skype: lyuka18 (office), lyuka17 (home)
> E-mail: lyuk...@mail.ru (office), lyuk...@gmail.com (home)
>
> ___
> 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
>


-- 
Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India
___
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.def failed

2023-12-16 Thread Fecher, Gerhard

Not to forget: where is the structure coming from ?

Ciao
Gerhard

DEEP THOUGHT in D. Adams; Hitchhikers Guide to the Galaxy:
"I think the problem, to be quite honest with you,
is that you have never actually known what the question is."

Dr. Gerhard H. Fecher
Institut of Physics
Johannes Gutenberg - University
55099 Mainz

Von: Wien [wien-boun...@zeus.theochem.tuwien.ac.at] im Auftrag von Lyudmila 
Dobysheva via Wien [wien@zeus.theochem.tuwien.ac.at]
Gesendet: Samstag, 16. Dezember 2023 12:02
An: wien@zeus.theochem.tuwien.ac.at
Cc: Lyudmila Dobysheva
Betreff: Re: [Wien] lapw1.def failed

16.12.2023 10:37, shamik chakrabarti wrote:
> At the 7th cycle I got the following error;
> stop error
> error: command   /home/akt/Desktop/Shamik_Installation/Wien2k/lapw1c
> lapw1.def   failed
>  >   lapw1 -c (02:25:39) 737.008u 71.143s 5:39.69 237.9% 0+0k
> 1064+165016io 8pf+0w
>  >   lapw0 (02:24:23) 176.006u 3.565s 1:16.19 235.6% 0+0k
> 4264+103984io 22pf+0w
> In error file it is written as "Error in LAPW1"

Failed here not lapw1.def, but command lapw1c with a standard argument
lapw1.def
You gave too little information. There should be some info, maybe in
case.dayfile, or .output1, :log
Is it in parallel mode or not?
Try to repeat in terminal the command
x lapw1 -c
sometimes its output is more informative.
What are other settings? case.in* files?
Check what happened in the first six iterations and compare the outputs
with those in the 7th.
Was computer well at that time? maybe some accident problem occurred?
Does the stop repeat at the same place?
and so long, and so forth...

Best wishes
Lyudmila Dobysheva
--
http://ftiudm.ru/content/view/25/103/lang,english/
Institute of Physics and Technology,
Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.
426000 Izhevsk Kirov str. 132
Russia
---
Tel. +7 (34I2)43-24-59 (office), +7 (9I2)OI9-795O (home)
Skype: lyuka18 (office), lyuka17 (home)
E-mail: lyuk...@mail.ru (office), lyuk...@gmail.com (home)

___
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.def failed

2023-12-16 Thread Lyudmila Dobysheva via Wien

16.12.2023 10:37, shamik chakrabarti wrote:

At the 7th cycle I got the following error;
    stop error
error: command   /home/akt/Desktop/Shamik_Installation/Wien2k/lapw1c 
lapw1.def   failed
 >   lapw1     -c (02:25:39) 737.008u 71.143s 5:39.69 237.9% 0+0k 
1064+165016io 8pf+0w
 >   lapw0     (02:24:23) 176.006u 3.565s 1:16.19 235.6% 0+0k 
4264+103984io 22pf+0w

In error file it is written as "Error in LAPW1"

Failed here not lapw1.def, but command lapw1c with a standard argument 
lapw1.def
You gave too little information. There should be some info, maybe in 
case.dayfile, or .output1, :log

Is it in parallel mode or not?
Try to repeat in terminal the command
x lapw1 -c
sometimes its output is more informative.
What are other settings? case.in* files?
Check what happened in the first six iterations and compare the outputs 
with those in the 7th.
Was computer well at that time? maybe some accident problem occurred? 
Does the stop repeat at the same place?

and so long, and so forth...

Best wishes
Lyudmila Dobysheva
--
http://ftiudm.ru/content/view/25/103/lang,english/
Institute of Physics and Technology,
Udmurt Federal Research Center, Ural Br. of Rus.Ac.Sci.
426000 Izhevsk Kirov str. 132
Russia
---
Tel. +7 (34I2)43-24-59 (office), +7 (9I2)OI9-795O (home)
Skype: lyuka18 (office), lyuka17 (home)
E-mail: lyuk...@mail.ru (office), lyuk...@gmail.com (home)

___
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] lapw1.def failed

2023-12-15 Thread shamik chakrabarti

Dear Wien2k users,

  I have started to simulate an electrolyte material
(structure attached) using non-spin polarization. At the 7th cycle I got
the following error;
   stop error

error: command   /home/akt/Desktop/Shamik_Installation/Wien2k/lapw1c
lapw1.def   failed
>   lapw1 -c (02:25:39) 737.008u 71.143s 5:39.69 237.9% 0+0k
1064+165016io 8pf+0w
>   lapw0 (02:24:23) 176.006u 3.565s 1:16.19 235.6% 0+0k 4264+103984io
22pf+0w

In error file it is written as "Error in LAPW1"

Looking forward to your response in this regard.

with regards,

-- 
Dr. Shamik Chakrabarti
Research Fellow
Department of Physics
Indian Institute of Technology Patna
Bihta-801103
Patna
Bihar, India


LGPSO_minf.struct
Description: Binary data
___
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-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

1 2 >

1 - 100 of 111 matches

Mail list logo