Re: [Wien] ‘mixer’ crashes when forces too large

2013-05-29 Thread Elias Assmann

Dear Laurence and Peter,

Thank you for the suggestion of changing to TOT.  It appears to work (I 
say appears because after 2 iterations I hit the dreaded QTL-B 
error, but still: progress!).


Elias

On 05/25/2013 08:37 AM, Peter Blaha wrote:

I've never seen this before.

Anyway, I suggest that you resubmit with  runsp -I ...

This will switch in case.in2 from FOR to TOT and thus does not calculate
:FSU   (until the partial forces are converged and you get the converged
total forces).


___
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] Problem in SO calculation

2013-05-29 Thread Elias Assmann

On 05/28/2013 05:32 PM, Peter Blaha wrote:

The default value 0.30 has to be changed. Use the –in1ef switch in
runsp_lapw


This is NOT TRUE !  When you use the latest WIEN2k version, I do NOT
recommend  -in1ef anymore.  Any 0.30 will be automatically adjusted to
EF-0.2 Ry.


I think that the FAQ (qtlb, scf) still reflects the old situation: 
changing linearization energies manually, and -in1new, if not -in1ef (s 
-in1new still recommended?).  It might be helpful to change that.


Elias

___
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] QTL -B error in mBJ

2013-05-29 Thread Muhammad Sajjad
Dear Wien2k Users

I am trying to run mBJ for a ternary alloy. everything was right but every
time QTL -B error appears. the error statement is

*[msajjad@msajjad SCF]$ runsp_lapw -cc 0.0001 -in1new 2 -i 100 -NI*
* LAPW0 END*
* LAPW0 END*
* LAPW1 END*
* LAPW1 END*
*L2main - QTL-B Error*
*
*
Please someone let me know the solution to this problem?

With thanks in advance
M. Sajjad
___
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] Problem in SO calculation

2013-05-29 Thread Stefaan Cottenier


I guess that typos in these posts have caused some confusion. Peter, you 
probably meant -in1new instead of -in1ef? Because what you describe 
looks like the definition of -in1ef as it is found in the update list:


VERSION_09.2: 29.9.2009

SRC: various fixes and improvements for the following scripts: 
ana2D_lapw, clean_lapw, dosplot2_lapw, init_lapw, init_phonon_lapw, 
instgen_lapw, lapw0para_lapw, lapw1para_lapw, lapw2para_lapw, 
lapwsopara_lapw, min_lapw, restore_lapw, runfsm_lapw, runsp_c_lapw, 
runsp_lapw, save_lapw, siteconfig_lapw, testpara_lapw, x_lapw.
setrmt_lapw (slightly modified RMT settings), write_in1_lapw has a 
new option [-ef]. When specified, it will only update the default 
energy-parameters 0.3 to EF-0.2. All scf scripts (run_lapw, ) take a 
new switch -in1ef, which activates the new option.

I recommend using -in1ef instead of -in1new N. 

By the way, while searching for this I noticed that the usersguide 
doesn't mention -in1ef at all. The update list is the only source. It 
would be useful to add this to the usersguide.


Stefaan



On 29/05/2013 16:45, Elias Assmann wrote:

On 05/28/2013 05:32 PM, Peter Blaha wrote:

The default value 0.30 has to be changed. Use the –in1ef switch in
runsp_lapw


This is NOT TRUE !  When you use the latest WIEN2k version, I do NOT
recommend  -in1ef anymore.  Any 0.30 will be automatically adjusted to
EF-0.2 Ry.


I think that the FAQ (qtlb, scf) still reflects the old situation:
changing linearization energies manually, and -in1new, if not -in1ef (s
-in1new still recommended?).  It might be helpful to change that.

 Elias


___
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] Compilation errors in mixer and telnes3

