Re: [Wien] SCF Cycle's problem at WIEN2k 19.1

[河上 匠]

Dear Mr.Tran and Mr.Blaha

I ran the command according to your advice.
We were able to run WIEN2k.
Thank you.

2019-10-15 15:35 に Peter Blaha さんは書きました:

It is rather trivial:

When you modified the x_lapw script, you made a new file, which does
not have "execution" permission. In Linux only files with "x"
permisions can be executed.

chmod +x x_lapw



Am 15.10.2019 um 05:02 schrieb 河上　匠:

Hello,

The file x_lapw and its link x exist in /home/tokunaga/wien2k/ .
Also when I listed the directory of /home/tokunaga/wien2k/ with "ls 
-l",

I was able to confirm the following display:

lrwxrwxrwx  1 tokunaga tokunaga 6 Oct 11 14:00 x -> x_lapw
-rw-r--r--  1 tokunaga tokunaga    107358 Oct 11 14:01 x_lapw

Please tell us about the next solution.

2019-10-11 17:34 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

Is the file x_lapw and its link x still present in 
/home/tokunaga/wien2k/ ?

If you list the WIENROOT directory with "ls -l" you should see them:
/home/tokunaga/wien2k/x_lapw
/home/tokunaga/wien2k/x -> x_lapw

On Friday 2019-10-11 09:58, 河上　匠 wrote:


Date: Fri, 11 Oct 2019 09:58:39
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 

To: A Mailing list for WIEN2k users 


Subject: Re: [Wien] SCF Cycle's problem at WIEN2k 19.1

Thank you your advise, Mr.Tran.

I deleted it in x_lapw:

15,'$file.tmp$updn',   'scratch','unformatted',0

But, in show STDOUT, SCF Cycle stops again at the next step:

hup: Command not found.
/home/tokunaga/wien2k/x: 險ｱ蜿ｯ縺後≠繧翫∪縺帙ｓ.

In addition, when the initialize calculation is repeated from the 
beginning,

the following error message is displayed at x nn;

sh: 23: x: Permission denied

What can be the source of this error?

Sincerely,
Takumi Kawakami

2019-10-10 17:47 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html 
As written, delete

15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during 
processing of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -    filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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




--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF Cycle's problem at WIEN2k 19.1

[Peter Blaha]

It is rather trivial:

When you modified the x_lapw script, you made a new file, which does not 
have "execution" permission. In Linux only files with "x" permisions can 
be executed.


chmod +x x_lapw



Am 15.10.2019 um 05:02 schrieb 河上　匠:

Hello,

The file x_lapw and its link x exist in /home/tokunaga/wien2k/ .
Also when I listed the directory of /home/tokunaga/wien2k/ with "ls -l",
I was able to confirm the following display:

lrwxrwxrwx  1 tokunaga tokunaga 6 Oct 11 14:00 x -> x_lapw
-rw-r--r--  1 tokunaga tokunaga    107358 Oct 11 14:01 x_lapw

Please tell us about the next solution.

2019-10-11 17:34 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

Is the file x_lapw and its link x still present in 
/home/tokunaga/wien2k/ ?

If you list the WIENROOT directory with "ls -l" you should see them:
/home/tokunaga/wien2k/x_lapw
/home/tokunaga/wien2k/x -> x_lapw

On Friday 2019-10-11 09:58, 河上　匠 wrote:


Date: Fri, 11 Oct 2019 09:58:39
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] SCF Cycle's problem at WIEN2k 19.1

Thank you your advise, Mr.Tran.

I deleted it in x_lapw:

15,'$file.tmp$updn',   'scratch','unformatted',0

But, in show STDOUT, SCF Cycle stops again at the next step:

hup: Command not found.
/home/tokunaga/wien2k/x: 險ｱ蜿ｯ縺後≠繧翫∪縺帙ｓ.

In addition, when the initialize calculation is repeated from the 
beginning,

the following error message is displayed at x nn;

sh: 23: x: Permission denied

What can be the source of this error?

Sincerely,
Takumi Kawakami

2019-10-10 17:47 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html 



As written, delete
15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during 
processing of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -    filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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 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] SCF Cycle's problem at WIEN2k 19.1

[河上 匠]

Hello,

The file x_lapw and its link x exist in /home/tokunaga/wien2k/ .
Also when I listed the directory of /home/tokunaga/wien2k/ with "ls -l",
I was able to confirm the following display:

lrwxrwxrwx  1 tokunaga tokunaga 6 Oct 11 14:00 x -> x_lapw
-rw-r--r--  1 tokunaga tokunaga107358 Oct 11 14:01 x_lapw

Please tell us about the next solution.

2019-10-11 17:34 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

Is the file x_lapw and its link x still present in 
/home/tokunaga/wien2k/ ?

If you list the WIENROOT directory with "ls -l" you should see them:
/home/tokunaga/wien2k/x_lapw
/home/tokunaga/wien2k/x -> x_lapw

On Friday 2019-10-11 09:58, 河上　匠 wrote:


Date: Fri, 11 Oct 2019 09:58:39
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] SCF Cycle's problem at WIEN2k 19.1

Thank you your advise, Mr.Tran.

I deleted it in x_lapw:

15,'$file.tmp$updn',   'scratch','unformatted',0

But, in show STDOUT, SCF Cycle stops again at the next step:

hup: Command not found.
/home/tokunaga/wien2k/x: 險ｱ蜿ｯ縺後≠繧翫∪縺帙ｓ.

In addition, when the initialize calculation is repeated from the 
beginning,

the following error message is displayed at x nn;

sh: 23: x: Permission denied

What can be the source of this error?

Sincerely,
Takumi Kawakami

2019-10-10 17:47 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html

As written, delete
15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during 
processing of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF Cycle's problem at WIEN2k 19.1

[tran]

Hi,

Is the file x_lapw and its link x still present in /home/tokunaga/wien2k/ ?
If you list the WIENROOT directory with "ls -l" you should see them:
/home/tokunaga/wien2k/x_lapw
/home/tokunaga/wien2k/x -> x_lapw

On Friday 2019-10-11 09:58, 河上　匠 wrote:


Date: Fri, 11 Oct 2019 09:58:39
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 
To: A Mailing list for WIEN2k users 
Subject: Re: [Wien] SCF Cycle's problem at WIEN2k 19.1

Thank you your advise, Mr.Tran.

I deleted it in x_lapw:

15,'$file.tmp$updn',   'scratch','unformatted',0

But, in show STDOUT, SCF Cycle stops again at the next step:

hup: Command not found.
/home/tokunaga/wien2k/x: 險ｱ蜿ｯ縺後≠繧翫∪縺帙ｓ.

In addition, when the initialize calculation is repeated from the 
beginning,

the following error message is displayed at x nn;

sh: 23: x: Permission denied

What can be the source of this error?

Sincerely,
Takumi Kawakami

2019-10-10 17:47 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html

As written, delete
15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during processing 
of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF Cycle's problem at WIEN2k 19.1

[河上 匠]

Thank you your advise, Mr.Tran.

I deleted it in x_lapw:

15,'$file.tmp$updn',   'scratch','unformatted',0

But, in show STDOUT, SCF Cycle stops again at the next step:

hup: Command not found.
/home/tokunaga/wien2k/x: 險ｱ蜿ｯ縺後≠繧翫∪縺帙ｓ.

In addition, when the initialize calculation is repeated from the 
beginning,

the following error message is displayed at x nn;

sh: 23: x: Permission denied

What can be the source of this error?

Sincerely,
Takumi Kawakami

2019-10-10 17:47 に t...@theochem.tuwien.ac.at さんは書きました:

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html

As written, delete
15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 


To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during processing 
of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

-- ---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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


--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF Cycle's problem at WIEN2k 19.1

[tran]

Hi,

The solution should be here:
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg18771.html

As written, delete
15,'$file.tmp$updn',   'scratch','unformatted',0
in the file $WIENROOT/x_lapw

F. Tran

On Thursday 2019-10-10 09:05, 河上　匠 wrote:

Date: Thu, 10 Oct 2019 09:05:55
From: 河上　匠 
Reply-To: A Mailing list for WIEN2k users 
To: wien@zeus.theochem.tuwien.ac.at
Subject: [Wien] SCF Cycle's problem at WIEN2k 19.1

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during processing of SCF 
Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

'LAPW2' - can't open unit: 15
'LAPW2' -filename: TiC.tmp
'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF Cycle's problem at WIEN2k 19.1

[河上 匠]

Dear WIEN2k users,

I am a beginner of WIEN2k.
I am trying to calculate TiC, but the error occurred during processing 
of SCF Cycle.


In show STDOUT, SCF Cycle stops at the next step:

hup: Command not found.
STOP  LAPW0 END
STOP  LAPW1 END
STOP LAPW2 - Error. Check file lapw2.error


  stop error


And the following error message is displayed:

 'LAPW2' - can't open unit: 15
 'LAPW2' -filename: TiC.tmp
 'LAPW2' -  status: scratch  form: unformatted

Could you tell me how to solve this problem?

Sincerely yours,
Takumi Kawakami

--
---
Nagoya Univercity
Takumi Kawakami
E-mail:kawakami.tak...@i.mbox.nagoya-u.ac.jp
---
___
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] SCF is not converging for DFT+U calculations

[Gavin Abo]

It depends on what you need or want to do.

Refer to section "5.1.4 Job control for iteration (run_lapw or 
runsp_lapw)" in the WIEN2k 18.2 usersguide on page 64 [ 
http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf ].


If you want to reset the calculation from the beginning, use 
run[sp]_lapw without the -NI switch.  It should show a message telling 
you it is automatically removing the *.broyd.* files.  The "-i NUMBER" 
switch can be added to change the default maximum number of iteration 
from that of 40.


If you want to continue the calculation, use "run[sp]_lapw -NI", which 
keeps the *.broyd.* files.


If you need to continue the calculation from a specific program, add the 
"-s PROGRAM" switch.


https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02833.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06118.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg09879.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg06230.html
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg12648.html

On 11/11/2018 12:01 AM, Riyajul Islam wrote:
If SCF does not converge within 40 iterations, should I restart the 
job by removing broyd files or should I keep the broyd files and then 
start the job again?


On Mon, 5 Nov 2018 at 16:14, Peter Blaha > wrote:


Usually DFT+U calculations converge easier than GGA, since often they
lead to an insulator, while plain GGA still gives a metal.

Without details one cannot help.
I'd try:

rm *.broy*
runsp 



On 11/5/18 9:29 AM, Riyajul Islam wrote:
> Dear Wien2k users,
> I am working on MnFe2O4 cubic structure on wien version 17.1
with OS
> centos7. I was running spin polarised calculations and SCF was well
> converged to 0.0001 Ry but SCF is not converging for DFT+U
calculations.
> I have also tried by increasing to 80 iterations but it did not
work. So
> what can I do to make it converge?
>
> Thanking you
> --
> Riyajul Islam
> Research Scholar
> National Institute of Technology Nagaland
> Chumukedima, Dimapur
> Nagaland 797103, 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
>

-- 


                                       P.Blaha
--
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.at
   WIEN2k: 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



--
Riyajul Islam
Research Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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] SCF is not converging for DFT+U calculations

[Riyajul Islam]

If SCF does not converge within 40 iterations, should I restart the job by
removing broyd files or should I keep the broyd files and then start the
job again?

On Mon, 5 Nov 2018 at 16:14, Peter Blaha 
wrote:

> Usually DFT+U calculations converge easier than GGA, since often they
> lead to an insulator, while plain GGA still gives a metal.
>
> Without details one cannot help.
> I'd try:
>
> rm *.broy*
> runsp 
>
>
>
> On 11/5/18 9:29 AM, Riyajul Islam wrote:
> > Dear Wien2k users,
> > I am working on MnFe2O4 cubic structure on wien version 17.1 with OS
> > centos7. I was running spin polarised calculations and SCF was well
> > converged to 0.0001 Ry but SCF is not converging for DFT+U calculations.
> > I have also tried by increasing to 80 iterations but it did not work. So
> > what can I do to make it converge?
> >
> > Thanking you
> > --
> > Riyajul Islam
> > Research Scholar
> > National Institute of Technology Nagaland
> > Chumukedima, Dimapur
> > Nagaland 797103, 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
> >
>
> --
>
>P.Blaha
> --
> 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
>


-- 
Riyajul Islam
Research Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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] SCF is not converging for DFT+U calculations

[Peter Blaha]

Usually DFT+U calculations converge easier than GGA, since often they 
lead to an insulator, while plain GGA still gives a metal.


Without details one cannot help.
I'd try:

rm *.broy*
runsp 



On 11/5/18 9:29 AM, Riyajul Islam wrote:

Dear Wien2k users,
I am working on MnFe2O4 cubic structure on wien version 17.1 with OS 
centos7. I was running spin polarised calculations and SCF was well 
converged to 0.0001 Ry but SCF is not converging for DFT+U calculations. 
I have also tried by increasing to 80 iterations but it did not work. So 
what can I do to make it converge?


Thanking you
--
Riyajul Islam
Research Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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



--

  P.Blaha
--
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

[Wien] SCF is not converging for DFT+U calculations

[Riyajul Islam]

Dear Wien2k users,
I am working on MnFe2O4 cubic structure on wien version 17.1 with OS
centos7. I was running spin polarised calculations and SCF was well
converged to 0.0001 Ry but SCF is not converging for DFT+U calculations. I
have also tried by increasing to 80 iterations but it did not work. So what
can I do to make it converge?

Thanking you
-- 
Riyajul Islam
Research Scholar
National Institute of Technology Nagaland
Chumukedima, Dimapur
Nagaland 797103, 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] scf not converging for slab calculations with spin orbit coupling

[Laurence Marks]

The energy is a very crude test of convergence and can be misleading. You
should look at the magnetic moments (:MM*), the interstitial charge and
pseudo charge (":CTO ", :CPC) and the orbital moments. They may be walking.
If they are really oscillating (which :ENE won't show), MSEC3 may help.
Don't use PRATT.

Most problems are due to bad technical parameters/physics/chemistry. For
instance a badly setup slab does not have to converge well or even at all.

_
Professor Laurence Marks
"Research is to see what everybody else has seen, and to think what nobody
else has thought", Albert Szent-Gyorgi
www.numis.northwestern.edu

On Sun, Oct 28, 2018, 1:58 AM Anup Shakya  wrote:

> Dear All,
>
> I am doing non magnetic GGA+SOC+U calculations for a material containing
> Sm. Without SOC the convergence was obtained using MSR1 scheme with a
> mixing factor of 0.1. But when SOC is included then the scf is oscillating.
> in cycle 119 ETEST: 0.2087   CTEST: .187796
> in cycle 149 ETEST: .1798   CTEST: .2784
> Then I stopped the calculations and tried to perform calculations by
> changing the scheme from MSR1 to PRATT but then I got an error as shown
> below.
> in cycle 2ETEST: .128316935000   CTEST: .1903329
> in cycle 3ETEST: .328839125000   CTEST: .7860095
> in cycle 4ETEST: 12.70075780   CTEST: 6.2762989
> Error in LAPW1
>  'SELECT' - no energy limits found for atom   1  L=
> 0
>  'SELECT' - E-bottom -200.0   E-top   -5.32257
> This error was not there with MSR1 scheme, but its not getting converged.
> Should I increase the mixing factor and keep the MSR1 scheme?
> Please suggest me what to do.
>
> Sincerely,
> Anup Pradhan Sakhya (Ph.D.)
> Visiting Post-Doctoral Fellow
> DCMP, TIFR, Mumbai
>
>
___
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] scf not converging for slab calculations with spin orbit coupling

[Anup Shakya]

Dear All,

I am doing non magnetic GGA+SOC+U calculations for a material containing
Sm. Without SOC the convergence was obtained using MSR1 scheme with a
mixing factor of 0.1. But when SOC is included then the scf is oscillating.
in cycle 119 ETEST: 0.2087   CTEST: .187796
in cycle 149 ETEST: .1798   CTEST: .2784
Then I stopped the calculations and tried to perform calculations by
changing the scheme from MSR1 to PRATT but then I got an error as shown
below.
in cycle 2ETEST: .128316935000   CTEST: .1903329
in cycle 3ETEST: .328839125000   CTEST: .7860095
in cycle 4ETEST: 12.70075780   CTEST: 6.2762989
Error in LAPW1
 'SELECT' - no energy limits found for atom   1  L=
0
 'SELECT' - E-bottom -200.0   E-top   -5.32257
This error was not there with MSR1 scheme, but its not getting converged.
Should I increase the mixing factor and keep the MSR1 scheme?
Please suggest me what to do.

Sincerely,
Anup Pradhan Sakhya (Ph.D.)
Visiting Post-Doctoral Fellow
DCMP, TIFR, Mumbai
___
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] SCF Cycle stops; if: event not found

[Eric Kenney]

Thank you!  Currently I'm running on a cluster, so I need to talk with
IT to change that line,
but I'll try and see if it works!  I'd find it interesting,
Gavin Abo 

Wrote
The error may be coming from line 702 in $WIENROOT/runafm_lapw:

!if (! $?cc_test) goto nextiter


The symbol ! I think is for history substitution in csh [1] but someone may
have intended it to be a comment symbol # [2] as the ! is comment symbol in
Fortran [3].

You might see if the error goes away by changing the line to:

#if (! $?cc_test) goto nextiter

[1] https://stackoverflow.com/questions/19174808/event-not-found-csh
[2] http://www-cs.canisius.edu/ONLINESTUFF/UNIX/shellprogramming.html#A
[3] https://web.stanford.edu/class/me200c/tutorial_77/03_basics.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] SCF Cycle stops; if: event not found

[Gavin Abo]

The error may be coming from line 702 in $WIENROOT/runafm_lapw:

!if (! $?cc_test) goto nextiter

The symbol ! I think is for history substitution in csh [1] but someone 
may have intended it to be a comment symbol # [2] as the ! is comment 
symbol in Fortran [3].


You might see if the error goes away by changing the line to:

#if (! $?cc_test) goto nextiter

[1] https://stackoverflow.com/questions/19174808/event-not-found-csh
[2] http://www-cs.canisius.edu/ONLINESTUFF/UNIX/shellprogramming.html#A
[3] https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

On 9/14/2018 10:16 AM, Eric Kenney wrote:
Sorry for the delay; Helium experiments happened and then I've been 
trying to debug.


The Script I'm trying to run is runafm_lapw -cc 0.001

I get a if:event not found after Mixer->clmcopy runs. For example:

runafm_lapw -cc 0.001 -NI
struct_afm_check END
 LAPW0 END
 LAPW1 END
 LAPW2 END
clmcopy END
 CORE  END
 CORE  END
 MIXER END
clmcopy END
if: Event not found.


After some debugging, I can get runafm_lapw to run properly when /no 
options/ are presented, but as soon as I submit convergence options, 
such as -ec or -cc.


As a final note, I'm using a torque job scheduler, so adding in -xf or 
-f doesn't seem to enhance the stdout.


Message-ID:
        >

Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I'm not aware of such a problem.

To make it more clear:

Which command are you using ?

  runafm  or   runsp    and which switches ??

Put in the first line of the script you are using (eg. runafm) a -xf
instead of -f only.

This will give you a lot of output at stdout, but the interesting part
is just at the end, because with this you can find where it happens.

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] SCF Cycle stops; if: event not found

[Eric Kenney]

Sorry for the delay; Helium experiments happened and then I've been trying
to debug.

The Script I'm trying to run is runafm_lapw -cc 0.001

I get a if:event not found after Mixer->clmcopy runs.  For example:

runafm_lapw -cc 0.001 -NI
struct_afm_check END
 LAPW0 END
 LAPW1 END
 LAPW2 END
clmcopy END
 CORE  END
 CORE  END
 MIXER END
clmcopy END
if: Event not found.


After some debugging, I can get runafm_lapw to run properly when *no
options* are presented, but as soon as I submit convergence options, such
as -ec or -cc.

As a final note, I'm using a torque job scheduler, so adding in -xf or -f
doesn't seem to enhance the stdout.

Message-ID:

Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

I'm not aware of such a problem.

To make it more clear:

Which command are you using ?

  runafm  or   runspand which switches ??

Put in the first line of the script you are using (eg. runafm) a -xf
instead of -f only.

This will give you a lot of output at stdout, but the interesting part
is just at the end, because with this you can find where it happens.

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] SCF Cycle stops; if: event not found

[Peter Blaha]

Hi,

I'm not aware of such a problem.

To make it more clear:

Which command are you using ?

 runafm  or   runspand which switches ??

Put in the first line of the script you are using (eg. runafm) a -xf 
instead of -f only.


This will give you a lot of output at stdout, but the interesting part 
is just at the end, because with this you can find where it happens.


Regards

On 09/06/2018 04:07 PM, Eric Kenney wrote:
Good morning! I'm current on WIEN2k Version 18, and I'm having an issue 
with an AFM calculation.


Currently, I'm trying to run a refinement on a AFM lattice using charge 
convergence criterion.  I consistently get two cycles in before the 
process suddenly stops with the message:


/if: event not found./
/
/
This leaves behind no error messages or logs; just the /if: event not 
found/ statement std out.  The dayfile doesn't seem to show any 
abnormalities either.  I've perused the help and mailing list, but I 
can't any topics about this message.  Thus, I ask you kindly for your 
help.  Thank you.



___
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



--

  P.Blaha
--
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

[Wien] SCF Cycle stops; if: event not found

[Eric Kenney]

Good morning! I'm current on WIEN2k Version 18, and I'm having an issue
with an AFM calculation.

Currently, I'm trying to run a refinement on a AFM lattice using charge
convergence criterion.  I consistently get two cycles in before the process
suddenly stops with the message:

*if: event not found.*

This leaves behind no error messages or logs; just the *if: event not found*
statement std out.  The dayfile doesn't seem to show any abnormalities
either.  I've perused the help and mailing list, but I can't any topics
about this message.  Thus, I ask you kindly for your help.  Thank you.
___
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] SCF and symmetry

[Laurence Marks]

Peter may be busy.

The RKM value is critically important, and you cannot compare different
values. I guess you are running on a single node without mpi, and the RKM
value has been automatically reduced to avoid going beyond the memory
limits (set via NMATMAX). Unless you have small minimum RMT's such as for H
(~0.5) an RKM value around 3 is way too small. You need to repair this,
either using more cores & mpi or something else.

You sound like you have some DFT experience, but I suspect not much with
WIEN2K. Have you tried simpler systems first?

---
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
http://www.numis.northwestern.edu
Corrosion in 4D http://MURI4D.numis.northwestern.edu
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
On Dec 1, 2015 01:40, "Bruno Landeros"  wrote:

> Yes, there was a WARNING in the total energies.
>
> RKM for the NOSYM is 3.18 and 3.57 for the symmetric.
> Is this the reason? Should I increase it?
>
> Enviado desde Correo de Windows
>
> *De:* pbl...@theochem.tuwien.ac.at
> *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎01‎:‎23‎ ‎a. m.
> *Para:* wien@zeus.theochem.tuwien.ac.at
>
> One more thought:
>
> Since these are large cells and one has inversion and the other not,
> could it be that due to size-limitations of NMATMAX the complex case (no
> symmetry) used a much lower RKMAX ? You also should see a WARNING in
> your total energies.
>
> grep :RKM  case.scf   for the two cases.
>
> On 12/01/2015 08:03 AM, Bruno Landeros wrote:
> > The first time I generated the Nosymm structure file was by using the 76
> > posiciones generated by a first symmetric scf calculation (no coordinate
> > optimization), so the same coordinates where used in both cases.
> >
> > To be sure, I run again the Nosymm structure file but accepted the new
> > structfile suggested by the SGROUP program, which detected the corrected
> > symmetry and this gave the energy I just mentioned here, so in principle
> > they are equivalent.
> >
> > Would you like me to send you the case.struct files with the
> > specifications I gave with init_lapw?
> >
> > Enviado desde Correo de Windows
> >
> > *De:* pbl...@theochem.tuwien.ac.at  >
> > *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎53‎ ‎a. m.
> > *Para:* wien@zeus.theochem.tuwien.ac.at
> >  >
> >
> > No. This is a huge E-difference which must come from something very
> > severe. Did you compare the distances in the 2 case.outputnn file or
> > compare the structures in xcrysden.
> >
> > On 12/01/2015 07:37 AM, Bruno Landeros wrote:
> >  > Dear Peter:
> >  >
> >  > Yes, my mistake. First energy (no symmetry) is
> >  > -5752.55335845 Ry.
> >  > while second energy is
> >  > -5752.17735109 Ry.
> >  >
> >  > Since cell parameters are note small (12.994513, 25.002400, 17.381701
> > Bohr)
> >  > and I was testing convergence I asked for just 1 K point in both
> cases.
> >  > May be this the origin of the discrepancy?
> >  >
> >  > Greetings,
> >  >
> >  > Bruno
> >  >
> >  >
> >  > Enviado desde Correo de Windows
> >  >
> >  > *De:* pbl...@theochem.tuwien.ac.at <
> mailto:pbl...@theochem.tuwien.ac.at >
> >  > *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎16‎ ‎a. m.
> >  > *Para:* wien@zeus.theochem.tuwien.ac.at
> >  >  >
> >  >
> >  > The energies you posted are identical !
> >  >
> >  > Anyway: I hope you did not just copy the case.klist file from the low
> to
> >  > the high-symmetry case ??
> >  >
> >  > Otherwise: send me your 2 struct files together with the description
> of
> >  > the chosen calculational parameters (everything which is non-default)
> to
> >  > my private email.
> >  >
> >  > Am 01.12.2015 um 03:00 schrieb Bruno Landeros:
> >  >  > I'm studying a molecular crystal in which two different molecules
> form
> >  >  > an 1:1 adduct. There are 2 molecules of each kind (4 in total) in
> the
> >  >  > unit cell. There are 19 atoms in the asymmetric unit, and since it
> >  >  > belongs to the P21/c spacegroup, a total of 76 atoms are contained
> in
> >  >  > the unit cell. I was trying to find a possible mistake when
> > calculating
> >  >  > interaction energies and I found the next problem:
> >  >  >
> >  >  > If I calculate the SCF by manually inserting the 76 positions and
> > giving
> >  >  > it a P1 symmetry the energy converged to
> >  >  > -5752.17735109 Ry.
> >  >  >
> >  >  > If I calculate the SCF by inserting the 19 atoms of the asymmetric
> > unit
> >  >  > with the correct symmetry and let the program to generate the rest
> of
> >  >  > the positions (which where exactly the same as when inserted
> > 

Re: [Wien] SCF and symmetry

[Peter Blaha]

As Laurence said, you cannot compare energies with different RKmax.

Wien2k truncates RKMAX, if this would lead to matrices larger than 
NMATMAX (specified during installation with siteconfig) to avoid 
overloading/paging your machine (and making it "unusable").


In addition, since a case with complex matrices (no inversion) needs 
twice the memory, it will reduce the effective matrix-size by another 
factor of sqrt(2). Thus you got the different RKmax.


a) NEVER ignore WARNINGS (unless you read and UNDERSTAND the :WAR 
message and it is non-critical for your case).


b) You mentioned "2 molecules " previously. If this contains H with 
small RMTs, RKmax=3 is enough. Reduce it in case.in1(c).


Read http://www.wien2k.at/reg_user/faq/rkmax.html



On 12/01/2015 02:02 PM, Laurence Marks wrote:

Peter may be busy.

The RKM value is critically important, and you cannot compare different
values. I guess you are running on a single node without mpi, and the
RKM value has been automatically reduced to avoid going beyond the
memory limits (set via NMATMAX). Unless you have small minimum RMT's
such as for H (~0.5) an RKM value around 3 is way too small. You need to
repair this, either using more cores & mpi or something else.

You sound like you have some DFT experience, but I suspect not much with
WIEN2K. Have you tried simpler systems first?

---
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
http://www.numis.northwestern.edu
Corrosion in 4D http://MURI4D.numis.northwestern.edu
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

On Dec 1, 2015 01:40, "Bruno Landeros" > wrote:

Yes, there was a WARNING in the total energies.

RKM for the NOSYM is 3.18 and 3.57 for the symmetric.
Is this the reason? Should I increase it?

Enviado desde Correo de Windows

*De:* pbl...@theochem.tuwien.ac.at 
*Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎01‎:‎23‎ ‎a. m.
*Para:* wien@zeus.theochem.tuwien.ac.at


One more thought:

Since these are large cells and one has inversion and the other not,
could it be that due to size-limitations of NMATMAX the complex case
(no
symmetry) used a much lower RKMAX ? You also should see a WARNING in
your total energies.

grep :RKM  case.scf   for the two cases.

On 12/01/2015 08:03 AM, Bruno Landeros wrote:
 > The first time I generated the Nosymm structure file was by using
the 76
 > posiciones generated by a first symmetric scf calculation (no
coordinate
 > optimization), so the same coordinates where used in both cases.
 >
 > To be sure, I run again the Nosymm structure file but accepted
the new
 > structfile suggested by the SGROUP program, which detected the
corrected
 > symmetry and this gave the energy I just mentioned here, so in
principle
 > they are equivalent.
 >
 > Would you like me to send you the case.struct files with the
 > specifications I gave with init_lapw?
 >
 > Enviado desde Correo de Windows
 >
 > *De:* pbl...@theochem.tuwien.ac.at


 > *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎53‎ ‎a. m.
 > *Para:* wien@zeus.theochem.tuwien.ac.at

 > 
 >
 > No. This is a huge E-difference which must come from something very
 > severe. Did you compare the distances in the 2 case.outputnn file or
 > compare the structures in xcrysden.
 >
 > On 12/01/2015 07:37 AM, Bruno Landeros wrote:
 >  > Dear Peter:
 >  >
 >  > Yes, my mistake. First energy (no symmetry) is
 >  > -5752.55335845 Ry.
 >  > while second energy is
 >  > -5752.17735109 Ry.
 >  >
 >  > Since cell parameters are note small (12.994513, 25.002400,
17.381701
 > Bohr)
 >  > and I was testing convergence I asked for just 1 K point in
both cases.
 >  > May be this the origin of the discrepancy?
 >  >
 >  > Greetings,
 >  >
 >  > Bruno
 >  >
 >  >
 >  > Enviado desde Correo de Windows
 >  >
 >  > *De:* pbl...@theochem.tuwien.ac.at


 >  > *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎16‎
‎a. m.
 >  > *Para:* wien@zeus.theochem.tuwien.ac.at

 >  > 
 >  >
 >  > The energies you posted are identical !
 >  >
 >  > Anyway: I hope you did not just copy the case.klist file from
the low to
 >  > the 

[Wien] SCF and symmetry

[Bruno Landeros]

I'm studying a molecular crystal in which two different molecules form an 1:1 
adduct. There are 2 molecules of each kind (4 in total) in the unit cell. There 
are 19 atoms in the asymmetric unit, and since it belongs to the P21/c 
spacegroup, a total of 76 atoms are contained in the unit cell. I was trying to 
find a possible mistake when calculating interaction energies and I found the 
next problem:
If I calculate the SCF by manually inserting the 76 positions and giving it a 
P1 symmetry the energy converged to-5752.17735109 Ry.
If I calculate the SCF by inserting the 19 atoms of the asymmetric unit with 
the correct symmetry and let the program to generate the rest of the positions 
(which where exactly the same as when inserted manually), the same functional,  
same RMT, same K points and same convergence criteria the energy converged 
to-5752.17735109 Ry. 
Transforming the energy difference between the 2 calculations gives 195 
kcal/mol. The same happened when doing the same for other systems. 
My question is, ¿shouldn't I get the same energy in both calculations since 
it's the same system, same coordinates and the input was prepared equally 
except for the symmetry? Since I'm trying to calculate interaction energies 
using different subsystems, some with and some without symmetry, this is a 
relevant question to my research. 

Greetings, 
Bruno L   ___
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] SCF and symmetry

[Laurence Marks]

Typos in your energies?

On Mon, Nov 30, 2015 at 8:00 PM, Bruno Landeros 
wrote:

> I'm studying a molecular crystal in which two different molecules form an
> 1:1 adduct. There are 2 molecules of each kind (4 in total) in the unit
> cell. There are 19 atoms in the asymmetric unit, and since it belongs to
> the P21/c spacegroup, a total of 76 atoms are contained in the unit cell. I
> was trying to find a possible mistake when calculating interaction energies
> and I found the next problem:
>
> If I calculate the SCF by manually inserting the 76 positions and giving
> it a P1 symmetry the energy converged to
> -5752.17735109 Ry.
>
> If I calculate the SCF by inserting the 19 atoms of the asymmetric unit
> with the correct symmetry and let the program to generate the rest of the
> positions (which where exactly the same as when inserted manually), the
> same functional,  same RMT, same K points and same convergence criteria the
> energy converged to
> -5752.17735109 Ry.
>
> Transforming the energy difference between the 2 calculations gives 195
> kcal/mol. The same happened when doing the same for other systems.
>
> My question is, ¿shouldn't I get the same energy in both calculations
> since it's the same system, same coordinates and the input was prepared
> equally except for the symmetry?
> Since I'm trying to calculate interaction energies using different
> subsystems, some with and some without symmetry, this is a relevant
> question to my research.
>
>
> Greetings,
>
> Bruno L
>



-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
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] SCF and symmetry

[Peter Blaha]

The energies you posted are identical !

Anyway: I hope you did not just copy the case.klist file from the low to 
the high-symmetry case ??


Otherwise: send me your 2 struct files together with the description of 
the chosen calculational parameters (everything which is non-default) to 
my private email.


Am 01.12.2015 um 03:00 schrieb Bruno Landeros:

I'm studying a molecular crystal in which two different molecules form
an 1:1 adduct. There are 2 molecules of each kind (4 in total) in the
unit cell. There are 19 atoms in the asymmetric unit, and since it
belongs to the P21/c spacegroup, a total of 76 atoms are contained in
the unit cell. I was trying to find a possible mistake when calculating
interaction energies and I found the next problem:

If I calculate the SCF by manually inserting the 76 positions and giving
it a P1 symmetry the energy converged to
-5752.17735109 Ry.

If I calculate the SCF by inserting the 19 atoms of the asymmetric unit
with the correct symmetry and let the program to generate the rest of
the positions (which where exactly the same as when inserted manually),
the same functional,  same RMT, same K points and same convergence
criteria the energy converged to
-5752.17735109 Ry.

Transforming the energy difference between the 2 calculations gives 195
kcal/mol. The same happened when doing the same for other systems.

My question is, ¿shouldn't I get the same energy in both calculations
since it's the same system, same coordinates and the input was prepared
equally except for the symmetry?
Since I'm trying to calculate interaction energies using different
subsystems, some with and some without symmetry, this is a relevant
question to my research.


Greetings,

Bruno L


___
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/staff/tc_group_e.php
--
___
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] SCF and symmetry

[Bruno Landeros]

Dear Laurence Marks:


Yes, I'm sorry. First energy is:

-5752.55335845 Ry


Second energy is 

-5752.17735109 Ry






Enviado desde Correo de Windows





De: Laurence Marks
Enviado el: ‎lunes‎, ‎30‎ de ‎noviembre‎ de ‎2015 ‎09‎:‎06‎ ‎p. m.
Para: wien@zeus.theochem.tuwien.ac.at





Typos in your energies?



On Mon, Nov 30, 2015 at 8:00 PM, Bruno Landeros  
wrote:



I'm studying a molecular crystal in which two different molecules form an 1:1 
adduct. There are 2 molecules of each kind (4 in total) in the unit cell. There 
are 19 atoms in the asymmetric unit, and since it belongs to the P21/c 
spacegroup, a total of 76 atoms are contained in the unit cell. I was trying to 
find a possible mistake when calculating interaction energies and I found the 
next problem: 



If I calculate the SCF by manually inserting the 76 positions and giving it a 
P1 symmetry the energy converged to


-5752.17735109 Ry.




If I calculate the SCF by inserting the 19 atoms of the asymmetric unit with 
the correct symmetry and let the program to generate the rest of the positions 
(which where exactly the same as when inserted manually), the same functional,  
same RMT, same K points and same convergence criteria the energy converged to


-5752.17735109 Ry. 




Transforming the energy difference between the 2 calculations gives 195 
kcal/mol. The same happened when doing the same for other systems. 




My question is, ¿shouldn't I get the same energy in both calculations since 
it's the same system, same coordinates and the input was prepared equally 
except for the symmetry? 

Since I'm trying to calculate interaction energies using different subsystems, 
some with and some without symmetry, this is a relevant question to my 
research. 







Greetings, 




Bruno L





-- 


Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
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
___
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] SCF and symmetry

[Peter Blaha]

No. This is a huge E-difference which must come from something very 
severe. Did you compare the distances in the 2 case.outputnn file or 
compare the structures in xcrysden.


On 12/01/2015 07:37 AM, Bruno Landeros wrote:

Dear Peter:

Yes, my mistake. First energy (no symmetry) is
-5752.55335845 Ry.
while second energy is
-5752.17735109 Ry.

Since cell parameters are note small (12.994513, 25.002400, 17.381701 Bohr)
and I was testing convergence I asked for just 1 K point in both cases.
May be this the origin of the discrepancy?

Greetings,

Bruno


Enviado desde Correo de Windows

*De:* pbl...@theochem.tuwien.ac.at 
*Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎16‎ ‎a. m.
*Para:* wien@zeus.theochem.tuwien.ac.at


The energies you posted are identical !

Anyway: I hope you did not just copy the case.klist file from the low to
the high-symmetry case ??

Otherwise: send me your 2 struct files together with the description of
the chosen calculational parameters (everything which is non-default) to
my private email.

Am 01.12.2015 um 03:00 schrieb Bruno Landeros:
 > I'm studying a molecular crystal in which two different molecules form
 > an 1:1 adduct. There are 2 molecules of each kind (4 in total) in the
 > unit cell. There are 19 atoms in the asymmetric unit, and since it
 > belongs to the P21/c spacegroup, a total of 76 atoms are contained in
 > the unit cell. I was trying to find a possible mistake when calculating
 > interaction energies and I found the next problem:
 >
 > If I calculate the SCF by manually inserting the 76 positions and giving
 > it a P1 symmetry the energy converged to
 > -5752.17735109 Ry.
 >
 > If I calculate the SCF by inserting the 19 atoms of the asymmetric unit
 > with the correct symmetry and let the program to generate the rest of
 > the positions (which where exactly the same as when inserted manually),
 > the same functional,  same RMT, same K points and same convergence
 > criteria the energy converged to
 > -5752.17735109 Ry.
 >
 > Transforming the energy difference between the 2 calculations gives 195
 > kcal/mol. The same happened when doing the same for other systems.
 >
 > My question is, ¿shouldn't I get the same energy in both calculations
 > since it's the same system, same coordinates and the input was prepared
 > equally except for the symmetry?
 > Since I'm trying to calculate interaction energies using different
 > subsystems, some with and some without symmetry, this is a relevant
 > question to my research.
 >
 >
 > Greetings,
 >
 > Bruno L
 >
 >
 > ___
 > 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/staff/tc_group_e.php
--
___
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



--

  P.Blaha
--
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/staff/tc_group_e.php
--
___
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] SCF and symmetry

[Bruno Landeros]

The first time I generated the Nosymm structure file was by using the 76 
posiciones generated by a first symmetric scf calculation (no coordinate 
optimization), so the same coordinates where used in both cases.


To be sure, I run again the Nosymm structure file but accepted the new 
structfile suggested by the SGROUP program, which detected the corrected 
symmetry and this gave the energy I just mentioned here, so in principle they 
are equivalent.


Would you like me to send you the case.struct files with the specifications I 
gave with init_lapw? 






Enviado desde Correo de Windows





De: pbl...@theochem.tuwien.ac.at
Enviado el: ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎53‎ ‎a. m.
Para: wien@zeus.theochem.tuwien.ac.at





No. This is a huge E-difference which must come from something very 
severe. Did you compare the distances in the 2 case.outputnn file or 
compare the structures in xcrysden.

On 12/01/2015 07:37 AM, Bruno Landeros wrote:
> Dear Peter:
>
> Yes, my mistake. First energy (no symmetry) is
> -5752.55335845 Ry.
> while second energy is
> -5752.17735109 Ry.
>
> Since cell parameters are note small (12.994513, 25.002400, 17.381701 Bohr)
> and I was testing convergence I asked for just 1 K point in both cases.
> May be this the origin of the discrepancy?
>
> Greetings,
>
> Bruno
>
>
> Enviado desde Correo de Windows
>
> *De:* pbl...@theochem.tuwien.ac.at 
> *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎16‎ ‎a. m.
> *Para:* wien@zeus.theochem.tuwien.ac.at
> 
>
> The energies you posted are identical !
>
> Anyway: I hope you did not just copy the case.klist file from the low to
> the high-symmetry case ??
>
> Otherwise: send me your 2 struct files together with the description of
> the chosen calculational parameters (everything which is non-default) to
> my private email.
>
> Am 01.12.2015 um 03:00 schrieb Bruno Landeros:
>  > I'm studying a molecular crystal in which two different molecules form
>  > an 1:1 adduct. There are 2 molecules of each kind (4 in total) in the
>  > unit cell. There are 19 atoms in the asymmetric unit, and since it
>  > belongs to the P21/c spacegroup, a total of 76 atoms are contained in
>  > the unit cell. I was trying to find a possible mistake when calculating
>  > interaction energies and I found the next problem:
>  >
>  > If I calculate the SCF by manually inserting the 76 positions and giving
>  > it a P1 symmetry the energy converged to
>  > -5752.17735109 Ry.
>  >
>  > If I calculate the SCF by inserting the 19 atoms of the asymmetric unit
>  > with the correct symmetry and let the program to generate the rest of
>  > the positions (which where exactly the same as when inserted manually),
>  > the same functional,  same RMT, same K points and same convergence
>  > criteria the energy converged to
>  > -5752.17735109 Ry.
>  >
>  > Transforming the energy difference between the 2 calculations gives 195
>  > kcal/mol. The same happened when doing the same for other systems.
>  >
>  > My question is, ¿shouldn't I get the same energy in both calculations
>  > since it's the same system, same coordinates and the input was prepared
>  > equally except for the symmetry?
>  > Since I'm trying to calculate interaction energies using different
>  > subsystems, some with and some without symmetry, this is a relevant
>  > question to my research.
>  >
>  >
>  > Greetings,
>  >
>  > Bruno L
>  >
>  >
>  > ___
>  > 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/staff/tc_group_e.php
> --
> ___
> 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
>