2013-05-29 Thread andrew tan
Hello all, I am a new wien2k user and had some problems during the
compilation process. I am running version 11.1 on Ubuntu 12.04 LTS
compiling with gfortran. After running the siteconfig_lapw and trying to
compile all programs I get the following errors:
*
SRC_mixer/compile.msg:make: *** [mixer] Error 1
SRC_telnes3/compile.msg:Error: Unterminated character constant beginning at
(1)
SRC_telnes3/compile.msg:make: *** [describetask.o] Error 1

*
and checking the compile.msg for each I find the following errors:

For SRC_mixer/compile.msg:

*make: *** [mixer] Error 1
make: *** No rule to make target `complex'.  Stop.

*
For SRC_telnes3/compile.msg:

*Error: Unterminated character constant beginning at (1)
make: *** [describetask.o] Error 1
make: *** No rule to make target `complex'.  Stop.


*
I've included both compile.msg files.
During my searches on the mailing list I've found that this 'complex' error
can be ignored for SRC_lapw0 and was wondering if this is also true for my
case. Here is the link:
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04284.html

Thank you.

Andrew Tan
University of Guelph


mixer_compile.msg
Description: Binary data


telnes3_compile.msg
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] Problem in SO calculation

2013-05-29 Thread Peter Blaha

Yes, my doku is sloppy, but I did NOT make a typo.

-in1ef was introduced in WIEN2k_09, but since WIEN2k_10   -in1ef  does 
not appear as switch, because this is the default behavior anyway.


Therefore it has also been removed from the UG (but unfortunately not 
from a faq-page).


-in1new XXstill exists, but usually I do not recommend it either,
because in most cases the default behavior is pretty good. An exeption 
might be extremely small spheres, where the E-bottom/E-top search fails 
or is not optimal.
PS: there will be a small update in the default energies for high-lying 
semicore states in WIEN2k_13.





On 05/29/2013 05:04 PM, Stefaan Cottenier wrote:


I guess that typos in these posts have caused some confusion. Peter, you
probably meant -in1new instead of -in1ef? Because what you describe
looks like the definition of -in1ef as it is found in the update list:

VERSION_09.2: 29.9.2009

 SRC: various fixes and improvements for the following scripts:
ana2D_lapw, clean_lapw, dosplot2_lapw, init_lapw, init_phonon_lapw,
instgen_lapw, lapw0para_lapw, lapw1para_lapw, lapw2para_lapw,
lapwsopara_lapw, min_lapw, restore_lapw, runfsm_lapw, runsp_c_lapw,
runsp_lapw, save_lapw, siteconfig_lapw, testpara_lapw, x_lapw.
 setrmt_lapw (slightly modified RMT settings), write_in1_lapw has a
new option [-ef]. When specified, it will only update the default
energy-parameters 0.3 to EF-0.2. All scf scripts (run_lapw, ) take a
new switch -in1ef, which activates the new option.
 I recommend using -in1ef instead of -in1new N. 

By the way, while searching for this I noticed that the usersguide
doesn't mention -in1ef at all. The update list is the only source. It
would be useful to add this to the usersguide.

Stefaan



On 29/05/2013 16:45, Elias Assmann wrote:

On 05/28/2013 05:32 PM, Peter Blaha wrote:

The default value 0.30 has to be changed. Use the –in1ef switch in
runsp_lapw


This is NOT TRUE !  When you use the latest WIEN2k version, I do NOT
recommend  -in1ef anymore.  Any 0.30 will be automatically adjusted to
EF-0.2 Ry.


I think that the FAQ (qtlb, scf) still reflects the old situation:
changing linearization energies manually, and -in1new, if not -in1ef (s
-in1new still recommended?).  It might be helpful to change that.

 Elias


___
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] Problem in SO calculation

2013-05-29 Thread Gavin Abo
I didn't check carefully, but is seems like run*_lapw scripts without 
-in1ef use:


set in1new = 999

and with -in1ef use:

set in1new = -1

Does this make default -in1ef switch behavior in Wien2k 12.1 not work 
correctly?


On 5/29/2013 8:33 AM, Peter Blaha wrote:

Yes, my doku is sloppy, but I did NOT make a typo.

-in1ef was introduced in WIEN2k_09, but since WIEN2k_10   -in1ef does 
not appear as switch, because this is the default behavior anyway.


Therefore it has also been removed from the UG (but unfortunately not 
from a faq-page).


-in1new XXstill exists, but usually I do not recommend it either,
because in most cases the default behavior is pretty good. An exeption 
might be extremely small spheres, where the E-bottom/E-top search 
fails or is not optimal.
PS: there will be a small update in the default energies for 
high-lying semicore states in WIEN2k_13.





On 05/29/2013 05:04 PM, Stefaan Cottenier wrote:


I guess that typos in these posts have caused some confusion. Peter, you
probably meant -in1new instead of -in1ef? Because what you describe
looks like the definition of -in1ef as it is found in the update list:

VERSION_09.2: 29.9.2009

 SRC: various fixes and improvements for the following scripts:
ana2D_lapw, clean_lapw, dosplot2_lapw, init_lapw, init_phonon_lapw,
instgen_lapw, lapw0para_lapw, lapw1para_lapw, lapw2para_lapw,
lapwsopara_lapw, min_lapw, restore_lapw, runfsm_lapw, runsp_c_lapw,
runsp_lapw, save_lapw, siteconfig_lapw, testpara_lapw, x_lapw.
 setrmt_lapw (slightly modified RMT settings), write_in1_lapw has a
new option [-ef]. When specified, it will only update the default
energy-parameters 0.3 to EF-0.2. All scf scripts (run_lapw, ) take a
new switch -in1ef, which activates the new option.
 I recommend using -in1ef instead of -in1new N. 

By the way, while searching for this I noticed that the usersguide
doesn't mention -in1ef at all. The update list is the only source. It
would be useful to add this to the usersguide.

Stefaan



On 29/05/2013 16:45, Elias Assmann wrote:

On 05/28/2013 05:32 PM, Peter Blaha wrote:

The default value 0.30 has to be changed. Use the –in1ef switch in
runsp_lapw


This is NOT TRUE !  When you use the latest WIEN2k version, I do NOT
recommend  -in1ef anymore.  Any 0.30 will be automatically adjusted to
EF-0.2 Ry.


I think that the FAQ (qtlb, scf) still reflects the old 
situation:

changing linearization energies manually, and -in1new, if not -in1ef (s
-in1new still recommended?).  It might be helpful to change that.

 Elias


___
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] error in lapw2

2013-05-29 Thread ben amara imen
hello
 I'm working on compound with spinell symetry
 When I do ' runsp_lapw' there is  this following error :

 error in Lapw2
'l2main' -QTL-B.GT.15.? Ghosbands, check scf files

But the strange that I did before the same calculation with the same
compound and it worked well
 Can some one help me Please
 best 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] Compilation errors in mixer and telnes3

2013-05-29 Thread Laurence Marks
It can be ignored for the mixer.

On Wed, May 29, 2013 at 10:24 AM, andrew tan andta...@gmail.com wrote:
 Hello all, I am a new wien2k user and had some problems during the
 compilation process. I am running version 11.1 on Ubuntu 12.04 LTS compiling
 with gfortran. After running the siteconfig_lapw and trying to compile all
 programs I get the following errors:

 SRC_mixer/compile.msg:make: *** [mixer] Error 1
 SRC_telnes3/compile.msg:Error: Unterminated character constant beginning at
 (1)
 SRC_telnes3/compile.msg:make: *** [describetask.o] Error 1

 and checking the compile.msg for each I find the following errors:

 For SRC_mixer/compile.msg:

 make: *** [mixer] Error 1
 make: *** No rule to make target `complex'.  Stop.

 For SRC_telnes3/compile.msg:

 Error: Unterminated character constant beginning at (1)
 make: *** [describetask.o] Error 1
 make: *** No rule to make target `complex'.  Stop.


 I've included both compile.msg files.
 During my searches on the mailing list I've found that this 'complex' error
 can be ignored for SRC_lapw0 and was wondering if this is also true for my
 case. Here is the link:
 http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04284.html

 Thank you.

 Andrew Tan
 University of Guelph