-- 

   P.Blaha

Re: [Wien] SCF and symmetry

[Peter Blaha]

One more thought:

Since these are large cells and one has inversion and the other not, 
could it be that due to size-limitations of NMATMAX the complex case (no 
symmetry) used a much lower RKMAX ? You also should see a WARNING in 
your total energies.


grep :RKM  case.scf   for the two cases.

On 12/01/2015 08:03 AM, Bruno Landeros wrote:

The first time I generated the Nosymm structure file was by using the 76
posiciones generated by a first symmetric scf calculation (no coordinate
optimization), so the same coordinates where used in both cases.

To be sure, I run again the Nosymm structure file but accepted the new
structfile suggested by the SGROUP program, which detected the corrected
symmetry and this gave the energy I just mentioned here, so in principle
they are equivalent.

Would you like me to send you the case.struct files with the
specifications I gave with init_lapw?

Enviado desde Correo de Windows

*De:* pbl...@theochem.tuwien.ac.at 
*Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎53‎ ‎a. m.
*Para:* wien@zeus.theochem.tuwien.ac.at


No. This is a huge E-difference which must come from something very
severe. Did you compare the distances in the 2 case.outputnn file or
compare the structures in xcrysden.

On 12/01/2015 07:37 AM, Bruno Landeros wrote:
 > Dear Peter:
 >
 > Yes, my mistake. First energy (no symmetry) is
 > -5752.55335845 Ry.
 > while second energy is
 > -5752.17735109 Ry.
 >
 > Since cell parameters are note small (12.994513, 25.002400, 17.381701
Bohr)
 > and I was testing convergence I asked for just 1 K point in both cases.
 > May be this the origin of the discrepancy?
 >
 > Greetings,
 >
 > Bruno
 >
 >
 > Enviado desde Correo de Windows
 >
 > *De:* pbl...@theochem.tuwien.ac.at 
 > *Enviado el:* ‎martes‎, ‎1‎ de ‎diciembre‎ de ‎2015 ‎12‎:‎16‎ ‎a. m.
 > *Para:* wien@zeus.theochem.tuwien.ac.at
 > 
 >
 > The energies you posted are identical !
 >
 > Anyway: I hope you did not just copy the case.klist file from the low to
 > the high-symmetry case ??
 >
 > Otherwise: send me your 2 struct files together with the description of
 > the chosen calculational parameters (everything which is non-default) to
 > my private email.
 >
 > Am 01.12.2015 um 03:00 schrieb Bruno Landeros:
 >  > I'm studying a molecular crystal in which two different molecules form
 >  > an 1:1 adduct. There are 2 molecules of each kind (4 in total) in the
 >  > unit cell. There are 19 atoms in the asymmetric unit, and since it
 >  > belongs to the P21/c spacegroup, a total of 76 atoms are contained in
 >  > the unit cell. I was trying to find a possible mistake when
calculating
 >  > interaction energies and I found the next problem:
 >  >
 >  > If I calculate the SCF by manually inserting the 76 positions and
giving
 >  > it a P1 symmetry the energy converged to
 >  > -5752.17735109 Ry.
 >  >
 >  > If I calculate the SCF by inserting the 19 atoms of the asymmetric
unit
 >  > with the correct symmetry and let the program to generate the rest of
 >  > the positions (which where exactly the same as when inserted
manually),
 >  > the same functional,  same RMT, same K points and same convergence
 >  > criteria the energy converged to
 >  > -5752.17735109 Ry.
 >  >
 >  > Transforming the energy difference between the 2 calculations
gives 195
 >  > kcal/mol. The same happened when doing the same for other systems.
 >  >
 >  > My question is, ¿shouldn't I get the same energy in both calculations
 >  > since it's the same system, same coordinates and the input was
prepared
 >  > equally except for the symmetry?
 >  > Since I'm trying to calculate interaction energies using different
 >  > subsystems, some with and some without symmetry, this is a relevant
 >  > question to my research.
 >  >
 >  >
 >  > Greetings,
 >  >
 >  > Bruno L
 >  >
 >  >
 >  > ___
 >  > 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/staff/tc_group_e.php
 >
--
 > ___
 > Wien mailing list
 > Wien@zeus.theochem.tuwien.ac.at
 > 

Re: [Wien] SCF is not conversed in 11 iteration for TiC test case

[Dr. K. C. Bhamu]

Thank You Prof Marks
But I also tried with -ec 0.0001 and left unchecked -cc as mentioned below:

Dear All wien2k users

  I have selected the following parameters: 3% reduction, rkmax 7, lmax
 10, kpoint-1000 with Shift k-mesh y, Energy 2.0 in TiC.in1_st file,
 instgen_lapw - no spin polarised, PBE96, -6.0.

  When I click on *Prepare input files *then I got the following files

 in0, in1, in2, inc and inm files generated (*no case.in1c file is
 generated0*.

 with -ec 0.0001

 *It SCF conversed into 9 iterations* and energy analysis is as below:


 --- ENE ---
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.13380728
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.08745504
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.00297754
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.98554678
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96353428
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96497501
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96268090
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96263476
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96261344

 --- FER ---
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.6933434621
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.6983570438
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7109073318
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7152568186
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7215751110
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7235424064
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7305559942
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7312026244
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7299098968


  Plz help me how to overcome this problem so that my SCF also converse in
 11 iterations.

  With thanks and regards
  Dr. Bhamu




 --
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu
 Corrosion in 4D: MURI4D.numis.northwestern.edu
 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


___
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] SCF is not conversed in 11 iteration for TiC test case

[Laurence Marks]

You do not have a problem! The charge convergence is very sensitive to
numerical issues, so using -cc 0.0001 demands a lot and is probably not a
good idea.

Until you understand Wien2k well, perhaps best to stay with defaults.

On Fri, Jul 10, 2015 at 10:48 AM, Dr. K. C. Bhamu kcbham...@gmail.com
wrote:

Dear All wien2k users

  I reinstalled the latest version of Wien2k (14.2) on lenovo i3 (4GB RAM)
 64  bit with latest ifort and mkl library.
  I tried to get SCF as mentioned in UG but the SCF is conversed in 14
 iterations

  With -cc 0.0001

  I have selected the following parameters: 3% reduction, rkmax 7, lmax 10,
 kpoint-1000 with Shift k-mesh y, Energy 2.0 in TiC.in1_st file,
 instgen_lapw - no spin polarised, PBE96, -6.0.

  When I click on *Prepare input files *then I got the following files

 in0, in1, in2, inc and inm files generated.

 I left unchecked -ec.

 The following are the energy analysis:

 Analysis of parameter:
 :ENE :FER
 in TiC.scf (showing last 10 / 1 lines)

 --- ENE ---
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96353428
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96497501
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96268090
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96263476
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96261344
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96261624
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96261968
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96262016
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96262061
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96262092
 --- FER ---
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7215751110
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7235424064
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7305559942
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7312026244
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7299098968
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7300270359
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7301998769
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7302566406
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7302677380
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7302878329
 ...

 with -ec 0.0001

 It SCF conversed into 9 iterations and energy analysis is as below:


 --- ENE ---
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.13380728
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.08745504
 :ENE  : ** TOTAL ENERGY IN Ry =-1784.00297754
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.98554678
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96353428
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96497501
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96268090
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96263476
 :ENE  : ** TOTAL ENERGY IN Ry =-1783.96261344

 --- FER ---
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.6933434621
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.6983570438
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7109073318
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7152568186
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7215751110
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7235424064
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7305559942
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7312026244
 :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.7299098968


  Plz help me how to overcome this problem so that my SCF also converse in
 11 iterations.

  With thanks and regards
  Dr. Bhamu




-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
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] SCF Convergence with mBJ

[Muhammad Sajjad]

Dear P. Bala
Thank you for your suggestions.
Dr. Muhammad Sajjad

On Sun, Dec 7, 2014 at 3:51 PM, Peter Blaha pbl...@theochem.tuwien.ac.at
wrote:

 Looks as if he is still using PRATT with a small mixing.

 As I said before, update to wien2k_14.2

 Am 07.12.2014 06:43, schrieb Muhammad Sajjad:

 Dear F. Tran and P. Bala

 The user Qaasim has some problem with his email and can not see your
 emails. I am posting on his behalf.

 The charge criteria is used (runsp_lapw -cc 0.1 -in1new 2 -i 200)
 with Wirn2k 11 version.
 Analysis of parameter:

 The grep :DIS case.scf generates

 :DIS

 in SCFNi50.scf (showing last 10 / 1 lines)

 --- DIS ---
 :DIS  :  CHARGE DISTANCE   ( 0.5610332 for atom1 spin 2)
 0.2378662
 :DIS  :  CHARGE DISTANCE   ( 0.5625705 for atom1 spin 2)
 0.2377033
 :DIS  :  CHARGE DISTANCE   ( 0.5596997 for atom1 spin 2)
 0.2372355
 :DIS  :  CHARGE DISTANCE   ( 0.5610506 for atom1 spin 2)
 0.2370034
 :DIS  :  CHARGE DISTANCE   ( 0.5580173 for atom1 spin 2)
 0.2364869
 :DIS  :  CHARGE DISTANCE   ( 0.5592747 for atom1 spin 2)
 0.2362548
 :DIS  :  CHARGE DISTANCE   ( 0.5563927 for atom1 spin 2)
 0.2357996
 :DIS  :  CHARGE DISTANCE   ( 0.5578176 for atom1 spin 2)
 0.2356113
 :DIS  :  CHARGE DISTANCE   ( 0.5550182 for atom1 spin 2)
 0.2351496
 :DIS  :  CHARGE DISTANCE   ( 0.5562844 for atom1 spin 2)
 0.2349745


 Please suggest the possible solution.


 Kind Regards

 Muhammad Sajjad


 On Fri, Dec 5, 2014 at 5:10 PM, Peter Blaha pbl...@theochem.tuwien.ac.at
 mailto:pbl...@theochem.tuwien.ac.at wrote:

 Are you using wien2k_14.x ???

 Am 05.12.2014 18:20, schrieb Qasim Mahmood:



 Dear User

 Could you please let me know what changes we can make to converge
 our
 calculations with mBJ ( at50% doping). I have done almost all the
 steps
 that i know, like to change mixing factor, switch to MSRI from
 PRATT
 within 6 to 10 cycles, use dense k-mesh etc.
 My system is a magnetic ternary alloy where the magnetic ion is
 Co.

 With many thanks and true regards





 */









 Mr.Qasim Mahmood
 /*
 */Ph.D Schollar, PU,Lahore,Pakistan/*


 _
 Wien mailing list
 w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.
 tuwien.ac.at
 http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien 
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
 SEARCH the MAILING-LIST at: http://www.mail-archive.com/__
 w...@zeus.theochem.tuwien.ac.__at/index.html
 http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.
 at/index.html


 --
 Peter Blaha
 Inst.Materials Chemistry
 TU Vienna
 Getreidemarkt 9
 A-1060 Vienna
 Austria
 +43-1-5880115671 tel:%2B43-1-5880115671

 _
 Wien mailing list
 w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.
 tuwien.ac.at
 http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien 
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
 SEARCH the MAILING-LIST at: http://www.mail-archive.com/__
 w...@zeus.theochem.tuwien.ac.__at/index.html
 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. Materials Chemistry, TU Vienna
 Getreidemarkt 9, A-1060 Vienna, Austria
 Tel: +43-1-5880115671
 Fax: +43-1-5880115698
 email: pbl...@theochem.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] SCF Convergence with mBJ

[Muhammad Sajjad]

Dear F. Tran and P. Bala

The user Qaasim has some problem with his email and can not see your
emails. I am posting on his behalf.

The charge criteria is used (runsp_lapw -cc 0.1 -in1new 2 -i 200) with
Wirn2k 11 version.
 Analysis of parameter:

The grep :DIS case.scf generates

:DIS

in SCFNi50.scf (showing last 10 / 1 lines)

--- DIS ---
:DIS  :  CHARGE DISTANCE   ( 0.5610332 for atom1 spin 2)  0.2378662
:DIS  :  CHARGE DISTANCE   ( 0.5625705 for atom1 spin 2)  0.2377033
:DIS  :  CHARGE DISTANCE   ( 0.5596997 for atom1 spin 2)  0.2372355
:DIS  :  CHARGE DISTANCE   ( 0.5610506 for atom1 spin 2)  0.2370034
:DIS  :  CHARGE DISTANCE   ( 0.5580173 for atom1 spin 2)  0.2364869
:DIS  :  CHARGE DISTANCE   ( 0.5592747 for atom1 spin 2)  0.2362548
:DIS  :  CHARGE DISTANCE   ( 0.5563927 for atom1 spin 2)  0.2357996
:DIS  :  CHARGE DISTANCE   ( 0.5578176 for atom1 spin 2)  0.2356113
:DIS  :  CHARGE DISTANCE   ( 0.5550182 for atom1 spin 2)  0.2351496
:DIS  :  CHARGE DISTANCE   ( 0.5562844 for atom1 spin 2)  0.2349745


Please suggest the possible solution.


Kind Regards

Muhammad Sajjad


On Fri, Dec 5, 2014 at 5:10 PM, Peter Blaha pbl...@theochem.tuwien.ac.at
wrote:

 Are you using wien2k_14.x ???

 Am 05.12.2014 18:20, schrieb Qasim Mahmood:



 Dear User

 Could you please let me know what changes we can make to converge our
 calculations with mBJ ( at50% doping). I have done almost all the steps
 that i know, like to change mixing factor, switch to MSRI from PRATT
 within 6 to 10 cycles, use dense k-mesh etc.
 My system is a magnetic ternary alloy where the magnetic ion is Co.

 With many thanks and true regards





 */









 Mr.Qasim Mahmood
 /*
 */Ph.D Schollar, PU,Lahore,Pakistan/*


 ___
 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.Materials Chemistry
 TU Vienna
 Getreidemarkt 9
 A-1060 Vienna
 Austria
 +43-1-5880115671

 ___
 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] SCF Convergence with mBJ

[Peter Blaha]

Looks as if he is still using PRATT with a small mixing.

As I said before, update to wien2k_14.2

Am 07.12.2014 06:43, schrieb Muhammad Sajjad:

Dear F. Tran and P. Bala

The user Qaasim has some problem with his email and can not see your emails. I 
am posting on his behalf.

The charge criteria is used (runsp_lapw -cc 0.1 -in1new 2 -i 200) with 
Wirn2k 11 version.
Analysis of parameter:

The grep :DIS case.scf generates

:DIS

in SCFNi50.scf (showing last 10 / 1 lines)

--- DIS ---
:DIS  :  CHARGE DISTANCE   ( 0.5610332 for atom1 spin 2)  0.2378662
:DIS  :  CHARGE DISTANCE   ( 0.5625705 for atom1 spin 2)  0.2377033
:DIS  :  CHARGE DISTANCE   ( 0.5596997 for atom1 spin 2)  0.2372355
:DIS  :  CHARGE DISTANCE   ( 0.5610506 for atom1 spin 2)  0.2370034
:DIS  :  CHARGE DISTANCE   ( 0.5580173 for atom1 spin 2)  0.2364869
:DIS  :  CHARGE DISTANCE   ( 0.5592747 for atom1 spin 2)  0.2362548
:DIS  :  CHARGE DISTANCE   ( 0.5563927 for atom1 spin 2)  0.2357996
:DIS  :  CHARGE DISTANCE   ( 0.5578176 for atom1 spin 2)  0.2356113
:DIS  :  CHARGE DISTANCE   ( 0.5550182 for atom1 spin 2)  0.2351496
:DIS  :  CHARGE DISTANCE   ( 0.5562844 for atom1 spin 2)  0.2349745


Please suggest the possible solution.


Kind Regards

Muhammad Sajjad


On Fri, Dec 5, 2014 at 5:10 PM, Peter Blaha pbl...@theochem.tuwien.ac.at 
mailto:pbl...@theochem.tuwien.ac.at wrote:

Are you using wien2k_14.x ???

Am 05.12.2014 18:20, schrieb Qasim Mahmood:



Dear User

Could you please let me know what changes we can make to converge our
calculations with mBJ ( at50% doping). I have done almost all the steps
that i know, like to change mixing factor, switch to MSRI from PRATT
within 6 to 10 cycles, use dense k-mesh etc.
My system is a magnetic ternary alloy where the magnetic ion is Co.

With many thanks and true regards





*/









Mr.Qasim Mahmood
/*
*/Ph.D Schollar, PU,Lahore,Pakistan/*


_
Wien mailing list
w...@zeus.theochem.tuwien.ac.__at 
mailto:Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien 
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
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html


--
Peter Blaha
Inst.Materials Chemistry
TU Vienna
Getreidemarkt 9
A-1060 Vienna
Austria
+43-1-5880115671 tel:%2B43-1-5880115671

_
Wien mailing list
w...@zeus.theochem.tuwien.ac.__at mailto:Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.__ac.at/mailman/listinfo/wien 
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
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. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pbl...@theochem.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] SCF Convergence with mBJ

[Qasim Mahmood]

Dear User

Could you please let me know what changes we can make to converge our
calculations with mBJ ( at50% doping). I have done almost all the steps
that i know, like to change mixing factor, switch to MSRI from PRATT within
6 to 10 cycles, use dense k-mesh etc.
My system is a magnetic ternary alloy where the magnetic ion is Co.

With many thanks and true regards
















*Mr.Qasim Mahmood*
*Ph.D Schollar, PU,Lahore,Pakistan*
___
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] SCF Convergence with mBJ

[tran]

Hi,

Magnetic systems can be very difficult to converge and even
more with mBJ. But, without knowing more details it's difficult
to help you. Which criteria of convergence for energy (-ec) and
charge (-cc) are you using? During how many iterations
did you let the calculation running? You could also
do grep :DIS case.scf to show use how the distance charge
behaves.

F. Tran

On Fri, 5 Dec 2014, Qasim Mahmood wrote:




Dear User
Could you please let me know what changes we can make to converge our 
calculations with mBJ ( at50% doping). I have done almost all the steps that i 
know, like
to change mixing factor, switch to MSRI from PRATT within 6 to 10 cycles, use 
dense k-mesh etc.
My system is a magnetic ternary alloy where the magnetic ion is Co.

With many thanks and true regards















Mr.Qasim Mahmood
Ph.D Schollar, PU,Lahore,Pakistan



___
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] SCF Convergence with mBJ

[Peter Blaha]

Are you using wien2k_14.x ???

Am 05.12.2014 18:20, schrieb Qasim Mahmood:



Dear User

Could you please let me know what changes we can make to converge our
calculations with mBJ ( at50% doping). I have done almost all the steps
that i know, like to change mixing factor, switch to MSRI from PRATT
within 6 to 10 cycles, use dense k-mesh etc.
My system is a magnetic ternary alloy where the magnetic ion is Co.

With many thanks and true regards





*/