-- 
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] Cannot run kpoint parallel jobs - only serial.

2013-05-29 Thread Robert Nichol
Dear community.

I've been utilizing WIEN for a little while now and have spent considerable 
time trying to get the code to work on the Ohio Super Computing Center's ( PBS 
queue system) Oakley Cluster.
If I submit the script for k-point parallelization lapw2 to crashes.
If I submit the script for mpi parallelization, either I get an error in lapw0, 
or lapw0 hangs indefinitely.
It is worth mentioning  that OSC utilizes MVAPICH2 which is an OSU creation 
derived from MPICH

**
[osu6811@oakley02 ti-c-24]$ module avail mvapich

 /usr/local/share/lmodfiles/intel-12.1 
-
  mvapich2/1.7 (default)  mvapich2/1.9  mvapich2/1.9a2-profiling
  mvapich2/1.7-r5140  mvapich2/1.9-profilingmvapich2/1.9b
  mvapich2/1.7-r5140-hwlocmvapich2/1.9a mvapich2/1.9b-profiling
  mvapich2/1.8-r5668  mvapich2/1.9a2mvapich2/1.9rc1
  mvapich2/1.8.1  mvapich2/1.9a2-dbg

 /usr/local/share/lmodfiles/modulefiles 

  hpctoolkit/5.3.2-r3950-mvapich2-1.7hpctoolkit/5.3.2-r3950-mvapich2-1.9 
(default)
  hpctoolkit/5.3.2-r3950-mvapich2-1.8
**

This will be a relatively long email as I attempted to be thorough.  I have 
attached my

I have run serial jobs that give reasonable results.

below is my script for k-point parallel jobs
**
Attached
**

example .machines file generated by kp.pbs
**
Attached
**

 47 k points in case.klist and 47 cores in the .machines file.

The lapw0 and lapw1_1 - lapw1_47 error files are all empty.
**
[osu6811@oakley02 ti-c-24]$ cat lapw2.error
Error in LAPW2
 'LAPW2' - can't open unit: 30
 'LAPW2' -filename: ti-c-24.energy_11
**  testerror: Error in Parallel LAPW2
[osu6811@oakley02 ti-c-24]$
**



not only is case.energy_11 missing, but so is case.energy12 and every 12th 
case.energy file after those (11/12/23/24/35/36/47 are all missing.)



contents of  a case.dayfile
**
Attached
**

Interesting to note this line: running lapw0 in single mode
Apparently lapw0 is not run in parallel and we may own the successful 
termination of lapw0 to that fact.




Information on the login node
**
[osu6811@oakley01 ~]$ lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description:Red Hat Enterprise Linux Server release 6.3 (Santiago)
Release:6.3
Codename:   Santiago
[osu6811@oakley01 ~]$ uname -a
Linux oakley01.osc.eduhttp://oakley01.osc.edu 2.6.32-220.7.1.el6.x86_64 #1 
SMP Fri Feb 10 15:22:22 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
[osu6811@oakley01 ~]$ cat /proc/version
Linux version 2.6.32-220.7.1.el6.x86_64 
(mockbu...@x86-002.build.bos.redhat.commailto:mockbu...@x86-002.build.bos.redhat.com)
 (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Fri Feb 10 
15:22:22 EST 2012
[osu6811@oakley01 ~]$ ifort -v
ifort version 12.1.4
[osu6811@oakley01 ~]$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla 
--enable-bootstrap --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-gnu-unique-object 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre 
--enable-libgcj-multifile --enable-java-maintainer-mode 
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib 
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)
[osu6811@oakley01 ~]$
**



I am running WIEN2k version 12.1




My .bash_profile
**
[osu6811@oakley02 ~]$ cat .bash_profile
[ -f .bashrc ]  source .bashrc
[osu6811@oakley02 ~]$
**

I have attached my .bashrc

Thank you for taking the time.  I apologize in advance for the bulk of this 
email.


Appreciatively,

Robert Nichol




kp.pbs
Description: kp.pbs


ti-c-24.dayfile
Description: ti-c-24.dayfile
. /etc/bashrc

alias ls=ls -F --color
alias trsh=mv -t ~/.trash/

module load mkl
module load mvapich2
module load fftw3

#
# this is for XCRYSDEN 1.5.53; added by XCRYSDEN installation on
# Sun Jan  6 21:31:29 EST 2013
#

Re: [Wien] Cannot run kpoint parallel jobs - only serial.

2013-05-29 Thread Laurence Marks
I strongly suggest that you break things into pieces and test
seperately using an interactive queue, which will make many things
simpler.
a) Is fftw compiled using the mvapich mpicc?
b) Did you try just mvapich (I never got mvapich2 to work right)?
c) Try, interactively, x lapw0 -p (with a hand created .machines file
and interactive) for a simple system.
d) Have you followed the Intel linker suggestions?
e) Are you using the intel compiler (recommended)
f) Are you using a version of mvapich compiled with icc? It may not
matter, but it is safer.
g) Don't use 1 core/k-point, do something simpler such as
12:n0509
12:n0510
12:n0520
11:n0523
lapw0: n0509:8


On Wed, May 29, 2013 at 2:58 PM, Robert Nichol
nichol...@buckeyemail.osu.edu wrote:
 Dear community.



 I've been utilizing WIEN for a little while now and have spent considerable
 time trying to get the code to work on the Ohio Super Computing Center's (
 PBS queue system) Oakley Cluster.

 If I submit the script for k-point parallelization lapw2 to crashes.

 If I submit the script for mpi parallelization, either I get an error in
 lapw0, or lapw0 hangs indefinitely.

 It is worth mentioning  that OSC utilizes MVAPICH2 which is an OSU creation
 derived from MPICH



 **

 [osu6811@oakley02 ti-c-24]$ module avail mvapich



 
 /usr/local/share/lmodfiles/intel-12.1
 -

   mvapich2/1.7 (default)  mvapich2/1.9
 mvapich2/1.9a2-profiling

   mvapich2/1.7-r5140  mvapich2/1.9-profilingmvapich2/1.9b

   mvapich2/1.7-r5140-hwlocmvapich2/1.9a
 mvapich2/1.9b-profiling

   mvapich2/1.8-r5668  mvapich2/1.9a2mvapich2/1.9rc1

   mvapich2/1.8.1  mvapich2/1.9a2-dbg



 
 /usr/local/share/lmodfiles/modulefiles
 

   hpctoolkit/5.3.2-r3950-mvapich2-1.7hpctoolkit/5.3.2-r3950-mvapich2-1.9
 (default)

   hpctoolkit/5.3.2-r3950-mvapich2-1.8

 **



 This will be a relatively long email as I attempted to be thorough.  I have
 attached my



 I have run serial jobs that give reasonable results.



 below is my script for k-point parallel jobs

 **

 Attached

 **



 example .machines file generated by kp.pbs

 **

 Attached

 **



  47 k points in case.klist and 47 cores in the .machines file.



 The lapw0 and lapw1_1 – lapw1_47 error files are all empty.

 **

 [osu6811@oakley02 ti-c-24]$ cat lapw2.error

 Error in LAPW2

  'LAPW2' - can't open unit: 30

  'LAPW2' -filename: ti-c-24.energy_11

 **  testerror: Error in Parallel LAPW2

 [osu6811@oakley02 ti-c-24]$

 **







 not only is case.energy_11 missing, but so is case.energy12 and every 12th
 case.energy file after those (11/12/23/24/35/36/47 are all missing.)







 contents of  a case.dayfile

 **

 Attached

 **



 Interesting to note this line: running lapw0 in single mode

 Apparently lapw0 is not run in parallel and we may own the successful
 termination of lapw0 to that fact.









 Information on the login node

 **

 [osu6811@oakley01 ~]$ lsb_release -a

 LSB Version:
 :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch

 Distributor ID: RedHatEnterpriseServer

 Description:Red Hat Enterprise Linux Server release 6.3 (Santiago)

 Release:6.3

 Codename:   Santiago

 [osu6811@oakley01 ~]$ uname -a

 Linux oakley01.osc.edu 2.6.32-220.7.1.el6.x86_64 #1 SMP Fri Feb 10 15:22:22
 EST 2012 x86_64 x86_64 x86_64 GNU/Linux

 [osu6811@oakley01 ~]$ cat /proc/version

 Linux version 2.6.32-220.7.1.el6.x86_64
 (mockbu...@x86-002.build.bos.redhat.com) (gcc version 4.4.6 20110731 (Red
 Hat 4.4.6-3) (GCC) ) #1 SMP Fri Feb 10 15:22:22 EST 2012

 [osu6811@oakley01 ~]$ ifort -v

 ifort version 12.1.4

 [osu6811@oakley01 ~]$ gcc -v

 Using built-in specs.

 Target: x86_64-redhat-linux

 Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
 --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
 --enable-bootstrap --enable-shared --enable-threads=posix
 --enable-checking=release --with-system-zlib --enable-__cxa_atexit
 --disable-libunwind-exceptions --enable-gnu-unique-object
 --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
 --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
 --enable-libgcj-multifile --enable-java-maintainer-mode
 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
 --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
 --build=x86_64-redhat-linux

 Thread model: posix

 gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC)

 [osu6811@oakley01 ~]$

 **







 I am running WIEN2k version 