Mr.Qasim Mahmood
/*
*/Ph.D Schollar, PU,Lahore,Pakistan/*


___
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.Materials Chemistry
TU Vienna
Getreidemarkt 9
A-1060 Vienna
Austria
+43-1-5880115671
___
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] SCF doesn't run after initso_lap

[hüsnü kara]

I use version 12.1 of Wien2k. There are some errors in my calculation
file(but inside of error files are empty)

a3.bva a3.in1_so  a3.output2dn
a3.scf1upa3.vorbdn_so
   dstart.def
a3.clmcordn   a3.in1_st   a3.output2up
a3.scf2dna3.vorbup
  *dstart.error*
a3.clmcorup   a3.in2   a3.outputcdn
a3.scf2up
a3.vorbup_so fort.66
a3.clmdn a3.in2ca3.outputcup
a3.scfcdn
a3.vrespcordn  fort.96
a3.clmdn_old  a3.in2_ls a3.outputd
a3.scfcup
a3.vrespcorupkgen.def
a3.clmdn_so   a3.in2_soa3.outputddn
a3.scfma3.vrespdn
   lapw0.def
a3.clmscdn a3.in2_st a3.outputdup
a3_scf_sp_pbe_exp-vol.clmdn   a3.vrespsum
*lapw0.error*
a3.clmscup a3.in2_sya3.outputkgen
a3_scf_sp_pbe_exp-vol.clmsum   a3.vrespup :log
a3.clmsum  a3.inc a3.outputm
a3_scf_sp_pbe_exp-vol.clmup a3.vspdn
lstart.def
a3.clmsum_old   a3.inc_so   a3.outputnn
a3_scf_sp_pbe_exp-vol.scf  a3.vspdn_old
mixer.def
a3.clmsum_soa3.inc_sta3.outputs
a3_scf_sp_pbe_exp-vol.struct   a3.vspdn_so
*mixer.error*
a3.clmup a3.incup  a3.outputsgroup
a3.sigmaa3.vspdn_st
 new_super.clmdn
a3.clmup_old  a3.indm  a3.outputsgroup1
a3.structa3.vsp_st
 new_super.clmsum
a3.clmup_so   a3.indm_soa3.outputst
a3.struct_ii
a3.vspup new_super.clmup
a3.clmvaldn   a3.inm a3.outsymso
a3.struct_interm   a3.vspup_old
   nn.def
a3.clmvalup   a3.inm_restart_st   a3.qdmftdn
a3.struct_nn
a3.vspup_so  setrmt.bva
a3.corewfdn   a3.inm_sta3.qdmftup
a3.struct_sgroup
a3.vtotal   setrmt.nnshells
a3.corewfup   a3.inorb   a3.qtldn
a3.struct_so a3.weighdn
   setrmt.outputnn
a3.dayfile   a3.inorb_soa3.qtlup
a3.struct_st  a3.weightaverdn
 setrmt.struct
a3.dmatdn  a3.inq  a3.r2v
a3.temp a3.weightaverup
 setrmt.struct_nn
a3.dmatdn_soa3.inq_st a3.radwfdn
a3.test
a3.weightdnsetrmt.struct_setrmt
a3.dmatup  a3.insoa3.radwfup
a3.tmp
a3.weightupSTDOUT
a3.dmatup_soa3.inst   a3.recprlist
a3.tmpdena3.weighup
symmetry.def
a3.dmftsyma3.kgena3.rhopw
a3.tmpdn
case.dmatdn_dummy  symmetso.def
a3.eecedn  a3.klist a3.rotlm
a3.tmpup
case.dmat_dummy  updstart.def
a3.eeceup  a3.ksyma3.rsigma
a3.vcoul
case.dmatup_dummy  *updstart.error*
a3.energydn   a3.nnshellsa3.rsp
a3.vec
dndstart.def uplapw1.def
a3.energyup   a3.nshdn   a3.rspdn
a3.vnsdn   *
dndstart.error   *
   * uplapw1.error*
a3.grr a3.nshup   a3.rsplcoredn
a3.vnsdn_olddnlapw1.def
   uplapw2.def
a3.in0a3.oubwindna3.rsplcoreup
a3.vnsdn_so  dnlapw1.error
 * uplapw2.error*
a3.in0abp  a3.oubwinupa3.rspup
a3.vnsup
dnlapw2.def   uplcore.def
a3.in0_st   a3.output0 a3.scf
a3.vnsup_old *dnlapw2.error   *
 * uplcore.error*
a3.in0_stda3.output1dn   a3.scf0
a3.vnsup_so   dnlcore.def
a3.in1   a3.output1up   a3.scf1dn
a3.vorbdn*dnlcore.error*


These are inside my :log file:


















































*Mon Jun 23 12:30:45 EEST 2014 (x) mixerMon Jun 23 12:30:46 EEST 2014 (x)
lapw0Mon Jun 23 12:30:48 EEST 2014 (x) lapw1 -upMon Jun 23 12:30:52 EEST
2014 (x) lapw1 -dnMon Jun 23 12:30:56 EEST 2014 (x) lapw2 -up Mon Jun 23
12:30:57 EEST 2014 (x) lapw2 -dnMon Jun 23 12:30:58 EEST 2014 (x) lcore
-upMon Jun 23 12:30:58 EEST 2014 (x) lcore -dnMon Jun 23 12:30:59 EEST
2014 (x) 

[Wien] SCF doesn't run after initso_lap

[hüsnü kara]

Dear Wien Users,

I did structure optimization and I got regular initialization. I runned the
SCF calculation for spin poarized case.(runsp_lapw -ec 0.1 -cc 0.1
-Nl -i 50)  I saved the results. Then I used initso_lapw command in
terminal:



*For large spin orbit effects it might be necessary to include many more
eigenstates from lapw1 by increasing EMAX in case.in1(c). *





















































*Please enter EMAX(default 5.0 Ryd):  The radial basis set for heavy
atoms with p-semicore states is verylimited. One can improve this by adding
RLOs. Note: you MUST NOT addRLOs for atoms like oxygen, therefore the
default is set to NONEAdd RLO for NONE, ALL, CHOOSE elements? (N/a/c)
: cp-Energy parameters for Sr atom is : 1   -1.35  0.002 CONT 1 1
0.30  0.000 CONT 1 Would you like to add RLO? (Y/n)Yp-Energy parameters
for Ti atom is : 1   -2.58  0.002 CONT 1 10.30  0.000 CONT
1 Would you like to add RLO? (Y/n)Y Check the generated a3.inso file
(RLOs,...) Check the generated a3.in1 file (Emax at the bottom of the
file)In spinpolarized case SO may reduce symmetry. The program symmetso
dedects the proper symmetry and creates new struct andinput files. (Note,
equivalent atoms could become inequivalent in some cases). Do you have a
spinpolarized case (and want to run symmetso) ? (y/N)y
90.090.01.57079632679490  T
1.00   0.000E+000  0.000E+000
6.123233995736766E-017   1.00   0.000E+000
6.123233995736766E-017  6.123233995736766E-017   1.00 0.0u
0.0s 0:00.11 81.8% 0+0k 2224+4208io 8pf+0w A new structure for SO
calculations has been created (_so). If you commit it will create new
a3.struct, in1(c), in2c, inc, clmsum/up/dn, vspup/dn and vnsup/dn files.
(Please SAVE any previous calculations)NOTE: Files for -orb
(a3.indm(c),inorb,dmatup/dn) must be adapted manuallyDo you want to use the
new structure for SO calculations ? (y/N)y We run KGEN to generate a new
kmesh for the SO calculation: Number of Kpoint in a3.klist is :
1000Please enter Number of k-points in full BZ (default: 1000):
NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of
G) length of reciprocal lattice vectors:   0.843   0.843   0.843  10.000
10.000  10.000  Shift of k-mesh allowed. Do you want to shift: (0=no,
1=shift)  75  k-points generated, ndiv=  10
10  10KGEN ENDSDo you want to rerun kgen ? (y/N)NSpinorbit is now
ready to run.*
And then I runned the SCF calculation(*runsp_lapw -so -ec 0.1 -cc
0.1 -NI* ), but it doesn't run.

Please can you help me?

With regards,







-- 

Hüsnü Kara

Doktora Öğrencisi/ PhD Candidate
Yıldız Teknik Üniversitesi/ Yildiz Technical University
İstanbul / Turkey
___
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] SCF doesn't run after initso_lap

[tran]

Hi,

what do you mean by but it doesn't run? Did the calculation crash?
You have to give more details.

F. Tran

On Mon, 23 Jun 2014, hüsnü kara wrote:


Dear Wien Users,

I did structure optimization and I got regular initialization. I runned the SCF 
calculation for spin poarized case.(runsp_lapw -ec 0.1 -cc 0.1 -Nl -i
50)  I saved the results. Then I used initso_lapw command in terminal:

For large spin orbit effects it might be necessary to include many more
eigenstates from lapw1 by increasing EMAX in case.in1(c).
 
Please enter EMAX(default 5.0 Ryd):
 
The radial basis set for heavy atoms with p-semicore states is very
limited. One can improve this by adding RLOs. Note: you MUST NOT add
RLOs for atoms like oxygen, therefore the default is set to NONE
Add RLO for NONE, ALL, CHOOSE elements? (N/a/c) : c
p-Energy parameters for Sr atom is :
 1   -1.35  0.002 CONT 1
 1    0.30  0.000 CONT 1
 
Would you like to add RLO? (Y/n)Y
p-Energy parameters for Ti atom is :
 1   -2.58  0.002 CONT 1
 1    0.30  0.000 CONT 1
 
Would you like to add RLO? (Y/n)Y
 Check the generated a3.inso file (RLOs,...)
 Check the generated a3.in1 file (Emax at the bottom of the file)

In spinpolarized case SO may reduce symmetry.

The program symmetso dedects the proper symmetry and creates new struct and
input files. (Note, equivalent atoms could become inequivalent in some cases).

Do you have a spinpolarized case (and want to run symmetso) ? (y/N)y
   90.0    90.0    1.57079632679490  T
   1.00   0.000E+000  0.000E+000
  6.123233995736766E-017   1.00   0.000E+000
  6.123233995736766E-017  6.123233995736766E-017   1.00
0.0u 0.0s 0:00.11 81.8% 0+0k 2224+4208io 8pf+0w
 A new structure for SO calculations has been created (_so).
 If you commit it will create new  a3.struct, in1(c), in2c, inc,
 clmsum/up/dn, vspup/dn and vnsup/dn files. (Please SAVE any previous
 calculations)

NOTE: Files for -orb (a3.indm(c),inorb,dmatup/dn) must be adapted manually
Do you want to use the new structure for SO calculations ? (y/N)y

 We run KGEN to generate a new kmesh for the SO calculation:
 
Number of Kpoint in a3.klist is : 1000

Please enter Number of k-points in full BZ (default: 1000):

  NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
 length of reciprocal lattice vectors:   0.843   0.843   0.843  10.000  10.000  
10.000
  Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
  75  k-points generated, ndiv=  10  10  10
KGEN ENDS
Do you want to rerun kgen ? (y/N)N

Spinorbit is now ready to run.

And then I runned the SCF calculation(runsp_lapw -so -ec 0.1 -cc 0.1 
-NI ), but it doesn't run.

Please can you help me?

With regards,

 





--

Hüsnü Kara

Doktora Öğrencisi/ PhD Candidate
Yıldız Teknik Üniversitesi/ Yildiz Technical University
İstanbul / Turkey


___
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] SCF convergence

[Luis Ogando]

Dear Prof. Blaha (and others),

   Related to my previous messages, do you think that it would be useful to
change the mBJ parameters in order to get the experimental gap for the bulk
wurtzite InP with RKmax=5 and transfer them to the supercell keeping
RKmax=5 ?
   It would not be the most elegant solution, but it could be a solution.
   All the best,
Luis



2013/9/26 Luis Ogando lcoda...@gmail.com

 Dear Prof. Blaha,

Thank you for your comments.
I have reasons to change the default parameters and I would like to
 clarify some points:

 1) All the structural parameters were taken from optimized WZ and ZB bulk
 InP structures using the PBE potential.

 2) The increase in the number o K-points I mentioned in my first message
 was done only in the a-b (x-y) plane, because there is no sense in
 increasing K-points along the huge c-axis of the supercell.

 3) Some time ago, there was a message sent to the list saying that an
 increase in the Gmax value could improve the calculation performance. I did
 some tests in the simple WZ structure and I got a faster calculation with
 Gmax=20. This was (more or less) the value cited in the message, but,
 unfortunately, I do not remember details (the message is somewhere in my
 mailbox).

 4) As you noted, the gap is the critical quantity in my calculations and I
 did the suggested RKmax tests some time ago. The main parameters in these
 tests were (only Gmax and Kpoints are different from that employed in the
 supercell):

*Structure: WZ InP bulk
*RMT: 2.50 (In) and 2.10 (P)
*Emax: 5 (spin-orbit effects)
*XC: 13 (PBE) + mBJ
*core-valence separation energy: -6.0
*GMAX: 12 (NOT 20 !!!)
*Inequivalent Kpoints: 16
*Calculation options: run_lapw -p -NI -so -ec 0.0001 -cc 0.0001 -i 150
 -it

 Results:
RKmax = 5 = gap = 1.556 eV
RKmax = 6 = gap = 1.467 eV
RKmax = 7 = gap = 1.476 eV
RKmax = 8 = gap = 1.486 eV
RKmax = 9 = gap = 1.493 eV   ( the experimental value is 1.49 eV ;  Appl.
 Phys. Lett. 91, 263104 (2007) )
RKmax = 10 = gap = 1.498 eV

The difference between the calculated gaps for WZ and ZB bulk
 structures is around 98 meV, but I doubt that the 3 ZB layers will
 reproduce the bulk gap, so the difference between phases in the supercell
 must be lower than 98 meV. This is the reason for using RKmax = 9, I would
 like to get the best gap value for the WZ region.

In your message, you commented that the convergence may be disturbed by
 ghostbands. Do you believe that the -in1new option can help ?

I would strongly appreciate any comment / suggestion !
Thank you again,
  Luis



 2013/9/26 Peter Blaha pbl...@theochem.tuwien.ac.at

 Reduce RKmax. It is ridiculous to start such a calculation with RKmax=9.
 Probably convergence was spoiled by the occurrence of ghostbands.

 To do it right:

 Do a simple wurzite structure.

 Start with RKmax=5.5 (or even 5.0 )  (see http://www.wien2k.at/reg_user/*
 *faq/rkmax.html http://www.wien2k.at/reg_user/faq/rkmax.html) and do:

 run_lapw -fc 1 -cc 0.0001 check gap and forces.
 save wc_rkm5.5
 increase rkmax to 6.5 in case.in1c
 run_lapw -fc 1 -cc 0.0001check again gap and forces

 any significant changes ? If not, you have found a reasonable rkmax (5.5)
 to go to the large calculation.

 For a BIG calculation ALWAYS start with low convergence parameters
 (which, if possible, should be tested before on a small system).
 Once the BIG calculation has converged and is fully relaxed, you can
 still check your results by increasing RKmax and continuing, but NEVER
 start with such huge values.


 On 09/25/2013 04:22 PM, Luis Ogando wrote:

 Dear Wien2k community,

 We are trying do calculate the influence of zinc blend (ZB) stacking
 faults on InP (sp semiconductor) wurtzite (WZ) systems using Wien2k 13.
 Our first goal is to calculate the band gap change along the c-axis
 (perpendicular to the interface between the two phases), similar to what
 was done in J. Appl. Phys. 114, 033709 (2013) for two semi-infinite
 structures.
 In our case, we use a supercell with three ZB cells along (111)
 (hexagonal form) matched along c to a large sequence of WZ cells to
 guarantee a minimum reproduction of a ZB environment in the stacking
 fault region.
 We have done calculations for a system with 10 WZ cells, but the gap
 did not change along the structure and we are now trying 15 WZ cells and
 the 3 ZB ones (78 atoms in total) to isolate neighbour stacking faults.
 As the gap is our main property, we are using the mBJ potential, but
 we are facing convergence problems at the first (PBE) SCF calculation.
 We would be glad if someone could give us any hint about how to
 improve the PBE scf convergence.
 Here we give some relevant parameters of our calculation (please, do
 not hesitate in asking others):

 *Species: In and P
 *Number of atoms: 78
 *RMT: 2.50 (In) and 2.10 (P)  (NN-DIST= 4.84768)
 

Re: [Wien] SCF convergence

[Peter Blaha]

Reduce RKmax. It is ridiculous to start such a calculation with RKmax=9.
Probably convergence was spoiled by the occurrence of ghostbands.

To do it right:

Do a simple wurzite structure.

Start with RKmax=5.5 (or even 5.0 )  (see 
http://www.wien2k.at/reg_user/faq/rkmax.html) and do:


run_lapw -fc 1 -cc 0.0001 check gap and forces.
save wc_rkm5.5
increase rkmax to 6.5 in case.in1c
run_lapw -fc 1 -cc 0.0001check again gap and forces

any significant changes ? If not, you have found a reasonable rkmax 
(5.5) to go to the large calculation.


For a BIG calculation ALWAYS start with low convergence parameters 
(which, if possible, should be tested before on a small system).
Once the BIG calculation has converged and is fully relaxed, you can 
still check your results by increasing RKmax and continuing, but NEVER 
start with such huge values.


On 09/25/2013 04:22 PM, Luis Ogando wrote:

Dear Wien2k community,

We are trying do calculate the influence of zinc blend (ZB) stacking
faults on InP (sp semiconductor) wurtzite (WZ) systems using Wien2k 13.
Our first goal is to calculate the band gap change along the c-axis
(perpendicular to the interface between the two phases), similar to what
was done in J. Appl. Phys. 114, 033709 (2013) for two semi-infinite
structures.
In our case, we use a supercell with three ZB cells along (111)
(hexagonal form) matched along c to a large sequence of WZ cells to
guarantee a minimum reproduction of a ZB environment in the stacking
fault region.
We have done calculations for a system with 10 WZ cells, but the gap
did not change along the structure and we are now trying 15 WZ cells and
the 3 ZB ones (78 atoms in total) to isolate neighbour stacking faults.
As the gap is our main property, we are using the mBJ potential, but
we are facing convergence problems at the first (PBE) SCF calculation.
We would be glad if someone could give us any hint about how to
improve the PBE scf convergence.
Here we give some relevant parameters of our calculation (please, do
not hesitate in asking others):

*Species: In and P
*Number of atoms: 78
*RMT: 2.50 (In) and 2.10 (P)  (NN-DIST= 4.84768)
*RKmax: 9
*Emax: 5 (spin-orbit effects)
*XC: 13 (PBE)
*core-valence separation energy: -6.0
*GMAX: 20
*Inequivalent Kpoints: 12 increased to 24 after some iterations
*Mixing schema: MSR1 changed to PRATT with 0.15 mixing factor after some
iterations
*Calculation options: run_lapw -p -NI -ec 0.0001 -cc 0.0001 -i 150 -it
** We also attached the energy (Energy.dat) and charge (Charge.dat)
convergence evolution.

Many thanks in advance.
All the best,
 Luis


___
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



--

  P.Blaha
--
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.atWWW: 
http://info.tuwien.ac.at/theochem/

--
___
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] SCF convergence

[Luis Ogando]

Dear Prof. Blaha,

   Thank you for your comments.
   I have reasons to change the default parameters and I would like to
clarify some points:

1) All the structural parameters were taken from optimized WZ and ZB bulk
InP structures using the PBE potential.

2) The increase in the number o K-points I mentioned in my first message
was done only in the a-b (x-y) plane, because there is no sense in
increasing K-points along the huge c-axis of the supercell.

3) Some time ago, there was a message sent to the list saying that an
increase in the Gmax value could improve the calculation performance. I did
some tests in the simple WZ structure and I got a faster calculation with
Gmax=20. This was (more or less) the value cited in the message, but,
unfortunately, I do not remember details (the message is somewhere in my
mailbox).

4) As you noted, the gap is the critical quantity in my calculations and I
did the suggested RKmax tests some time ago. The main parameters in these
tests were (only Gmax and Kpoints are different from that employed in the
supercell):

   *Structure: WZ InP bulk
   *RMT: 2.50 (In) and 2.10 (P)
   *Emax: 5 (spin-orbit effects)
   *XC: 13 (PBE) + mBJ
   *core-valence separation energy: -6.0
   *GMAX: 12 (NOT 20 !!!)
   *Inequivalent Kpoints: 16
   *Calculation options: run_lapw -p -NI -so -ec 0.0001 -cc 0.0001 -i 150
-it

Results:
   RKmax = 5 = gap = 1.556 eV
   RKmax = 6 = gap = 1.467 eV
   RKmax = 7 = gap = 1.476 eV
   RKmax = 8 = gap = 1.486 eV
   RKmax = 9 = gap = 1.493 eV   ( the experimental value is 1.49 eV ;  Appl.
Phys. Lett. 91, 263104 (2007) )
   RKmax = 10 = gap = 1.498 eV

   The difference between the calculated gaps for WZ and ZB bulk structures
is around 98 meV, but I doubt that the 3 ZB layers will reproduce the bulk
gap, so the difference between phases in the supercell must be lower than
98 meV. This is the reason for using RKmax = 9, I would like to get the
best gap value for the WZ region.

   In your message, you commented that the convergence may be disturbed by
ghostbands. Do you believe that the -in1new option can help ?

   I would strongly appreciate any comment / suggestion !
   Thank you again,
 Luis



2013/9/26 Peter Blaha pbl...@theochem.tuwien.ac.at

 Reduce RKmax. It is ridiculous to start such a calculation with RKmax=9.
 Probably convergence was spoiled by the occurrence of ghostbands.

 To do it right:

 Do a simple wurzite structure.

 Start with RKmax=5.5 (or even 5.0 )  (see http://www.wien2k.at/reg_user/**
 faq/rkmax.html http://www.wien2k.at/reg_user/faq/rkmax.html) and do:

 run_lapw -fc 1 -cc 0.0001 check gap and forces.
 save wc_rkm5.5
 increase rkmax to 6.5 in case.in1c
 run_lapw -fc 1 -cc 0.0001check again gap and forces

 any significant changes ? If not, you have found a reasonable rkmax (5.5)
 to go to the large calculation.

 For a BIG calculation ALWAYS start with low convergence parameters (which,
 if possible, should be tested before on a small system).
 Once the BIG calculation has converged and is fully relaxed, you can still
 check your results by increasing RKmax and continuing, but NEVER start with
 such huge values.


 On 09/25/2013 04:22 PM, Luis Ogando wrote:

 Dear Wien2k community,

 We are trying do calculate the influence of zinc blend (ZB) stacking
 faults on InP (sp semiconductor) wurtzite (WZ) systems using Wien2k 13.
 Our first goal is to calculate the band gap change along the c-axis
 (perpendicular to the interface between the two phases), similar to what
 was done in J. Appl. Phys. 114, 033709 (2013) for two semi-infinite
 structures.
 In our case, we use a supercell with three ZB cells along (111)
 (hexagonal form) matched along c to a large sequence of WZ cells to
 guarantee a minimum reproduction of a ZB environment in the stacking
 fault region.
 We have done calculations for a system with 10 WZ cells, but the gap
 did not change along the structure and we are now trying 15 WZ cells and
 the 3 ZB ones (78 atoms in total) to isolate neighbour stacking faults.
 As the gap is our main property, we are using the mBJ potential, but
 we are facing convergence problems at the first (PBE) SCF calculation.
 We would be glad if someone could give us any hint about how to
 improve the PBE scf convergence.
 Here we give some relevant parameters of our calculation (please, do
 not hesitate in asking others):

 *Species: In and P
 *Number of atoms: 78
 *RMT: 2.50 (In) and 2.10 (P)  (NN-DIST= 4.84768)
 *RKmax: 9
 *Emax: 5 (spin-orbit effects)
 *XC: 13 (PBE)
 *core-valence separation energy: -6.0
 *GMAX: 20
 *Inequivalent Kpoints: 12 increased to 24 after some iterations
 *Mixing schema: MSR1 changed to PRATT with 0.15 mixing factor after some
 iterations
 *Calculation options: run_lapw -p -NI -ec 0.0001 -cc 0.0001 -i 150 -it
 ** We also attached the energy (Energy.dat) and charge (Charge.dat)
 convergence evolution.

 Many thanks in advance.
 All the best,
 

[Wien] SCF convergence

[Luis Ogando]

Dear Wien2k community,

   We are trying do calculate the influence of zinc blend (ZB) stacking
faults on InP (sp semiconductor) wurtzite (WZ) systems using Wien2k 13. Our
first goal is to calculate the band gap change along the c-axis
(perpendicular to the interface between the two phases), similar to what
was done in J. Appl. Phys. 114, 033709 (2013) for two semi-infinite
structures.
   In our case, we use a supercell with three ZB cells along (111)
(hexagonal form) matched along c to a large sequence of WZ cells to
guarantee a minimum reproduction of a ZB environment in the stacking fault
region.
   We have done calculations for a system with 10 WZ cells, but the gap did
not change along the structure and we are now trying 15 WZ cells and the 3
ZB ones (78 atoms in total) to isolate neighbour stacking faults.
   As the gap is our main property, we are using the mBJ potential, but we
are facing convergence problems at the first (PBE) SCF calculation.
   We would be glad if someone could give us any hint about how to improve
the PBE scf convergence.
   Here we give some relevant parameters of our calculation (please, do not
hesitate in asking others):

*Species: In and P
*Number of atoms: 78
*RMT: 2.50 (In) and 2.10 (P)  (NN-DIST= 4.84768)
*RKmax: 9
*Emax: 5 (spin-orbit effects)
*XC: 13 (PBE)
*core-valence separation energy: -6.0
*GMAX: 20
*Inequivalent Kpoints: 12 increased to 24 after some iterations
*Mixing schema: MSR1 changed to PRATT with 0.15 mixing factor after some
iterations
*Calculation options: run_lapw -p -NI -ec 0.0001 -cc 0.0001 -i 150 -it
** We also attached the energy (Energy.dat) and charge (Charge.dat)
convergence evolution.


   Many thanks in advance.
   All the best,
Luis


Charge.dat
Description: Binary data


Energy.dat
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] SCF convergence

[Laurence Marks]

It is unlikely that anyone will be able to help without the
case.struct file (as a minimum). I suspect that you have something
wrong with the structure, for instance inappropriate symmetry,
distances, or similar. As a basic point, it is best to use the
defaults unless you have a good reason (one is the # k-points with
larger cells), so GMAX 20  RKMAX 9.0 are probably not appropriate as
well as Emax 5 as you do not have -so.

A simple thing to do is x patchsymm and see what that tells you, it
picks up many errors.

Also, you a viewer to look at your structure to see if it is sensible.

Switching from MSR1 to PRATT won't help, and will almost certainly
make things worse.


On Wed, Sep 25, 2013 at 9:22 AM, Luis Ogando lcoda...@gmail.com wrote:
 Dear Wien2k community,

We are trying do calculate the influence of zinc blend (ZB) stacking
 faults on InP (sp semiconductor) wurtzite (WZ) systems using Wien2k 13. Our
 first goal is to calculate the band gap change along the c-axis
 (perpendicular to the interface between the two phases), similar to what was
 done in J. Appl. Phys. 114, 033709 (2013) for two semi-infinite structures.
In our case, we use a supercell with three ZB cells along (111)
 (hexagonal form) matched along c to a large sequence of WZ cells to
 guarantee a minimum reproduction of a ZB environment in the stacking fault
 region.
We have done calculations for a system with 10 WZ cells, but the gap did
 not change along the structure and we are now trying 15 WZ cells and the 3
 ZB ones (78 atoms in total) to isolate neighbour stacking faults.
As the gap is our main property, we are using the mBJ potential, but we
 are facing convergence problems at the first (PBE) SCF calculation.
We would be glad if someone could give us any hint about how to improve
 the PBE scf convergence.
Here we give some relevant parameters of our calculation (please, do not
 hesitate in asking others):

 *Species: In and P
 *Number of atoms: 78
 *RMT: 2.50 (In) and 2.10 (P)  (NN-DIST= 4.84768)
 *RKmax: 9
 *Emax: 5 (spin-orbit effects)
 *XC: 13 (PBE)
 *core-valence separation energy: -6.0
 *GMAX: 20
 *Inequivalent Kpoints: 12 increased to 24 after some iterations
 *Mixing schema: MSR1 changed to PRATT with 0.15 mixing factor after some
 iterations
 *Calculation options: run_lapw -p -NI -ec 0.0001 -cc 0.0001 -i 150 -it
 ** We also attached the energy (Energy.dat) and charge (Charge.dat)
 convergence evolution.


Many thanks in advance.
All the best,
 Luis



-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
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

[Wien] SCF cycle - mixer not executing

[andrew tan]

Hello all, I am a new Wien2k user and I'm having some problems with running
the SCF cycle for TiC (I am following the user guide for this calculation.)
I am running version 11.1 on Ubuntu 12.04 LTS compiling with gfortran.
Checking the STDOUT I have the following:

 hup: Command not found.

STOP  LAPW0 END
STOP  LAPW1 END
STOP  LAPW2 END
STOP  CORE  END
STOP DSTART ENDS
/home/user/Desktop/Wien2k/mixer: Command not found.

   stop error

I've checked the error files and they are all empty and it seems that mixer
doesn't generate any output files (.error, .scfm, .outputm). When I look at
the final .scf file it says that only one iteration was run.

Other flags I've found are when checking TiC.clmval, TiC.clmsum,
TiC.energy, TiC.output1, TiC.output2 and TiC.scf . The output, scf and
energy files contain constant energies which are not consistent with the
example files for TiC. I'm not sure if this is because the cycle is not
reiterating because of mixer or is failing because of lapw1 or if the
problem is elsewhere. Any help is appreciated.


 Hopefully someone has resolved this problem. Thank you.
___
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] SCF cycle - mixer not executing

[Laurence Marks]

mixer not found means literally that. Probably you did not compile it correctly.

On Tue, Jun 11, 2013 at 1:57 PM, andrew tan andta...@gmail.com wrote:
 Hello all, I am a new Wien2k user and I'm having some problems with running
 the SCF cycle for TiC (I am following the user guide for this calculation.)
 I am running version 11.1 on Ubuntu 12.04 LTS compiling with gfortran.
 Checking the STDOUT I have the following:

 hup: Command not found.

 STOP  LAPW0 END
 STOP  LAPW1 END
 STOP  LAPW2 END
 STOP  CORE  END
 STOP DSTART ENDS
 /home/user/Desktop/Wien2k/mixer: Command not found.

   stop error

 I've checked the error files and they are all empty and it seems that mixer
 doesn't generate any output files (.error, .scfm, .outputm). When I look at
 the final .scf file it says that only one iteration was run.

 Other flags I've found are when checking TiC.clmval, TiC.clmsum, TiC.energy,
 TiC.output1, TiC.output2 and TiC.scf . The output, scf and energy files
 contain constant energies which are not consistent with the example files
 for TiC. I'm not sure if this is because the cycle is not reiterating
 because of mixer or is failing because of lapw1 or if the problem is
 elsewhere. Any help is appreciated.


 Hopefully someone has resolved this problem. Thank you.



-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
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

[Wien] SCF crash, XLF IBM

[Luis Ogando]

Dear Prof. Blaha, Marks and WIEN2k community,

   First of all, I would like to thank your comments on my IBM/XLF problem.
   About the suggestion given by Prof. Blaha, people from RES believe that
the problem is in the writing of case.energy (number of lines, ...) and not
in the reading. Could you please indicate who writes case.energy ?

   About the changes made in the code (asked by Prof. Marks), they sent me
some information:

===

SRC_lapw0:

lapw0.F

*line 256: line break inside a string, solution:

if ((alphax .lt. 0d0) .or. (alphax .gt. 1d0)) stop 'error in case.inhf:
 the fraction of HF exchange should be between 0 and 1'

*several lines: comparison among logical values
 .neq. and .eq. changed by .neqv. and .eqv.

vx_screened.f:

* line 47: .eqv.

SRC_lapw1:

inilpw.f

*line 229: comment with # changed by !

SRC_hf:

calc_exhf.f

several lines : line break inside a format: solution:


write(6,'(valence-valence HF exchange energy in sphere ,i4,
  (mult=,i4,) = ,f22.8, Ry)') 

calc_exhfvv_tmp_.F

line 138.40: 1512-050 (W) Field separator is missing, in literal FMT
specifier, after edit descriptor .  A comma is assumed.

WE DO NOT UNDERSTAND THIS ASSUMPTION

* line 269: changed
igv = (/ 1:ng /) by

igv = (/ (i,i=1,ng) /)

* line 272: changed
igv = (/ 1:(igs-1),(igs+1):ng /) by

igv = (/ (i,i=1,igs-1),(i,i=igs+1,ng) /)

calc_h.F:

* line 290:

indexb(1:nbf,1) = (/1:nbf/) by

indexb(1:nbf,1) = (/ (i,i=1,nbf) /)

* line 421:

the same

* line 424:

again

* problems with line break () in many lines
(1037,1038,1039, 1053, 1054, 1055)

calc_rhovalvxsl.F

* line breaks

* line 25:
r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/1:nr/))-1d0)) by

r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

calc_ucuchucuc.f

line 33:


r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0)


calc_uu.f

line 23:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

calc_uuchucu.f

line 33:


r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))


calc_uuchucuh.f

line 35:


r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

calc_uuguu.f

line 33


r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

calc_uuguuh.f

line 35: the same

calc_uui.f

line 33: the same

calc_uuih.f.

line 35: the same

calc_uvxslug.f


   And it goes on repeating these kinds of problems !!!

===

   Now, they are compiling WIEN2k with lower optimization flags. Let's see
if anything changes.
   All the best,
  Luis
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130322/e0f93f8f/attachment.htm

[Wien] SCF crash, XLF IBM

[Peter Blaha]

Thank's.
As far as I can see, all these problems have been reported before and 
I'll try to fix all of them (most of them are fixed in my source 
already, but as I do not have xlf, )

On 03/22/2013 02:41 PM, Luis Ogando wrote:
 Dear Prof. Blaha, Marks and WIEN2k community,

 First of all, I would like to thank your comments on my IBM/XLF problem.
 About the suggestion given by Prof. Blaha, people from RES believe
 that the problem is in the writing of case.energy (number of lines, ...)
 and not in the reading. Could you please indicate who writes case.energy ?

 About the changes made in the code (asked by Prof. Marks), they sent
 me some information:

 ===

 SRC_lapw0:

 lapw0.F

 *line 256: line break inside a string, solution:

 if ((alphax .lt. 0d0) .or. (alphax .gt. 1d0)) stop 'error in case.inhf:
  the fraction of HF exchange should be between 0 and 1'

 *several lines: comparison among logical values
   .neq. and .eq. changed by .neqv. and .eqv.

 vx_screened.f:

 * line 47: .eqv.

 SRC_lapw1:

 inilpw.f

 *line 229: comment with # changed by !

 SRC_hf:

 calc_exhf.f

 several lines : line break inside a format: solution:


 write(6,'(valence-valence HF exchange energy in sphere ,i4,
   (mult=,i4,) = ,f22.8, Ry)') 

 calc_exhfvv_tmp_.F

 line 138.40: 1512-050 (W) Field separator is missing, in literal FMT
 specifier, after edit descriptor .  A comma is assumed.

 WE DO NOT UNDERSTAND THIS ASSUMPTION

 * line 269: changed
 igv = (/ 1:ng /) by

 igv = (/ (i,i=1,ng) /)

 * line 272: changed
 igv = (/ 1:(igs-1),(igs+1):ng /) by

 igv = (/ (i,i=1,igs-1),(i,i=igs+1,ng) /)

 calc_h.F:

 * line 290:

 indexb(1:nbf,1) = (/1:nbf/) by

 indexb(1:nbf,1) = (/ (i,i=1,nbf) /)

 * line 421:

 the same

 * line 424:

 again

 * problems with line break () in many lines
 (1037,1038,1039, 1053, 1054, 1055)

 calc_rhovalvxsl.F

 * line breaks

 * line 25:
 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/1:nr/))-1d0)) by

 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

 calc_ucuchucuc.f

 line 33:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0)


 calc_uu.f

 line 23:


   r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

 calc_uuchucu.f

 line 33:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))


 calc_uuchucuh.f

 line 35:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

 calc_uuguu.f

 line 33


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

 calc_uuguuh.f

 line 35: the same

 calc_uui.f

 line 33: the same

 calc_uuih.f.

 line 35: the same

 calc_uvxslug.f


 And it goes on repeating these kinds of problems !!!

 ===

 Now, they are compiling WIEN2k with lower optimization flags. Let's
 see if anything changes.
 All the best,
Luis


 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


-- 

   P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: blaha at theochem.tuwien.ac.atWWW: 
http://info.tuwien.ac.at/theochem/
--

[Wien] SCF crash, XLF IBM

[Laurence Marks]

Peter may want to know the full list (his email crossed as I composed
this); if there is anything on the mixer or mini please send those to
me.

One thing as I have been working with someone else who also has aix.
The essl library has some routines with the same names as those in
lapack but different arguments. For certain parts of the mixer do not
work if they are linked against essl first, so compilation options
need to have (if essl is used)  -llapack and -lessl so lapack is
searched first. They probably already know this.

On Fri, Mar 22, 2013 at 8:41 AM, Luis Ogando lcodacal at gmail.com wrote:
 Dear Prof. Blaha, Marks and WIEN2k community,

First of all, I would like to thank your comments on my IBM/XLF problem.
About the suggestion given by Prof. Blaha, people from RES believe that
 the problem is in the writing of case.energy (number of lines, ...) and not
 in the reading. Could you please indicate who writes case.energy ?

About the changes made in the code (asked by Prof. Marks), they sent me
 some information:

 ===

 SRC_lapw0:

 lapw0.F

 *line 256: line break inside a string, solution:

 if ((alphax .lt. 0d0) .or. (alphax .gt. 1d0)) stop 'error in case.inhf:
  the fraction of HF exchange should be between 0 and 1'

 *several lines: comparison among logical values
  .neq. and .eq. changed by .neqv. and .eqv.

 vx_screened.f:

 * line 47: .eqv.

 SRC_lapw1:

 inilpw.f

 *line 229: comment with # changed by !

 SRC_hf:

 calc_exhf.f

 several lines : line break inside a format: solution:


 write(6,'(valence-valence HF exchange energy in sphere ,i4,
   (mult=,i4,) = ,f22.8, Ry)') 

 calc_exhfvv_tmp_.F

 line 138.40: 1512-050 (W) Field separator is missing, in literal FMT
 specifier, after edit descriptor .  A comma is assumed.

 WE DO NOT UNDERSTAND THIS ASSUMPTION

 * line 269: changed
 igv = (/ 1:ng /) by

 igv = (/ (i,i=1,ng) /)

 * line 272: changed
 igv = (/ 1:(igs-1),(igs+1):ng /) by

 igv = (/ (i,i=1,igs-1),(i,i=igs+1,ng) /)

 calc_h.F:

 * line 290:

 indexb(1:nbf,1) = (/1:nbf/) by

 indexb(1:nbf,1) = (/ (i,i=1,nbf) /)

 * line 421:

 the same

 * line 424:

 again

 * problems with line break () in many lines
 (1037,1038,1039, 1053, 1054, 1055)

 calc_rhovalvxsl.F

 * line breaks

 * line 25:
 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/1:nr/))-1d0)) by

 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

 calc_ucuchucuc.f

 line 33:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0)


 calc_uu.f

 line 23:


  r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (i,i=1,nr) /))-1d0))

 calc_uuchucu.f

 line 33:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))


 calc_uuchucuh.f

 line 35:


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

 calc_uuguu.f

 line 33


 r(1:nr) = r0(iat)*exp(dx(iat)*(dble((/ (j,j=1,nr) /))-1d0))

 calc_uuguuh.f

 line 35: the same

 calc_uui.f

 line 33: the same

 calc_uuih.f.

 line 35: the same

 calc_uvxslug.f


And it goes on repeating these kinds of problems !!!

 ===

Now, they are compiling WIEN2k with lower optimization flags. Let's see
 if anything changes.
All the best,
   Luis



-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi

[Wien] SCF crash, XLF IBM

[Luis Ogando]

   Thank you very much Prof. Blaha !!
   I will send your comments to the people from RES.
   All the best,
Luis



2013/3/15 Peter Blaha pblaha at theochem.tuwien.ac.at

 Hard to tell what could cause the problem. Hopefully, the code changes did
 not introduce something odd.

 My suspicion is the xlf compiler, because:

 line   516 in SRC_lapw2/fermi.F   is:

14 READ(ITAP,*) NUM,E1

 and it is reading from a filecase.energy

 A valid case.energy file looks like:
 a) Header lines for each atom in your cell like:
 198.98000200.3  0.3  0.3  0.3  0.3  0.3  0.3
  0.3000
 0  0.3  0.3  0.3  0.3  0.0
  -1.02000  0.3999.0999.0  0.3997.0999.0999.**
 0999.
 0999.0999.0999.0
 
 b)  the coordinates of a k-point and number of bands,
  1.2500E-01 4.545454545455E-02 8.7500E-01 4  4423
   330
  4.0
 c) number of bands (330) lines with num, E
1  -1.76431887534161
2  -1.76416068726848
3  -1.76381815817653
4  -1.76374388956472
5  -1.76356590139222
   ...
 Since these lines are written format free, they may also contain:
4  5.506360437936372E-002

 Reading these lines, the program seems to crash.

 So either it does not read properly some header lines,
 or it has problems to convert a number like  5.506360437936372E-002 with a
 *-format into a real number.

 Just put a print statement after line 516 into the code and compare the
 output with
 case.energy.



 Am 15.03.2013 17:27, schrieb Luis Ogando:

 Dear WIEN2k community,

 I am trying to use WIEN2k 12.1 in the Spanish Supercomputing
 Network (RES), more specifically, the TIRANT machine at Valencia
 University (PowerPC processors and XLF
 compiler). The guys from RES had a hard work to compile WIEN2k (I believe
 mainly due to XLF) and now, we are facing a problem when trying to
 calculate a simple example,
 namely, InP in the zinc blend phase in sequential mode.
 The initialization goes fine, but when I start the SCF cycle, I get:

 STOP  LAPW0 END
 STOP  LAPW1 END
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit '.' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit 'E' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit '-' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-096 A data item processed during an
 integer read is too large.  The program will recover by assigning the data
 item the value 2147483647
 tel:2147483647.

 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit '-' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit '.' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit 'E' in the input file.  The program will
 recover by assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input found the invalid digit '-' in the input file.  The program will
 recover by assuming a zero in
 its place.

 People from RES had to change the source code in order to get a
 successful compilation, but I do not believe that this is the cause of our
 problems.
 I have searched the mailing list without any help and I would really
 appreciate if someone could give us any hint.
 Below, I show some information that I believe may be relevant, but if
 you need any other information, please, ask.
 Many thanks in advance,
  Luis Ogando

 ==**==**
 ==**

 Processor: IBM PowrPC 970+
 Compilers: XLC 11.1 and XLF 13.1
 MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version,
 parallel version not yet tested)
 ==**==**
 ==**
 Compilation options for sequential version:
 O   Compiler options:-qfree=f90 -O5 -qstrict -q64
 -qextname=flush -qdpc
   L   Linker Flags:$(FOPT) -L../SRC_lib -lpthread
 -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/**2.0.2
 -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
   P   Preprocessor flags   '-WF,-DParallel'
   R   R_LIB (LAPACK+BLAS): -lgoto2
 

[Wien] SCF crash, XLF IBM

[Luis Ogando]

Dear WIEN2k community,

   I am trying to use WIEN2k 12.1 in the Spanish Supercomputing Network
(RES), more specifically, the TIRANT machine at Valencia University
(PowerPC processors and XLF compiler). The guys from RES had a hard work to
compile WIEN2k (I believe mainly due to XLF) and now, we are facing a
problem when trying to calculate a simple example, namely, InP in the zinc
blend phase in sequential mode.
   The initialization goes fine, but when I start the SCF cycle, I get:

STOP  LAPW0 END
STOP  LAPW1 END
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '.' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit 'E' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-096 A data item processed during an integer
read is too large.  The program will recover by assigning the data item the
value 2147483647.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '.' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit 'E' in the input file.  The program will
recover by assuming a zero in its place.
fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
input found the invalid digit '-' in the input file.  The program will
recover by assuming a zero in its place.

   People from RES had to change the source code in order to get a
successful compilation, but I do not believe that this is the cause of our
problems.
   I have searched the mailing list without any help and I would really
appreciate if someone could give us any hint.
   Below, I show some information that I believe may be relevant, but if
you need any other information, please, ask.
   Many thanks in advance,
Luis Ogando

==

Processor: IBM PowrPC 970+
Compilers: XLC 11.1 and XLF 13.1
MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel
version not yet tested)
==
Compilation options for sequential version:
O   Compiler options:-qfree=f90 -O5 -qstrict -q64
-qextname=flush -qdpc
 L   Linker Flags:$(FOPT) -L../SRC_lib -lpthread
-L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
-L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
 P   Preprocessor flags   '-WF,-DParallel'
 R   R_LIB (LAPACK+BLAS): -lgoto2
==
Compilation options for parallel version (again, the problem occurs in the
sequential version, parallel version not yet tested)
RP  RP_LIB(SCALAPACK+PBLAS): -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
-L/gpfs/apps/GOTO2/64 -L/gpfs/apps/FFTW/3.3/64/double-xlf/lib
-L/opt/osshpc/mpich-mx/64/lib/ -lgoto2 -lscalapack -lmpich -lfftw3_mpi
-lfftw3
 FP  FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64
-WF,-DFFTW3 -qextname=flush
 MP  MPIRUN command: mpirun -np _NP_ -machinefile _HOSTS_
_EXEC_

==
case.dayfile:
Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb
on s01c2b11 with PID 17405
using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1


start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go)

cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go)

   lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w
   lapw1 -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w
   lapw2-c (14:11:06) Segmentation fault
0.064u 0.033s 0:00.15 60.0% 0+0k 0+0io 0pf+0w
error: command   /gpfs/home_apps/apps/WIEN2K/12.1/lapw2c lapw2.def   failed

   stop error
==

:log
   (init_lapw) options:
Fri Mar 15 14:05:44 CET 2013 (x_lapw) nn -f InPzb
Fri Mar 15 14:05:53 CET 2013 (x) nn
Fri Mar 15 14:06:03 CET 2013 (x) sgroup
Fri Mar 15 14:06:14 CET 2013 (x) symmetry
Fri Mar 15 14:06:33 CET 2013 (x) lstart
Fri Mar 15 14:07:24 CET 2013 (x) kgen
Fri Mar 15 14:07:34 CET 2013 

[Wien] SCF crash, XLF IBM

[Laurence Marks]

Peter may have some ideas but I suspect that you need to tell us what
they changed in the source code. That is very dangerous.

On Fri, Mar 15, 2013 at 11:27 AM, Luis Ogando lcodacal at gmail.com wrote:
 Dear WIEN2k community,

I am trying to use WIEN2k 12.1 in the Spanish Supercomputing Network
 (RES), more specifically, the TIRANT machine at Valencia University (PowerPC
 processors and XLF compiler). The guys from RES had a hard work to compile
 WIEN2k (I believe mainly due to XLF) and now, we are facing a problem when
 trying to calculate a simple example, namely, InP in the zinc blend phase in
 sequential mode.
The initialization goes fine, but when I start the SCF cycle, I get:

 STOP  LAPW0 END
 STOP  LAPW1 END
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit '.' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit 'E' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit '-' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-096 A data item processed during an integer
 read is too large.  The program will recover by assigning the data item the
 value 2147483647.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit '-' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit '.' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit 'E' in the input file.  The program will recover by
 assuming a zero in its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input
 found the invalid digit '-' in the input file.  The program will recover by
 assuming a zero in its place.

People from RES had to change the source code in order to get a
 successful compilation, but I do not believe that this is the cause of our
 problems.
I have searched the mailing list without any help and I would really
 appreciate if someone could give us any hint.
Below, I show some information that I believe may be relevant, but if you
 need any other information, please, ask.
Many thanks in advance,
 Luis Ogando

 ==

 Processor: IBM PowrPC 970+
 Compilers: XLC 11.1 and XLF 13.1
 MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel
 version not yet tested)
 ==
 Compilation options for sequential version:
 O   Compiler options:-qfree=f90 -O5 -qstrict -q64
 -qextname=flush -qdpc
  L   Linker Flags:$(FOPT) -L../SRC_lib -lpthread
 -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
 -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
  P   Preprocessor flags   '-WF,-DParallel'
  R   R_LIB (LAPACK+BLAS): -lgoto2
 ==
 Compilation options for parallel version (again, the problem occurs in the
 sequential version, parallel version not yet tested)
 RP  RP_LIB(SCALAPACK+PBLAS): -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
 -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/FFTW/3.3/64/double-xlf/lib
 -L/opt/osshpc/mpich-mx/64/lib/ -lgoto2 -lscalapack -lmpich -lfftw3_mpi
 -lfftw3
  FP  FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64
 -WF,-DFFTW3 -qextname=flush
  MP  MPIRUN command: mpirun -np _NP_ -machinefile _HOSTS_
 _EXEC_

 ==
 case.dayfile:
 Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb
 on s01c2b11 with PID 17405
 using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1


 start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go)

 cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go)

   lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w
   lapw1 -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w
   lapw2-c (14:11:06) Segmentation fault
 0.064u 0.033s 0:00.15 60.0% 0+0k 0+0io 0pf+0w
 error: command   /gpfs/home_apps/apps/WIEN2K/12.1/lapw2c lapw2.def   failed

   stop error
 ==

 :log
   (init_lapw) 

[Wien] SCF crash, XLF IBM

[Luis Ogando]

   Thank you, Prof. Marks !
   I will contact them askiing for what was changed.
   All the best,
 Luis




2013/3/15 Laurence Marks L-marks at northwestern.edu

 Peter may have some ideas but I suspect that you need to tell us what
 they changed in the source code. That is very dangerous.

 On Fri, Mar 15, 2013 at 11:27 AM, Luis Ogando lcodacal at gmail.com wrote:
  Dear WIEN2k community,
 
 I am trying to use WIEN2k 12.1 in the Spanish Supercomputing Network
  (RES), more specifically, the TIRANT machine at Valencia University
 (PowerPC
  processors and XLF compiler). The guys from RES had a hard work to
 compile
  WIEN2k (I believe mainly due to XLF) and now, we are facing a problem
 when
  trying to calculate a simple example, namely, InP in the zinc blend
 phase in
  sequential mode.
 The initialization goes fine, but when I start the SCF cycle, I get:
 
  STOP  LAPW0 END
  STOP  LAPW1 END
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit '.' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit 'E' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit '-' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-096 A data item processed during an
 integer
  read is too large.  The program will recover by assigning the data item
 the
  value 2147483647.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit '-' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit '.' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit 'E' in the input file.  The program will recover
 by
  assuming a zero in its place.
  fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base
 input
  found the invalid digit '-' in the input file.  The program will recover
 by
  assuming a zero in its place.
 
 People from RES had to change the source code in order to get a
  successful compilation, but I do not believe that this is the cause of
 our
  problems.
 I have searched the mailing list without any help and I would really
  appreciate if someone could give us any hint.
 Below, I show some information that I believe may be relevant, but if
 you
  need any other information, please, ask.
 Many thanks in advance,
  Luis Ogando
 
 
 ==
 
  Processor: IBM PowrPC 970+
  Compilers: XLC 11.1 and XLF 13.1
  MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version,
 parallel
  version not yet tested)
 
 ==
  Compilation options for sequential version:
  O   Compiler options:-qfree=f90 -O5 -qstrict -q64
  -qextname=flush -qdpc
   L   Linker Flags:$(FOPT) -L../SRC_lib -lpthread
  -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
  -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
   P   Preprocessor flags   '-WF,-DParallel'
   R   R_LIB (LAPACK+BLAS): -lgoto2
 
 ==
  Compilation options for parallel version (again, the problem occurs in
 the
  sequential version, parallel version not yet tested)
  RP  RP_LIB(SCALAPACK+PBLAS): -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
  -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/FFTW/3.3/64/double-xlf/lib
  -L/opt/osshpc/mpich-mx/64/lib/ -lgoto2 -lscalapack -lmpich -lfftw3_mpi
  -lfftw3
   FP  FPOPT(par.comp.options): -qfree=f90 -O5 -qstrict -q64
  -WF,-DFFTW3 -qextname=flush
   MP  MPIRUN command: mpirun -np _NP_ -machinefile _HOSTS_
  _EXEC_
 
 
 ==
  case.dayfile:
  Calculating InPzb in /gpfs/home_apps/home/vlc54/vlc54925/Wien/InP/InPzb
  on s01c2b11 with PID 17405
  using WIEN2k_12.1 (Release 22/7/2012) in /gpfs/home_apps/apps/WIEN2K/12.1
 
 
  start (Fri Mar 15 14:10:53 CET 2013) with lapw0 (40/99 to go)
 
  cycle 1 (Fri Mar 15 14:10:53 CET 2013) (40/99 to go)
 
lapw0 (14:10:53) 10.373u 0.274s 0:10.90 97.6% 0+0k 0+0io 1pf+0w
lapw1 -c (14:11:04) 1.489u 0.117s 0:01.67 95.2% 0+0k 0+0io 0pf+0w
lapw2-c 

[Wien] SCF crash, XLF IBM

[Peter Blaha]

Hard to tell what could cause the problem. Hopefully, the code changes did not 
introduce something odd.

My suspicion is the xlf compiler, because:

line   516 in SRC_lapw2/fermi.F   is:

14 READ(ITAP,*) NUM,E1

and it is reading from a filecase.energy

A valid case.energy file looks like:
a) Header lines for each atom in your cell like:
198.98000200.3  0.3  0.3  0.3  0.3  0.3  0.3  0.3000
0  0.3  0.3  0.3  0.3  0.0
  -1.02000  0.3999.0999.0  
0.3997.0999.0999.0999.
0999.0999.0999.0

b)  the coordinates of a k-point and number of bands,
  1.2500E-01 4.545454545455E-02 8.7500E-01 4  4423   330
  4.0
c) number of bands (330) lines with num, E
1  -1.76431887534161
2  -1.76416068726848
3  -1.76381815817653
4  -1.76374388956472
5  -1.76356590139222
   ...
Since these lines are written format free, they may also contain:
4  5.506360437936372E-002

Reading these lines, the program seems to crash.

So either it does not read properly some header lines,
or it has problems to convert a number like  5.506360437936372E-002 with a
*-format into a real number.

Just put a print statement after line 516 into the code and compare the output 
with
case.energy.



Am 15.03.2013 17:27, schrieb Luis Ogando:
 Dear WIEN2k community,

 I am trying to use WIEN2k 12.1 in the Spanish Supercomputing Network 
 (RES), more specifically, the TIRANT machine at Valencia University (PowerPC 
 processors and XLF
 compiler). The guys from RES had a hard work to compile WIEN2k (I believe 
 mainly due to XLF) and now, we are facing a problem when trying to calculate 
 a simple example,
 namely, InP in the zinc blend phase in sequential mode.
 The initialization goes fine, but when I start the SCF cycle, I get:

 STOP  LAPW0 END
 STOP  LAPW1 END
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit '.' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit 'E' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit '-' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-096 A data item processed during an integer 
 read is too large.  The program will recover by assigning the data item the 
 value 2147483647
 tel:2147483647.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit '-' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit '.' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit 'E' in the input file.  The program will recover by 
 assuming a zero in
 its place.
 fermi_tmp_.F, line 516: 1525-097 A READ statement using decimal base input 
 found the invalid digit '-' in the input file.  The program will recover by 
 assuming a zero in
 its place.

 People from RES had to change the source code in order to get a 
 successful compilation, but I do not believe that this is the cause of our 
 problems.
 I have searched the mailing list without any help and I would really 
 appreciate if someone could give us any hint.
 Below, I show some information that I believe may be relevant, but if you 
 need any other information, please, ask.
 Many thanks in advance,
  Luis Ogando

 ==

 Processor: IBM PowrPC 970+
 Compilers: XLC 11.1 and XLF 13.1
 MPI: MPICH-MX 1.2.7 (the problem occurs in the sequential version, parallel 
 version not yet tested)
 ==
 Compilation options for sequential version:
 O   Compiler options:-qfree=f90 -O5 -qstrict -q64
 -qextname=flush -qdpc
   L   Linker Flags:$(FOPT) -L../SRC_lib -lpthread
 -L/gpfs/apps/GOTO2/64 -L/gpfs/apps/SCALAPACK-GOTO2/2.0.2
 -L/opt/ibmcmp/xlf/13.1/lib64 -lxl -lxlf90 -lxlfmath
   P   Preprocessor flags   '-WF,-DParallel'
   R   R_LIB (LAPACK+BLAS): -lgoto2
 ==
 Compilation options for parallel version (again, the problem occurs in the 
 sequential version, parallel version not yet tested)
  RP  

[Wien] scf

[Mourad Karima]

Dear All

I'm studying a 8 atoms supercell of Antiferromgnetic (the rare earth)
In runs I'm getting the problem' there is energy in ? ? SCF NOT CONVERGED 
kGEN =150
kmax=9
gmax=14

this is my last case.inm

MSEC1? 0.0?? YES? (BROYD/PRATT, extra charge (+1 for additional e), norm)
0.20??? mixing FACTOR for BROYD/PRATT scheme
1.00? 1.00? PW and CLM-scaling factors
? 8 idum, HISTORY

so I must stopping the runs or what ? ? I repeat the calculation?

what is this problem due to ? ?

thanks
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121118/b477204b/attachment.htm

[Wien] scf

[Gavin Abo]

What Wien2k version are you using? What cycle did it stop at?

I think you get energy in SCF NOT CONVERGED when the :ENERGY 
convergence value in the case.dayfile has not met the energy 
convergence criteria value that you specified.

If the :ENERGY convergence value is decreasing and stopped after cycle 
40, then you probably just need to run more cycles.  By default, the 
maximum number of cycles is 40.  You can do runsp_lapw -NI to run up 
to another 40 cycles or you could specify the maximum number of cycles, 
for example 80 cycles, with runsp_lapw -i 80 (include also -NI if you 
are continuing a calculation instead of starting a new calculation).

If the :ENERGY convergence value is oscillating, then the calculation 
will likely never convergence (is divergent).  From what I have seen on 
the mailing list, I think the suggested solution that usually works is 
to use PRATT for a few cycles (sometimes using the mixing factor of 
0.1), then switch back to MSEC1.  I suppose you could also try another 
mixer scheme such as MSR1 (which has replaced MSEC1 as the recommended 
default one in Wien2k 12.1).

There is also a smaller possibility that it is caused from a bug in the 
Wien2k version that you are using.  You can check the update list 
(http://www.wien2k.at/reg_user/updates/) to see if there is something 
that might affect your calculation.

On 11/18/2012 10:42 AM, Mourad Karima wrote:
 Dear All

 I'm studying a 8 atoms supercell of Antiferromgnetic (the rare earth)
 In runs I'm getting the problem' there is energy in SCF NOT CONVERGED
 kGEN =150
 kmax=9
 gmax=14

 this is my last case.inm

 MSEC1  0.0   YES  (BROYD/PRATT, extra charge (+1 for additional e), norm)
 0.20mixing FACTOR for BROYD/PRATT scheme
 1.00  1.00  PW and CLM-scaling factors
   8 idum, HISTORY

 so I must stopping the runs or what ?   I repeat the calculation

 what is this problem due to   ?

 thanks



 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121118/2637e2dc/attachment.htm

[Wien] SCF calculation with noncentrosymmetric materials

[EGUCHI Gaku]

Dear Peter Blaha,

Thanks a lot for your reply. I'm happy seeing that we don't need to worry
about the spin-orbit calculation. That's very instructive for me.

---
Dear Fecher, Gerhand,

I also thank a lot to you, and I'd like to report the process, because
case.rsp is successfully generated by the `modified' structure, and
the SCF finished without any problem.

-
1. New session with `No spin-polarized'.
2. [StructGen] and [initialize calc.]. Don't [run SCF] yet.
3. From a terminal (cd to current directory), run `initso_lapw', to run 
symmetso (choose spin-polarized case).
4. Check [StructGen] for the symmetry is reduced and the structural data 
are changed.
5. [initialize calc.] again from first to `prepare input files'.
6. From the terminal, run `x kgen -so' with 'k mesh: 1000', `Yes'.
7. Then go back to [initialize calc.] and restart from `x dstart' to the 
end.
8. [run SCF] without SO, first. -- Finish.
9. [save_lapw] for the first calculation.
10.[run SCF] with SO.
-

I don't examine yet, but the results of the old case.rsp and new one 
should be
identical. The instructions of you both help me very much, and I'd 
sincerely
appreciate you.

Best regards,
Gaku Eguchi


(12/05/29 21:11), Fecher, Gerhard wrote:
 Dear Peter,
 but the problem with the case.rsp exists with initso and spinpolarized cases
 this does for example not allow to do a volume optimization in a straight 
 forward way

 I recocnized that some time ago but had no time to go into the detail
 it would be helpful if initso would also change the case.rsp for 
 spinpolarized cases in addition to the structure


 Ciao
 Gerhard


 
 Dr. Gerhard H. Fecher
 Institut of Inorganic and Analytical Chemistry
 Johannes Gutenberg - University
 55099 Mainz
 
 Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
 zeus.theochem.tuwien.ac.at]quot; im Auftrag vonquot;Peter Blaha [pblaha at 
 theochem.tuwien.ac.at]
 Gesendet: Dienstag, 29. Mai 2012 07:57
 An: A Mailing list for WIEN2k users
 Betreff: Re: [Wien] SCF calculation with noncentrosymmetric materials

 You are saying:

 the band structure of a noncentrosymmetric no spin-polarized materials., 
 e.g.,
 Without spin-polarization initso_lapw does NOT change the struct file !!!

 Also, you do not need to change the k-mesh or worry about non-centrosymmetric 
 symmetry.

 Only for Spin-orbit calculations AND spin-polarization the tim-inversion 
 symmetry is
 broken and symmetso is needed and eventually will reduce your symmetry.
 Spin-orbit alone does not change anything.




 Mo3Al2C, Li2Pt3B (Space group P4332), and LaPt3Si (Space group P4mm).

 What I want to do is that, calculate the bandstructure with/without 
 spin-orbit interaction
 of these noncentrosymmetric, no spin-polarized materials. I usually run SCF 
 with default
 setting, and then `initso' and rerun SCF with spin-orbit. For 
 centrosymmetric materials,
 I haven't had any errors.

 I usually uses w2web, and use `x kgen', but in this case the inversion 
 symmetry is added.
 To avoid it, I run `initso' from the terminal to prepare case.ksym and run 
 `x kgen -so'. Then I could get the correct case.klist, but it ended with the 
 error at the `x dstart'
 attached below.
 -
 Commandline: *x dstart -c -c*
 Program input is: **

 forrtl: severe (24): end-of-file during read, unit 81, file 
 /home/WIEN2k/withSO.rsp
 Image  PCRoutineLineSource
 dstart 004BAF6A  Unknown   Unknown  Unknown
 dstart 004B9AE5  Unknown   Unknown  Unknown
 dstart 00467B96  Unknown   Unknown  Unknown
 dstart 004326C6  Unknown   Unknown  Unknown
 dstart 00431E39  Unknown   Unknown  Unknown
 dstart 00446653  Unknown   Unknown  Unknown
 dstart 0040F4F7  init_  96  init.f
 dstart 0040E39D  MAIN__  9  dstart.f
 dstart 004035DC  Unknown   Unknown  Unknown
 libc.so.6  2BA13ABA1EFF  Unknown   Unknown  Unknown
 dstart 004034D9  Unknown   Unknown  Unknown
 0.000u 0.000s 0:00.00 0.0%0+0k 0+16io 0pf+0w
 error: command   /home/wien2k_v11/dstart dstart.def   failed



 --



 I could not find the solution in ML, and according to UG, the 
 program`symmetso' is for
 the spin-polarized case, and I found another sentence, referring about the 
 inversion
 symmetry on page 148 (OPTIC) as follows:
 --

   0.

  In cases of non-spinpolarized spin-orbit calculations WITHOUT inversion 
 symmetry one must do some tricks and ?mimick

[Wien] SCF calculation with noncentrosymmetric materials

[Peter Blaha]

You are saying:

 the band structure of a noncentrosymmetric no spin-polarized materials., e.g.,

Without spin-polarization initso_lapw does NOT change the struct file !!!

Also, you do not need to change the k-mesh or worry about non-centrosymmetric 
symmetry.

Only for Spin-orbit calculations AND spin-polarization the tim-inversion 
symmetry is
broken and symmetso is needed and eventually will reduce your symmetry.
Spin-orbit alone does not change anything.




 Mo3Al2C, Li2Pt3B (Space group P4332), and LaPt3Si (Space group P4mm).

 What I want to do is that, calculate the bandstructure with/without 
 spin-orbit interaction
 of these noncentrosymmetric, no spin-polarized materials. I usually run SCF 
 with default
 setting, and then `initso' and rerun SCF with spin-orbit. For centrosymmetric 
 materials,
 I haven't had any errors.

 I usually uses w2web, and use `x kgen', but in this case the inversion 
 symmetry is added.
 To avoid it, I run `initso' from the terminal to prepare case.ksym and run `x 
 kgen -so'. Then I could get the correct case.klist, but it ended with the 
 error at the `x dstart'
 attached below.
 -
 Commandline: *x dstart -c -c*
 Program input is: **

 forrtl: severe (24): end-of-file during read, unit 81, file 
 /home/WIEN2k/withSO.rsp
 Image  PCRoutineLineSource
 dstart 004BAF6A  Unknown   Unknown  Unknown
 dstart 004B9AE5  Unknown   Unknown  Unknown
 dstart 00467B96  Unknown   Unknown  Unknown
 dstart 004326C6  Unknown   Unknown  Unknown
 dstart 00431E39  Unknown   Unknown  Unknown
 dstart 00446653  Unknown   Unknown  Unknown
 dstart 0040F4F7  init_  96  init.f
 dstart 0040E39D  MAIN__  9  dstart.f
 dstart 004035DC  Unknown   Unknown  Unknown
 libc.so.6  2BA13ABA1EFF  Unknown   Unknown  Unknown
 dstart 004034D9  Unknown   Unknown  Unknown
 0.000u 0.000s 0:00.00 0.0%0+0k 0+16io 0pf+0w
 error: command   /home/wien2k_v11/dstart dstart.def   failed



 --



 I could not find the solution in ML, and according to UG, the 
 program`symmetso' is for
 the spin-polarized case, and I found another sentence, referring about the 
 inversion
 symmetry on page 148 (OPTIC) as follows:
 --

  0.

 In cases of non-spinpolarized spin-orbit calculations WITHOUT inversion 
 symmetry one must do some tricks and ?mimick? a spinpolarized calculation:

 ? cp case.vsp case.vspup
 ? cp case.vsp case.vspdn
 ? cp case.vectorso case.vectorsoup ? x lapw2 -fermi -so -c
 ? cp case.weight case.weightup
 ? cp case.weight case.weightdn
 ? x optic -so -up
 ? x joint -up

 ---

 Do I need some `special' technique to execute the calculation? Or if someone 
 knows the
 procedure of the calculation I want to do, could you please tell me?

 Thanks in advance and best regards,
 Gaku Eguchi

 --
 
 Gaku Eguchi
 Department of Physics, Graduate School of Science, Kyoto University
 Oiwake-cho, Kitashirakawa, Sakyou-ku, Kyoto 606-8502, Japan
 Laboratory  TEL   : +81-75-753-3744
 E-mail :geguchi at scphys.kyoto-u.ac.jp
 http://www.ss.scphys.kyoto-u.ac.jp/index.html.en
 



 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- 
-
Peter Blaha
Inst. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pblaha at theochem.tuwien.ac.at
-

[Wien] SCF calculation with noncentrosymmetric materials

[Fecher, Gerhard]

Dear Peter,
but the problem with the case.rsp exists with initso and spinpolarized cases
this does for example not allow to do a volume optimization in a straight 
forward way

I recocnized that some time ago but had no time to go into the detail
it would be helpful if initso would also change the case.rsp for spinpolarized 
cases in addition to the structure


Ciao
Gerhard



Dr. Gerhard H. Fecher
Institut of Inorganic and Analytical Chemistry
Johannes Gutenberg - University
55099 Mainz

Von: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
zeus.theochem.tuwien.ac.at]quot; im Auftrag von quot;Peter Blaha [pblaha at 
theochem.tuwien.ac.at]
Gesendet: Dienstag, 29. Mai 2012 07:57
An: A Mailing list for WIEN2k users
Betreff: Re: [Wien] SCF calculation with noncentrosymmetric materials

You are saying:

 the band structure of a noncentrosymmetric no spin-polarized materials., e.g.,

Without spin-polarization initso_lapw does NOT change the struct file !!!

Also, you do not need to change the k-mesh or worry about non-centrosymmetric 
symmetry.

Only for Spin-orbit calculations AND spin-polarization the tim-inversion 
symmetry is
broken and symmetso is needed and eventually will reduce your symmetry.
Spin-orbit alone does not change anything.




 Mo3Al2C, Li2Pt3B (Space group P4332), and LaPt3Si (Space group P4mm).

 What I want to do is that, calculate the bandstructure with/without 
 spin-orbit interaction
 of these noncentrosymmetric, no spin-polarized materials. I usually run SCF 
 with default
 setting, and then `initso' and rerun SCF with spin-orbit. For centrosymmetric 
 materials,
 I haven't had any errors.

 I usually uses w2web, and use `x kgen', but in this case the inversion 
 symmetry is added.
 To avoid it, I run `initso' from the terminal to prepare case.ksym and run `x 
 kgen -so'. Then I could get the correct case.klist, but it ended with the 
 error at the `x dstart'
 attached below.
 -
 Commandline: *x dstart -c -c*
 Program input is: **

 forrtl: severe (24): end-of-file during read, unit 81, file 
 /home/WIEN2k/withSO.rsp
 Image  PCRoutineLineSource
 dstart 004BAF6A  Unknown   Unknown  Unknown
 dstart 004B9AE5  Unknown   Unknown  Unknown
 dstart 00467B96  Unknown   Unknown  Unknown
 dstart 004326C6  Unknown   Unknown  Unknown
 dstart 00431E39  Unknown   Unknown  Unknown
 dstart 00446653  Unknown   Unknown  Unknown
 dstart 0040F4F7  init_  96  init.f
 dstart 0040E39D  MAIN__  9  dstart.f
 dstart 004035DC  Unknown   Unknown  Unknown
 libc.so.6  2BA13ABA1EFF  Unknown   Unknown  Unknown
 dstart 004034D9  Unknown   Unknown  Unknown
 0.000u 0.000s 0:00.00 0.0%0+0k 0+16io 0pf+0w
 error: command   /home/wien2k_v11/dstart dstart.def   failed



 --



 I could not find the solution in ML, and according to UG, the 
 program`symmetso' is for
 the spin-polarized case, and I found another sentence, referring about the 
 inversion
 symmetry on page 148 (OPTIC) as follows:
 --

  0.

 In cases of non-spinpolarized spin-orbit calculations WITHOUT inversion 
 symmetry one must do some tricks and ?mimick? a spinpolarized calculation:

 ? cp case.vsp case.vspup
 ? cp case.vsp case.vspdn
 ? cp case.vectorso case.vectorsoup ? x lapw2 -fermi -so -c
 ? cp case.weight case.weightup
 ? cp case.weight case.weightdn
 ? x optic -so -up
 ? x joint -up

 ---

 Do I need some `special' technique to execute the calculation? Or if someone 
 knows the
 procedure of the calculation I want to do, could you please tell me?

 Thanks in advance and best regards,
 Gaku Eguchi

 --
 
 Gaku Eguchi
 Department of Physics, Graduate School of Science, Kyoto University
 Oiwake-cho, Kitashirakawa, Sakyou-ku, Kyoto 606-8502, Japan
 Laboratory  TEL   : +81-75-753-3744
 E-mail :geguchi at scphys.kyoto-u.ac.jp
 http://www.ss.scphys.kyoto-u.ac.jp/index.html.en
 



 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

--
-
Peter Blaha
Inst. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pblaha at theochem.tuwien.ac.at

[Wien] SCF run problem

[Jagdish Nehra]

Thank you for suggestion sir
As per your suggestion i tried to compile the lapw0 file, but that is
showing some another problem in complie.
I use the command cd /WIEN2K/SRC_lapw0 cat compile.msg then that is
showing a message like as
nehra at nehra-desktop:~/WIEN2k/SRC_lapw0$ cat compile.msg
rm -f *.o *_tmp_.* *.P .sequential .parallel *.mod
if [ -f .parallel ]; then \
   rm -f .parallel modules.o reallocate.o energy.o fftw_para.o getff1.o
getfft.o gtfnam.o lapw0.o rean0.o rean3.o rean4.o setff1.o setff2.o
setfft.o xcpot1.o xcpot3.o zfft3d.o W2kinit.o *.mod; \
fi
touch .sequential
make lapw0 FORT=gfortran FFLAGS=' -ffree-form -O2'
make[1]: Entering directory `/home/nehra/WIEN2k/SRC_lapw0'
gcc -c cputim.c
gfortran -ffree-form -O2 -c modules.F
gfortran -ffree-form -O2 -c reallocate.f
gfortran -ffree-form -O2 -c ainv.f
gfortran -ffree-form -O2 -c am05_xscss.f
gfortran -ffree-form -O2 -c b88.f
gfortran -ffree-form -O2 -c blyp.f
gfortran -ffree-form -O2 -c brj.f
gfortran -ffree-form -O2 -c charg2.f
gfortran -ffree-form -O2 -c charg3.f
gfortran -ffree-form -O2 -c charge.f
gfortran -ffree-form -O2 -c chfac.f
gfortran -ffree-form -O2 -c chslv.f
gfortran -ffree-form -O2 -c corgga.f
gfortran -ffree-form -O2 -c corpbe_revtpss.f
gfortran -ffree-form -O2 -c corpbe_tpss.f
gfortran -ffree-form -O2 -c cub_xc_back.f
gfortran -ffree-form -O2 -c corlsd.f
gfortran -ffree-form -O2 -c dfxhpbe.f
gfortran -ffree-form -O2 -c dfxrevtpss.f
gfortran -ffree-form -O2 -c dfxtpss.f
gfortran -ffree-form -O2 -c drho.f
gfortran -ffree-form -O2 -c dylm.f
gfortran -ffree-form -O2 -c efg.f
gfortran -ffree-form -O2 -c energy.F
gfortran -ffree-form -O2 -c epot1.f
gfortran -ffree-form -O2 -c eramps.f
gfortran -ffree-form -O2 -c errclr.f
gfortran -ffree-form -O2 -c errflg.f
gfortran -ffree-form -O2 -c ev92.f
gfortran -ffree-form -O2 -c ev92ex.f
gfortran -ffree-form -O2 -c exch.f
gfortran -ffree-form -O2 -c exch17.f
gfortran -ffree-form -O2 -c fftw_para.F
gfortran -ffree-form -O2 -c fithi.f
gfortran -ffree-form -O2 -c fxhpbe.f
gfortran -ffree-form -O2 -c fx_revtpss.f
gfortran -ffree-form -O2 -c fx_tpss.f
gfortran -ffree-form -O2 -c gbass.f
gfortran -ffree-form -O2 -c gcor.f
gfortran -ffree-form -O2 -c gea.f
gfortran -ffree-form -O2 -c geaex.f
gfortran -ffree-form -O2 -c getff1.F
gfortran -ffree-form -O2 -c getfft.F
gfortran -ffree-form -O2 -c gpoint.f
gfortran -ffree-form -O2 -c gpointm.f
gfortran -ffree-form -O2 -c grans.f
gfortran -ffree-form -O2 -c gtfnam.F
gfortran -ffree-form -O2 -c hcth.f
gfortran -ffree-form -O2 -c htbs.f
gfortran -ffree-form -O2 -c ifflim.f
gfortran -ffree-form -O2 -c kcis.f
gfortran -ffree-form -O2 -c lapw0.F
gfortran -ffree-form -O2 -c latgen.f
gfortran -ffree-form -O2 -c multfc.f
gfortran -ffree-form -O2 -c multsu.f
gfortran -ffree-form -O2 -c outerr.f
gfortran -ffree-form -O2 -c pbea.f
gfortran -ffree-form -O2 -c pbem.f
gfortran -ffree-form -O2 -c pbe1.f
gfortran -ffree-form -O2 -c pbe2.f
gfortran -ffree-form -O2 -c pbesol.f
gfortran -ffree-form -O2 -c poissn.f
gfortran -ffree-form -O2 -c potfac.f
gfortran -ffree-form -O2 -c pwxad4.f
gfortran -ffree-form -O2 -c pwxad5.f
gfortran -ffree-form -O2 -c qranf.f
gfortran -ffree-form -O2 -c readstruct.f
gfortran -ffree-form -O2 -c rean0.F
gfortran -ffree-form -O2 -c rean1.f
gfortran -ffree-form -O2 -c rean3.F
gfortran -ffree-form -O2 -c rean4.F
gfortran -ffree-form -O2 -c rhopw.f
gfortran -ffree-form -O2 -c rotate.f
gfortran -ffree-form -O2 -c rotdef.f
gfortran -ffree-form -O2 -c rpbe.f
gfortran -ffree-form -O2 -c setff0.f
gfortran -ffree-form -O2 -c setff1.f
gfortran -ffree-form -O2 -c setfft.f
gfortran -ffree-form -O2 -c setff2.f
gfortran -ffree-form -O2 -c seval.f
gfortran -ffree-form -O2 -c sevald.f
gfortran -ffree-form -O2 -c sevaldd.f
gfortran -ffree-form -O2 -c sevali.f
gfortran -ffree-form -O2 -c sevalin.f
gfortran -ffree-form -O2 -c sicpbe.f
gfortran -ffree-form -O2 -c sicpbe_revtpss.f
gfortran -ffree-form -O2 -c sicpbe_tpss.f
gfortran -ffree-form -O2 -c sogga.f
gfortran -ffree-form -O2 -c sphbes.f
gfortran -ffree-form -O2 -c spline.f
gfortran -ffree-form -O2 -c srolyl.f
gfortran -ffree-form -O2 -c stern.f
gfortran -ffree-form -O2 -c sumfac.f
gfortran -ffree-form -O2 -c suml.f
gfortran -ffree-form -O2 -c SymmRot.f
gfortran -ffree-form -O2 -c th1.f
gfortran -ffree-form -O2 -c th2.f
gfortran -ffree-form -O2 -c vpw91.f
gfortran -ffree-form -O2 -c vresp.F
gfortran -ffree-form -O2 -c vs98.f
gfortran -ffree-form -O2 -c vxc15.f
gfortran -ffree-form -O2 -c vxc16.f
gfortran -ffree-form -O2 -c vxc17.f
gfortran -ffree-form -O2 -c vxc24.f
gfortran -ffree-form -O2 -c vxc26.f
gfortran -ffree-form -O2 -c vxclm2.f
gfortran -ffree-form -O2 -c vxcpw2.f
gfortran -ffree-form -O2 -c vxi35.f
gfortran -ffree-form -O2 -c vxi35a.f
gfortran -ffree-form -O2 -c wc05.f
gfortran -ffree-form -O2 -c workf1.f
gfortran -ffree-form -O2 -c xcener.f
gfortran -ffree-form -O2 -c xcpot.f
gfortran -ffree-form -O2 -c xcpot1.f
gfortran -ffree-form -O2 -c xcpot3.F
gfortran -ffree-form -O2 -c ykav.f
gfortran 

[Wien] SCF run problem

[Laurence Marks]

The information is in what you sent, the line /usr/bin/ld: cannot
find -lgoto. Your compilation options include the goto library for
blas commands, but either you do not have this installed or you did
not include information on where it is. For instance, if the file was
in a directory /MyComp/MyDir then you would need to have the option
-L/MyComp/MyDir before the -lgoto (similar to the -L../SRC_lib.

The goto library is something which you can download -- see
http://www.cs.utexas.edu/~flame/goto/signup_first.html

2012/3/28 Jagdish Nehra jpnehra at gmail.com:
 Thank you for suggestion sir
 As per your suggestion i tried to compile the lapw0 file, but that is
 showing some another problem in complie.
 I use the command cd /WIEN2K/SRC_lapw0 cat compile.msg then that is
 showing a message like as
 nehra at nehra-desktop:~/WIEN2k/SRC_lapw0$ cat compile.msg
 rm -f *.o *_tmp_.* *.P .sequential .parallel *.mod
 if [ -f .parallel ]; then \
 ?? rm -f .parallel modules.o reallocate.o energy.o fftw_para.o getff1.o
 getfft.o gtfnam.o lapw0.o rean0.o rean3.o rean4.o setff1.o setff2.o setfft.o
 xcpot1.o xcpot3.o zfft3d.o W2kinit.o *.mod; \
 fi
 touch .sequential
 make lapw0 FORT=gfortran FFLAGS=' -ffree-form -O2'
 make[1]: Entering directory `/home/nehra/WIEN2k/SRC_lapw0'
 gcc -c cputim.c
 gfortran -ffree-form -O2 -c modules.F
 gfortran -ffree-form -O2 -c reallocate.f
 gfortran -ffree-form -O2 -c ainv.f
 gfortran -ffree-form -O2 -c am05_xscss.f
 gfortran -ffree-form -O2 -c b88.f
 gfortran -ffree-form -O2 -c blyp.f
 gfortran -ffree-form -O2 -c brj.f
 gfortran -ffree-form -O2 -c charg2.f
 gfortran -ffree-form -O2 -c charg3.f
 gfortran -ffree-form -O2 -c charge.f
 gfortran -ffree-form -O2 -c chfac.f
 gfortran -ffree-form -O2 -c chslv.f
 gfortran -ffree-form -O2 -c corgga.f
 gfortran -ffree-form -O2 -c corpbe_revtpss.f
 gfortran -ffree-form -O2 -c corpbe_tpss.f
 gfortran -ffree-form -O2 -c cub_xc_back.f
 gfortran -ffree-form -O2 -c corlsd.f
 gfortran -ffree-form -O2 -c dfxhpbe.f
 gfortran -ffree-form -O2 -c dfxrevtpss.f
 gfortran -ffree-form -O2 -c dfxtpss.f
 gfortran -ffree-form -O2 -c drho.f
 gfortran -ffree-form -O2 -c dylm.f
 gfortran -ffree-form -O2 -c efg.f
 gfortran -ffree-form -O2 -c energy.F
 gfortran -ffree-form -O2 -c epot1.f
 gfortran -ffree-form -O2 -c eramps.f
 gfortran -ffree-form -O2 -c errclr.f
 gfortran -ffree-form -O2 -c errflg.f
 gfortran -ffree-form -O2 -c ev92.f
 gfortran -ffree-form -O2 -c ev92ex.f
 gfortran -ffree-form -O2 -c exch.f
 gfortran -ffree-form -O2 -c exch17.f
 gfortran -ffree-form -O2 -c fftw_para.F
 gfortran -ffree-form -O2 -c fithi.f
 gfortran -ffree-form -O2 -c fxhpbe.f
 gfortran -ffree-form -O2 -c fx_revtpss.f
 gfortran -ffree-form -O2 -c fx_tpss.f
 gfortran -ffree-form -O2 -c gbass.f
 gfortran -ffree-form -O2 -c gcor.f
 gfortran -ffree-form -O2 -c gea.f
 gfortran -ffree-form -O2 -c geaex.f
 gfortran -ffree-form -O2 -c getff1.F
 gfortran -ffree-form -O2 -c getfft.F
 gfortran -ffree-form -O2 -c gpoint.f
 gfortran -ffree-form -O2 -c gpointm.f
 gfortran -ffree-form -O2 -c grans.f
 gfortran -ffree-form -O2 -c gtfnam.F
 gfortran -ffree-form -O2 -c hcth.f
 gfortran -ffree-form -O2 -c htbs.f
 gfortran -ffree-form -O2 -c ifflim.f
 gfortran -ffree-form -O2 -c kcis.f
 gfortran -ffree-form -O2 -c lapw0.F
 gfortran -ffree-form -O2 -c latgen.f
 gfortran -ffree-form -O2 -c multfc.f
 gfortran -ffree-form -O2 -c multsu.f
 gfortran -ffree-form -O2 -c outerr.f
 gfortran -ffree-form -O2 -c pbea.f
 gfortran -ffree-form -O2 -c pbem.f
 gfortran -ffree-form -O2 -c pbe1.f
 gfortran -ffree-form -O2 -c pbe2.f
 gfortran -ffree-form -O2 -c pbesol.f
 gfortran -ffree-form -O2 -c poissn.f
 gfortran -ffree-form -O2 -c potfac.f
 gfortran -ffree-form -O2 -c pwxad4.f
 gfortran -ffree-form -O2 -c pwxad5.f
 gfortran -ffree-form -O2 -c qranf.f
 gfortran -ffree-form -O2 -c readstruct.f
 gfortran -ffree-form -O2 -c rean0.F
 gfortran -ffree-form -O2 -c rean1.f
 gfortran -ffree-form -O2 -c rean3.F
 gfortran -ffree-form -O2 -c rean4.F
 gfortran -ffree-form -O2 -c rhopw.f
 gfortran -ffree-form -O2 -c rotate.f
 gfortran -ffree-form -O2 -c rotdef.f
 gfortran -ffree-form -O2 -c rpbe.f
 gfortran -ffree-form -O2 -c setff0.f
 gfortran -ffree-form -O2 -c setff1.f
 gfortran -ffree-form -O2 -c setfft.f
 gfortran -ffree-form -O2 -c setff2.f
 gfortran -ffree-form -O2 -c seval.f
 gfortran -ffree-form -O2 -c sevald.f
 gfortran -ffree-form -O2 -c sevaldd.f
 gfortran -ffree-form -O2 -c sevali.f
 gfortran -ffree-form -O2 -c sevalin.f
 gfortran -ffree-form -O2 -c sicpbe.f
 gfortran -ffree-form -O2 -c sicpbe_revtpss.f
 gfortran -ffree-form -O2 -c sicpbe_tpss.f
 gfortran -ffree-form -O2 -c sogga.f
 gfortran -ffree-form -O2 -c sphbes.f
 gfortran -ffree-form -O2 -c spline.f
 gfortran -ffree-form -O2 -c srolyl.f
 gfortran -ffree-form -O2 -c stern.f
 gfortran -ffree-form -O2 -c sumfac.f
 gfortran -ffree-form -O2 -c suml.f
 gfortran -ffree-form -O2 -c SymmRot.f
 gfortran -ffree-form -O2 -c th1.f
 gfortran -ffree-form -O2 -c th2.f
 gfortran -ffree-form 

[Wien] SCF run problem

[Laurence Marks]

I sent an email about a broken link on the Goto page, and received the
following back. Maybe someone should store copies of the libraries
and/or try the alternatives. (It looks like what remains of Goto is
only for older computers.)

From: Robert van de Geijn r...@cs.utexas.edu

Thank you.  Goto BLAS are no longer maintained.  It moved to the Texas
Advanced Computing Center many years ago.  But Goto has since left
TACC and is now with Microsoft.

May I suggest you look into OpenBLAS or SurvivingGotoBLAS2 instead!
(Don't take this as an endorsement of either.)

On Wed, Mar 28, 2012 at 7:05 AM, Laurence Marks
L-marks at northwestern.edu wrote:
 The information is in what you sent, the line /usr/bin/ld: cannot
 find -lgoto. Your compilation options include the goto library for
 blas commands, but either you do not have this installed or you did
 not include information on where it is. For instance, if the file was
 in a directory /MyComp/MyDir then you would need to have the option
 -L/MyComp/MyDir before the -lgoto (similar to the -L../SRC_lib.

 The goto library is something which you can download -- see
 http://www.cs.utexas.edu/~flame/goto/signup_first.html

 2012/3/28 Jagdish Nehra jpnehra at gmail.com:
 Thank you for suggestion sir
 As per your suggestion i tried to compile the lapw0 file, but that is
 showing some another problem in complie.
 I use the command cd /WIEN2K/SRC_lapw0 cat compile.msg then that is
 showing a message like as
 nehra at nehra-desktop:~/WIEN2k/SRC_lapw0$ cat compile.msg
 rm -f *.o *_tmp_.* *.P .sequential .parallel *.mod
 if [ -f .parallel ]; then \
 ?? rm -f .parallel modules.o reallocate.o energy.o fftw_para.o getff1.o
 getfft.o gtfnam.o lapw0.o rean0.o rean3.o rean4.o setff1.o setff2.o setfft.o
 xcpot1.o xcpot3.o zfft3d.o W2kinit.o *.mod; \
 fi
 touch .sequential
 make lapw0 FORT=gfortran FFLAGS=' -ffree-form -O2'
 make[1]: Entering directory `/home/nehra/WIEN2k/SRC_lapw0'
 gcc -c cputim.c
 gfortran -ffree-form -O2 -c modules.F
 gfortran -ffree-form -O2 -c reallocate.f
 gfortran -ffree-form -O2 -c ainv.f
 gfortran -ffree-form -O2 -c am05_xscss.f
 gfortran -ffree-form -O2 -c b88.f
 gfortran -ffree-form -O2 -c blyp.f
 gfortran -ffree-form -O2 -c brj.f
 gfortran -ffree-form -O2 -c charg2.f
 gfortran -ffree-form -O2 -c charg3.f
 gfortran -ffree-form -O2 -c charge.f
 gfortran -ffree-form -O2 -c chfac.f
 gfortran -ffree-form -O2 -c chslv.f
 gfortran -ffree-form -O2 -c corgga.f
 gfortran -ffree-form -O2 -c corpbe_revtpss.f
 gfortran -ffree-form -O2 -c corpbe_tpss.f
 gfortran -ffree-form -O2 -c cub_xc_back.f
 gfortran -ffree-form -O2 -c corlsd.f
 gfortran -ffree-form -O2 -c dfxhpbe.f
 gfortran -ffree-form -O2 -c dfxrevtpss.f
 gfortran -ffree-form -O2 -c dfxtpss.f
 gfortran -ffree-form -O2 -c drho.f
 gfortran -ffree-form -O2 -c dylm.f
 gfortran -ffree-form -O2 -c efg.f
 gfortran -ffree-form -O2 -c energy.F
 gfortran -ffree-form -O2 -c epot1.f
 gfortran -ffree-form -O2 -c eramps.f
 gfortran -ffree-form -O2 -c errclr.f
 gfortran -ffree-form -O2 -c errflg.f
 gfortran -ffree-form -O2 -c ev92.f
 gfortran -ffree-form -O2 -c ev92ex.f
 gfortran -ffree-form -O2 -c exch.f
 gfortran -ffree-form -O2 -c exch17.f
 gfortran -ffree-form -O2 -c fftw_para.F
 gfortran -ffree-form -O2 -c fithi.f
 gfortran -ffree-form -O2 -c fxhpbe.f
 gfortran -ffree-form -O2 -c fx_revtpss.f
 gfortran -ffree-form -O2 -c fx_tpss.f
 gfortran -ffree-form -O2 -c gbass.f
 gfortran -ffree-form -O2 -c gcor.f
 gfortran -ffree-form -O2 -c gea.f
 gfortran -ffree-form -O2 -c geaex.f
 gfortran -ffree-form -O2 -c getff1.F
 gfortran -ffree-form -O2 -c getfft.F
 gfortran -ffree-form -O2 -c gpoint.f
 gfortran -ffree-form -O2 -c gpointm.f
 gfortran -ffree-form -O2 -c grans.f
 gfortran -ffree-form -O2 -c gtfnam.F
 gfortran -ffree-form -O2 -c hcth.f
 gfortran -ffree-form -O2 -c htbs.f
 gfortran -ffree-form -O2 -c ifflim.f
 gfortran -ffree-form -O2 -c kcis.f
 gfortran -ffree-form -O2 -c lapw0.F
 gfortran -ffree-form -O2 -c latgen.f
 gfortran -ffree-form -O2 -c multfc.f
 gfortran -ffree-form -O2 -c multsu.f
 gfortran -ffree-form -O2 -c outerr.f
 gfortran -ffree-form -O2 -c pbea.f
 gfortran -ffree-form -O2 -c pbem.f
 gfortran -ffree-form -O2 -c pbe1.f
 gfortran -ffree-form -O2 -c pbe2.f
 gfortran -ffree-form -O2 -c pbesol.f
 gfortran -ffree-form -O2 -c poissn.f
 gfortran -ffree-form -O2 -c potfac.f
 gfortran -ffree-form -O2 -c pwxad4.f
 gfortran -ffree-form -O2 -c pwxad5.f
 gfortran -ffree-form -O2 -c qranf.f
 gfortran -ffree-form -O2 -c readstruct.f
 gfortran -ffree-form -O2 -c rean0.F
 gfortran -ffree-form -O2 -c rean1.f
 gfortran -ffree-form -O2 -c rean3.F
 gfortran -ffree-form -O2 -c rean4.F
 gfortran -ffree-form -O2 -c rhopw.f
 gfortran -ffree-form -O2 -c rotate.f
 gfortran -ffree-form -O2 -c rotdef.f
 gfortran -ffree-form -O2 -c rpbe.f
 gfortran -ffree-form -O2 -c setff0.f
 gfortran -ffree-form -O2 -c setff1.f
 gfortran -ffree-form -O2 -c setfft.f
 gfortran -ffree-form -O2 -c setff2.f
 gfortran -ffree-form -O2 -c seval.f
 gfortran 

[Wien] SCF Run problem

[Jagdish Nehra]

?I am running wien2k_11version on a computer of type Intel(R) Core(TM)
2 Duo with
operating system Ubuntu 10.04 LTS, gfortran compiler and GotoBlas2-1.13

After sucessful initialize calculation, the SCF calculation is not
running, and that isshowing ?error like as
 hup: Command not found.

/home/nehra/WIEN2k/lapw0: Command not found.


 stop error
So please help me.

--
Jagdish Nehra
Research Scholar
Department of Physics
Mohan Lal Sukhadia University
Udaipur 313001 (Raj.)
Mob. 09799142333

[Wien] SCF Run problem

[Gavin Abo]

hup: Command not found.- Message is not a problem, ignore this [1]

/home/nehra/WIEN2k/lapw0: Command not found.- lapw0 may need compiled or 
recompiled, check for no errors (cat $WIENROOT/SRC_lapw0/compile.msg; cat 
case_folder_path/*.error) [2]

[1] http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-February/016371.html
[2] http://zeus.theochem.tuwien.ac.at/pipermail/wien/2009-July/011763.html

On 3/25/2012 7:25 AM, Jagdish Nehra wrote:
   I am running wien2k_11version on a computer of type Intel(R) Core(TM)
 2 Duo with
 operating system Ubuntu 10.04 LTS, gfortran compiler and GotoBlas2-1.13

 After sucessful initialize calculation, the SCF calculation is not
 running, and that isshowing  error like as
   hup: Command not found.

 /home/nehra/WIEN2k/lapw0: Command not found.


 stop error
 So please help me.

 --
 Jagdish Nehra
 Research Scholar
 Department of Physics
 Mohan Lal Sukhadia University
 Udaipur 313001 (Raj.)
 Mob. 09799142333
 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

[Wien] SCF 1st cycle keeps on running at LAPW2 and doesn't go further

[Masood Yousaf]

Respected wien2k users

I am facing an unsual problem while running different oxides material on wien2k 
with MBJ. But some of the oxides do not go further from LAPW2 -VRESP. It keeps 
on running but the process never ends . Similar oxides with similar structure 
are successfully executed with MBJ .I tried to adjust the different parameters 
but the first SCF cycle with MBJ keeps on running at LAPW2 . Can anyone Please 
help me and guide me what should I do to resolve this problem .

Very hopeful that someone will come out with a solution to my problem
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120320/aff9451b/attachment.htm

[Wien] SCF 1st cycle keeps on running at LAPW2 and doesn't go further

[Laurence Marks]

Are you using mpi versions ? (Spelling correction)

---
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
Research is to see what everybody else has seen, and to think what nobody
else has thought
Albert Szent-Gyorgi
 On Mar 20, 2012 5:33 AM, Laurence Marks L-marks at northwestern.edu wrote:

 Are youbusibg mpi versions?

 ---
 Professor Laurence Marks
 Department of Materials Science and Engineering
 Northwestern University
 www.numis.northwestern.edu 1-847-491-3996
 Research is to see what everybody else has seen, and to think what nobody
 else has thought
 Albert Szent-Gyorgi
  On Mar 20, 2012 3:40 AM, Masood Yousaf masoodyousaf1 at yahoo.com wrote:

 Respected wien2k users

 I am facing an unsual problem while running different oxides material on
 wien2k with MBJ. But some of the oxides do not go further from LAPW2
 -VRESP. It keeps on running but the process never ends . Similar oxides
 with similar structure are successfully executed with MBJ .I tried to
 adjust the different parameters but the first SCF cycle with MBJ keeps on
 running at LAPW2 . Can anyone Please help me and guide me what should I do
 to resolve this problem .

 Very hopeful that someone will come out with a solution to my problem


 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120320/ab5aab72/attachment.htm

[Wien] SCF 1st cycle keeps on running at LAPW2 and doesn't go further

[Laurence Marks]

I have some ideas what this might be, but to find it will take a
little work. There is a bug of some sort in lapw2 where one can get
a process running forever, but for me it has always been
irreproducible. It sounds like you may have a reproducible example,
which makes it possible to find it.

Are you reasonably familiar with fortran coding? If so I can give you
a number of steps to follow. If you are not please send the files from
save_lapw to my private email as a tar-gz file. (If the
case.clmsum/up/dn are not too large include them, otherwise don't.)
Also include details of exactly what you have done, i.e. the run_XX
commands.

N.B. I may not be able to reproduce it -- that is sometimes the case
if it depends upon the compiler/mpi version.

2012/3/20 Masood Yousaf masoodyousaf1 at yahoo.com:
 Respected wien2k users

 I am facing an unsual problem while running different oxides material on
 wien2k with MBJ. But some of the oxides do not go further from LAPW2 -VRESP.
 It keeps on running but the process never ends . Similar oxides with similar
 structure are successfully executed with MBJ .I tried to adjust the
 different parameters but the first SCF cycle with MBJ keeps on running at
 LAPW2 . Can anyone Please help me and guide me what should I do to resolve
 this problem .

 Very hopeful that someone will come out with a solution to my problem


 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien




-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
Research is to see what everybody else has seen, and to think what
nobody else has thought
Albert Szent-Gyorgi

[Wien] scf error (supercell)

[Saba Sabeti]

Dear Gavin Abo,

Thanks for your attention,

The ifort and mkl versions both are 11.0.
Yes,there's ulimit -s unlimited in my .bashrc.
the system has the same ifort/mkl versions and wien2k version,but actually I 
didn't understand what you meant by compiler setting?
Furthermore,I should add that this system has no error for a half-Heusler, and 
the error is just occurred for a supercell.
Bests
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120221/df947065/attachment.htm

[Wien] scf error (supercell)

[Saba Sabeti]

Dear all,
I encountered this error just after running scf for a 2*2*1 supercell (once 
lapw0 is run)

LAPW0 END
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown?
 Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E?
 Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0???
 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown?
 Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790?
 Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0???
 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line??? 
Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine??? Line???
 Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image? PC??? Routine???
 Line??? Source 
libpthread.so.0??? 0039A4D0C790? Unknown?? Unknown? Unknown
libpthread.so.0??? 0039A4D0C62E? Unknown?? Unknown? Unknown
libguide.so??? 002A971CB3FE? Unknown?? Unknown? Unknown

?? stop error

I should mention that I don't encounter this error on another system.
would you please help me in solving this problem?
thank you so much in advance
regards
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120218/ee835738/attachment.htm

[Wien] scf error (supercell)

[Gavin Abo]

What versions of ifort and mkl are you using?

ulimit -s unlimited in your .bashrc?  If other system has the same 
hardware, are ifort/mkl versions, Wien2k version, and compiler settings 
the same?

On 2/18/2012 2:05 PM, Saba Sabeti wrote:
 Dear all,
 I encountered this error just after running scf for a 2*2*1 supercell 
 (once lapw0 is run)

 LAPW0 END
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown
 forrtl: severe (174): SIGSEGV, segmentation fault occurred
 Image  PCRoutineLine
 Source
 libpthread.so.00039A4D0C790  Unknown   Unknown  
 Unknown
 libpthread.so.00039A4D0C62E  Unknown   Unknown  
 Unknown
 libguide.so002A971CB3FE  Unknown   Unknown  
 Unknown

stop error

 I should mention that I don't encounter this error on another system.
 would you please help me in solving this problem?
 thank you so much in advance
 regards


 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120218/8288f1dc/attachment.htm

[Wien] scf problem

[Ibrahim, El-Said]

Hi ...

during initialize calculation and also when I was runing scf 
I have  Invalid null command.


 Invalid null command.
 LAPW0 END
Invalid null command.
/usr/bin/rasmol/hup: Not a directory.


please tell me if it possible 
how to correct this error

thanks 
Said

[Wien] scf cycle for large cell parameter.

[mayank gupta]

Hi I am a new wien 2k user i am trying to find the cohesive nergy of
Zr metal (hcp) structure . For this i am trying to calculate the total
energy of Zr crystal(assuming its a primitive cell) at large cell
parameter but as i am going beyond 10 A scf cycle doesn't work. there
is an error in lapw0.


-- 
Mayank kumar gupta
Contact No- 9220630179,09869834437

[Wien] SCF cycle stuct in LAPW1

[Arun Kr. Chatterjee]

Dear All Users,
I amrunning wien2k for the case of a vanadium based compound having 14 atoms in 
unit cell.The processor is intel Pentium 4 with ram size of 256 MB and the 
speed is 1.5 GHz.
I could do the initialization without any prublem. The SCF cycle is also o.k 
for LAPW0. But problem starts with LAPW1. It takes abnormally long time ~ 60 
mts and LAPW1 is not even completed, I was rather puzzled and aborted the job. 
Later on I found that the LAPW1 has produced eigenvalues but not the 
eigenvectors. Could this be due to speed of processor or anything else. I 
cannot figure out the problem and SCF cycle does not move to the next stage i.e 
LAPW2. Any suggestion and advice will be well appreciated.
Thanks in advance.

Arun
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20090928/51afc806/attachment.htm

[Wien] SCF cycle stuct in LAPW1

[Laurence Marks]

If you are just using a single Pentium 4 with 256 Mb RAM and a 1.5 GHz
processor you will only be able to do very, very small calculations.
Almost certainly 14 atoms is too many already.  You need to use more
powerful computers.

To give you an idea of what you will need, I have an older cluster of
eight Pentium 4's with 2Gb RAM each and 3.4 GHz processors and this
would be fine for 14 atoms (a bit slow) if the k-points were on
different machines

2009/9/28 Arun Kr. Chatterjee aruna_c at vsnl.net:
 Dear All Users,
 I amrunning wien2k for the case of a vanadium based compound having 14 atoms
 in unit cell.The processor is intel Pentium 4 with ram size of 256 MB and
 the speed is 1.5 GHz.
 I could do the initialization without any prublem. The SCF cycle is also o.k
 for LAPW0. But problem starts with LAPW1. It takes abnormally long time ~ 60
 mts and LAPW1 is not even completed, I was rather puzzled and aborted the
 job. Later on I found that the LAPW1 has produced eigenvalues but not the
 eigenvectors. Could this be due to speed of processor or anything else. I
 cannot figure out the problem and SCF cycle does not move to the next stage
 i.e LAPW2. Any suggestion and advice will be well appreciated.
 Thanks in advance.

 Arun
 ___
 Wien mailing list
 Wien at zeus.theochem.tuwien.ac.at
 http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien





-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Chair, Commission on Electron Crystallography of IUCR
www.numis.northwestern.edu/
Electron crystallography is the branch of science that uses electron
scattering and imaging to study the structure of matter.

[Wien] scf convergence problem of hematite slab

[swati chaudhury]

Dear all Wien users,
   I am in very common scf convergence problem with nonmagnetic 
hematite slab. Details of inputs are given below:
  13 GGA, Cut-off = -9.0RmtKmax = 5.50, Global E-parameter = 0.30 
  Emin = -9.0, Emax = 2.5Mixing factor = 0.40
  Gmax =14.0, K-points = 1
  (2 2 1) type of supercell with 15 bohr slab in the z-direction.
  I have performed many calculations with changing mixing factor 0.40 to 0.10, 
0.01; global E-parameter 0.35, 8 K-points, mixing pattern PRATT rather than 
BROYD, GAUSS rather than TETRA ( evel 0.002 )in case.in2 file. But any 
combination does not help to solve the convergence problem. What will I do now? 
Please suggest.
  Structure file has been attached with this letter.
  I have used wien_07.3 version.
  Thanks in advance.
  Regards.
  swati
   
-- next part --
An HTML attachment was scrubbed...
URL: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20080422/15682b77/attachment.html
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: hem_15slab_super.struct
Url: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20080422/15682b77/hem_15slab_super.ksh