[Wien] Supercell calculation dilemma with WIEN2k_12

2013-05-29 Thread Guo-ping Zhang

Dear Peter and Wien2k users,

(Many thanks for your help for my previous questions!)

I was trying to do a supercell calculation (60 atoms) within 28x28x28 
(Angstrom^3), half of which is vacuum. Here are some of the questions that 
I have. (To be sure, I have searched all the previous 110 emails on this 
topic, but failed to notice any solutions to this, except a nice comment 
on the formation energy by Dr. Stefaan Cottenier.)


(1) Problems with the new WIEN2k.

x lapw0 complains the insufficient memory like this,

forrtl: severe (41): insufficient virtual memory

This does not happen in the old wien. So my question is whether I can 
change some parameters in SRC_lapw0, so at least x lapw0 runs.


(2) Problems with the old WIEN2k.

Since the new version does not work, I tried to use the older version, 
which worked well, but there is a problem with RKM. Due to the limit set 
by NMATMAX (=1), the RKM is now truncated to 3.24. To test the vacuum 
thickness effect, I have to increase the thickness, but this further 
reduces RKM to  an even smaller value. Since I am mostly interested in 
unoccupied states several eV above Ef, this casts

doubts on the wien results. (After I compared it with Gaussian results,
I found that APW calculation gives wrong symmetry splitting in those 
unoccupied states, but LAPW is ok).


I really appreciate it if you could give me some suggestions how to get 
the results accurately for such a big system.


If you need additional information,

Many thanks in advance!

Best regards,
Guoping










___
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] Supercell calculation dilemma with WIEN2k_12

2013-05-29 Thread Laurence Marks
For a system like this you need to be using mpi. Depending upon how
patient you are and the cores available to you somewhere in the range
of 16-64 cores. You will never get anywhere otherwise.

On Wed, May 29, 2013 at 6:00 PM, Guo-ping Zhang
gpzh...@femto.indstate.edu wrote:
 Dear Peter and Wien2k users,

 (Many thanks for your help for my previous questions!)

 I was trying to do a supercell calculation (60 atoms) within 28x28x28
 (Angstrom^3), half of which is vacuum. Here are some of the questions that
 I have. (To be sure, I have searched all the previous 110 emails on this
 topic, but failed to notice any solutions to this, except a nice comment
 on the formation energy by Dr. Stefaan Cottenier.)

 (1) Problems with the new WIEN2k.

 x lapw0 complains the insufficient memory like this,

 forrtl: severe (41): insufficient virtual memory

 This does not happen in the old wien. So my question is whether I can
 change some parameters in SRC_lapw0, so at least x lapw0 runs.

 (2) Problems with the old WIEN2k.

 Since the new version does not work, I tried to use the older version,
 which worked well, but there is a problem with RKM. Due to the limit set
 by NMATMAX (=1), the RKM is now truncated to 3.24. To test the vacuum
 thickness effect, I have to increase the thickness, but this further
 reduces RKM to  an even smaller value. Since I am mostly interested in
 unoccupied states several eV above Ef, this casts
 doubts on the wien results. (After I compared it with Gaussian results,
 I found that APW calculation gives wrong symmetry splitting in those
 unoccupied states, but LAPW is ok).

 I really appreciate it if you could give me some suggestions how to get
 the results accurately for such a big system.

 If you need additional information,

 Many thanks in advance!

 Best regards,
 Guoping










 ___
 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



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


Re: [Wien] Problem in SO calculation

2013-05-29 Thread Ghosh SUDDHASATTWA
Dear Dr. Blaha, Dr. Cottenier, 
In my cases with regard to heavy elements, my calculations invariably fails
at the SAME error (whatever ERROR started this thread of posts !!!) if I do
not use the -in1ef switch. (RMT=2.5 Rk_max=8.0, kpoints about 3000) 
The -in1ef switch VERY NICELY changes the linearization energies and I don't
get any warnings during the SCF. A typical in1c file (generated using
-in1ef) I paste below for a 32 atom P1 cell. 

WFFIL  EF=.35314   (WFFIL, WFPRI, ENFIL, SUPWF)
  8.00   104 (R-MT*K-MAX; MAX L IN WF, V-NMT
 .12261   6  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   .12261 0.000 CONT 1
 0   -3.23  0.001 STOP 1
 1   -1.27  0.002 CONT 1
 1   .12261 0.000 CONT 1
 3   .12261 0.005 CONT 1
 2   .12261 0.005 CONT 1
 .12261   6  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   .12261 0.000 CONT 1
 0   -3.23  0.001 STOP 1
 1   -1.27  0.002 CONT 1
 1   .12261 0.000 CONT 1
 3   .12261 0.005 CONT 1
 2   .12261 0.005 CONT 1
 .12261   6  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   .12261 0.000 CONT 1
 0   -3.09  0.001 STOP 1
 1   -1.16  0.002 CONT 1
 1   .12261 0.000 CONT 1
 3   .12261 0.005 CONT 1
 2   .12261 0.005 CONT 1
 .12261   6  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   .12261 0.000 CONT 1
 0   -3.09  0.001 STOP 1
 1   -1.16  0.002 CONT 1
 1   .12261 0.000 CONT 1
 3   .12261 0.005 CONT 1
 2   .12261 0.005 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   4  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -2.30  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   -1.08  0.002 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
APW/LAPW)
 0   -1.22  0.002 CONT 1
 0   .12261 0.000 CONT 1
 1   .12261 0.000 CONT 1
 .12261   3  0  (GLOBAL E-PARAMETER WITH n OTHER 

Re: [Wien] QTL -B error in mBJ

2013-05-29 Thread Muhammad Sajjad
Dear Users
I have found its solution from the mailing list, and up to now the
calculations are running error-less. Thank you

On Wed, May 29, 2013 at 10:48 PM, Muhammad Sajjad sajja...@gmail.comwrote:

 Dear Wien2k Users

 I am trying to run mBJ for a ternary alloy. everything was right but every
 time QTL -B error appears. the error statement is

 *[msajjad@msajjad SCF]$ runsp_lapw -cc 0.0001 -in1new 2 -i 100 -NI*
 * LAPW0 END*
 * LAPW0 END*
 * LAPW1 END*
 * LAPW1 END*
 *L2main - QTL-B Error*
 *
 *
 Please someone let me know the solution to this problem?

 With thanks in advance
 M. Sajjad

___
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