[Wien] AMD or intel CPU

2012-06-28 Thread Peter Blaha 
Intel I7 cpus are SIGNIFICANTLY faster than AMD.

Make sure it is an I7 (not I5,..), because they have the fastest memory 
access and run best with Lapack/Blas (because of the mkl-library) which 
is very important.

At the moment Intel offers:

i7-3820  300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels
 and 51.2 GB/s bandwidth
i7-3930K 600$, 130W, 6 cores, 3.2/3.8 12,  as above

i7-3770K 340$,  77W, 4 cores, 3.5/3.9   ,  8MB  , 2 memory channels
  25.6 GB/s !!!

So I would go clearly for a i7-3820  (or if you have more money) for a 
i7-3930K processor.

The last one (3770K) is produced in the newest technology (power 
saving), but I guess its memory bus is much slower!

Am 27.06.2012 13:53, schrieb ali ghafari:
> Dear Profs. Blaha and users
> We want to buy new computer for Wien2k calculation. The question is
> which kind of platforms (AMD or inlet) are suitable for Wien2k package?
> Best Regards
> Ali
>
>
> ___
> 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
+43-1-5880115671

[Wien] lapw2.def failed ???

2012-06-28 Thread susanta mohanta 
It's difficult always to stop at the final cycle manually. The second
method also does not help.

On Mon, Jun 25, 2012 at 7:59 PM, susanta mohanta wrote:

> thanks to both  Lyudmila Dobysheva and Gavin Abo for your suggestions. I
> am
> trying these fixes.
>
> with regards
> susanta
>
>
> On Mon, Jun 25, 2012 at 6:11 PM, Gavin Abo  wrote:
>
>>  Did you apply the fix to $WIENROOT/SRC_lapw2/l2main.f?
>>
>> You might try and see if it resolves the error. The fix was described at:
>>
>> http://zeus.theochem.tuwien.ac.at/pipermail/wien/2012-May/017010.html
>>
>>
>> On 6/24/2012 11:12 PM, susanta mohanta wrote:
>>
>> Dear Prof. P. Blaha and wien2k users,
>>
>> we are facing a strange kind of problem in 3*3*3 (2*2*2 case
>> also)supercell calculation of
>> antiferromagnetic Cr. The system shows an error like this
>>
>> >   stop error
>>
>> error: command   /home/mishra/wien2k/lapw2 uplapw2.def   failed
>> 2.808u 0.184s 0:02.00 149.0% 0+0k 0+968io 0pf+0w
>>   0.775463595415941754.996137720228755.043014519304
>> >   lapw2 -up(23:58:22)  WARNING: EF not accurate, new 
>> > emin,emax,NE-min,NE-max  0.775463587848595
>> >   lapw1  -dn   (23:57:00) 336.505u 3.180s 1:21.52 416.6%   0+0k 
>> > 0+166840io 0pf+0w
>> >   lapw1  -up   (23:55:40) 338.905u 3.136s 1:19.75 428.8%   0+0k 
>> > 0+166816io 0pf+0w
>> :FORCE convergence: 1 1 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO 0 XCO
>> >   lapw0(23:55:12) 27.109u 0.240s 0:27.37 99.8% 0+0k 0+7400io 0pf+0w
>>
>> cycle 54 (Sun Jun 24 23:55:12 IST 2012)  (347/46 to go)
>>
>> :CHARGE convergence:  1 0.001 -.736
>> :ENERGY convergence:  1 0.0001 .9145
>> >   mixer(23:55:11) 1.240u 0.144s 0:00.56 246.4% 0+0k 0+14680io 0pf+0w
>> >   lcore -dn(23:55:11) 0.036u 0.008s 0:00.04 75.0%  0+0k 0+856io 
>> > 0pf+0w
>> >   lcore -up(23:55:11) 0.036u 0.008s 0:00.04 75.0%  0+0k 0+856io 
>> > 0pf+0w
>> 61.439u 1.900s 0:16.99 372.7%0+0k 0+4488io 0pf+0w
>>   0.775465728942304754.996318253305755.043195022568
>> >   lapw2 -dn(23:54:54)  WARNING: EF not accurate, new 
>> > emin,emax,NE-min,NE-max  0.775465721374979
>> 62.315u 2.016s 0:16.99 378.5%0+0k 0+4488io 0pf+0w
>>   0.775465728942304754.996318253305755.043195022568
>> >   lapw2 -up(23:54:37)  WARNING: EF not accurate, new 
>> > emin,emax,NE-min,NE-max  0.775465721374979
>> >   lapw1  -dn   (23:53:17) 334.468u 3.092s 1:19.74 423.3%   0+0k 
>> > 0+166824io 0pf+0w
>> >   lapw1  -up   (23:51:57) 337.681u 2.816s 1:19.95 425.8%   0+0k 
>> > 0+166832io 0pf+0w
>> >   lapw0(23:51:30) 27.117u 0.260s 0:27.40 99.8% 0+0k 0+7400io 0pf+0w
>>
>> cycle 53 (Sun Jun 24 23:51:30 IST 2012)  (348/47 to go)
>>
>>
>>
>> Though the system seems to be converging completely, the error comes at
>> the last cycle.
>>
>> The problem is only seen in the latest version of wien2k, there is no
>> problem in the older version,
>> even those had published. I have attached the struct file. My IFORT
>> version is 11.1.072.
>>
>> We are unable to figure out the reason behind it ? The shown case shows
>> EF not accurate warnig,
>> but even if the warning is not there the problem arises at the end as
>> shown. we have played with various input
>> parameters like RMT, RKMAX, but problem still persists.
>>
>> Any suggestions will be helpful.
>>
>> Thank you and kind regards
>> Susanta
>>
>>
>>
>>
>>
>>
>> ___
>> Wien mailing listWien at 
>> zeus.theochem.tuwien.ac.athttp://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>
>>
>>
>>
>> ___
>> 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/20120628/244e57a2/attachment.htm>

[Wien] AMD or intel CPU

2012-06-28 Thread venkata ramudu 
Prof.Blaha
Is there possibility to purchase wien2k through a vendor, as we have
procurement problems (like placing order on you) to purchase directly
through you.If yes, can we get for the same price as we are govt. labs
please help us in this regard
thanking you,
**
*B.VENKATARAMUDU
* Scientist
*Defence Metallurgical Research Lab (DMRL)*
Kanchanbagh ,Hyderabad-58
*Mob:09490381127*
*Off:040-24586368*
***
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/c9f38ed1/attachment.htm>

[Wien] AMD or intel CPU

2012-06-28 Thread ali ghafari 
Dear Prof. Blaha
Thank you very much for your professional advice. for optimize system does it 
matter which operating system we use or not? for example Debian is better or 
Ubuntu?
Best Regards
Ali



 From: Peter Blaha 
To: A Mailing list for WIEN2k users  
Sent: Thursday, June 28, 2012 8:44 AM
Subject: Re: [Wien] AMD or intel CPU
 
Intel I7 cpus are SIGNIFICANTLY faster than AMD.

Make sure it is an I7 (not I5,..), because they have the fastest memory access 
and run best with Lapack/Blas (because of the mkl-library) which is very 
important.

At the moment Intel offers:

i7-3820? 300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? and 51.2 GB/s bandwidth
i7-3930K 600$, 130W, 6 cores, 3.2/3.8? ?  12? ? ? ? ,? as above

i7-3770K 340$,? 77W, 4 cores, 3.5/3.9?  ,? 8MB? ? ? , 2 memory channels
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  ? 25.6 GB/s !!!

So I would go clearly for a i7-3820? (or if you have more money) for a i7-3930K 
processor.

The last one (3770K) is produced in the newest technology (power saving), but I 
guess its memory bus is much slower!

Am 27.06.2012 13:53, schrieb ali ghafari:
> Dear Profs. Blaha and users
> We want to buy new computer for Wien2k calculation. The question is
> which kind of platforms (AMD or inlet) are suitable for Wien2k package?
> Best Regards
> Ali
> 
> 
> ___
> 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
+43-1-5880115671


___
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/20120628/bd791716/attachment.htm>

[Wien] AMD or intel CPU

2012-06-28 Thread Peter Blaha 
Use the Linux version which you "know" best, so that you are able to 
configure your Linux properly and install all necessary tools.

Am 28.06.2012 10:20, schrieb ali ghafari:
> Dear Prof. Blaha
> Thank you very much for your professional advice. for optimize system
> does it matter which operating system we use or not? for example Debian
> is better or Ubuntu?
> Best Regards
> Ali
>
> 
> *From:* Peter Blaha 
> *To:* A Mailing list for WIEN2k users 
> *Sent:* Thursday, June 28, 2012 8:44 AM
> *Subject:* Re: [Wien] AMD or intel CPU
>
> Intel I7 cpus are SIGNIFICANTLY faster than AMD.
>
> Make sure it is an I7 (not I5,..), because they have the fastest memory
> access and run best with Lapack/Blas (because of the mkl-library) which
> is very important.
>
> At the moment Intel offers:
>
> i7-3820  300$, 130W, 4 cores, 3.6/3.8GHz, 10MB cache, 4 memory channels
>  and 51.2 GB/s bandwidth
> i7-3930K 600$, 130W, 6 cores, 3.2/3.812,  as above
>
> i7-3770K 340$,  77W, 4 cores, 3.5/3.9  ,  8MB  , 2 memory channels
>  25.6 GB/s !!!
>
> So I would go clearly for a i7-3820  (or if you have more money) for a
> i7-3930K processor.
>
> The last one (3770K) is produced in the newest technology (power
> saving), but I guess its memory bus is much slower!
>
> Am 27.06.2012 13:53, schrieb ali ghafari:
>  > Dear Profs. Blaha and users
>  > We want to buy new computer for Wien2k calculation. The question is
>  > which kind of platforms (AMD or inlet) are suitable for Wien2k package?
>  > Best Regards
>  > Ali
>  >
>  >
>  > ___
>  > Wien mailing list
>  > Wien at zeus.theochem.tuwien.ac.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
> +43-1-5880115671
>
>
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at 
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
>
>
>
> ___
> 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
+43-1-5880115671

[Wien] Runtime Error

2012-06-28 Thread Debojyoti Mukherjee 
Dear Wien2k Users,

I am using Ubuntu operating system with Intel Fortran compiler to compile
wien2k. The compilation showed no error; but at the time of running the
code I am finding the following error:



hup: Command not found.
 LAPW0 END
*** glibc detected *** /home/debojyoti/Software/wien2k/lapw1:
munmap_chunk(): invalid pointer: 0x09709f88 ***
=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x40de4e42]
/lib/i386-linux-gnu/libc.so.6(+0x74525)[0x40de5525]
/home/debojyoti/Software/wien2k/lapw1[0x80d04f2]
/home/debojyoti/Software/wien2k/lapw1[0x8082d54]
/home/debojyoti/Software/wien2k/lapw1[0x80939a5]
/home/debojyoti/Software/wien2k/lapw1[0x807ca21]
/home/debojyoti/Software/wien2k/lapw1[0x804b0c4]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40d8a4d3]
=== Memory map: 
08048000-08193000 r-xp  08:06 7744711
/home/debojyoti/Software/wien2k/lapw1
08193000-0819b000 rw-p 0014a000 08:06 7744711
/home/debojyoti/Software/wien2k/lapw1
0819b000-0840b000 rw-p  00:00 0
094de000-097a rw-p  00:00 0  [heap]
4000-4002 r-xp  08:06 7078795/lib/i386-linux-gnu/
ld-2.15.so
4002-40021000 r--p 0001f000 08:06 7078795/lib/i386-linux-gnu/
ld-2.15.so
40021000-40022000 rw-p 0002 08:06 7078795/lib/i386-linux-gnu/
ld-2.15.so
40022000-40023000 r-xp  00:00 0  [vdso]
40023000-40025000 rw-p  00:00 0
40025000-40371000 r-xp  08:06 7350966
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so
40371000-40378000 rw-p 0034b000 08:06 7350966
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so
40378000-4037d000 rw-p  00:00 0
4037d000-40529000 r-xp  08:06 7351033
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so
40529000-4052d000 rw-p 001ac000 08:06 7351033
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so
4052d000-40cff000 r-xp  08:06 7348996
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so
40cff000-40d08000 rw-p 007d2000 08:06 7348996
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so
40d08000-40d13000 rw-p  00:00 0
40d24000-40d4e000 r-xp  08:06 7078847/lib/i386-linux-gnu/
libm-2.15.so
40d4e000-40d4f000 r--p 00029000 08:06 7078847/lib/i386-linux-gnu/
libm-2.15.so
40d4f000-40d5 rw-p 0002a000 08:06 7078847/lib/i386-linux-gnu/
libm-2.15.so
40d5-40d67000 r-xp  08:06 7078895/lib/i386-linux-gnu/
libpthread-2.15.so
40d67000-40d68000 r--p 00016000 08:06 7078895/lib/i386-linux-gnu/
libpthread-2.15.so
40d68000-40d69000 rw-p 00017000 08:06 7078895/lib/i386-linux-gnu/
libpthread-2.15.so
40d69000-40d6b000 rw-p  00:00 0
40d6b000-40d6e000 r-xp  08:06 7078828/lib/i386-linux-gnu/
libdl-2.15.so
40d6e000-40d6f000 r--p 2000 08:06 7078828/lib/i386-linux-gnu/
libdl-2.15.so
40d6f000-40d7 rw-p 3000 08:06 7078828/lib/i386-linux-gnu/
libdl-2.15.so
40d7-40d71000 rw-p  00:00 0
40d71000-40f1 r-xp  08:06 7078815/lib/i386-linux-gnu/
libc-2.15.so
40f1-40f12000 r--p 0019f000 08:06 7078815/lib/i386-linux-gnu/
libc-2.15.so
40f12000-40f13000 rw-p 001a1000 08:06 7078815/lib/i386-linux-gnu/
libc-2.15.so
40f13000-40f16000 rw-p  00:00 0
40f16000-40f32000 r-xp  08:06 7078836
/lib/i386-linux-gnu/libgcc_s.so.1
40f32000-40f33000 r--p 0001b000 08:06 7078836
/lib/i386-linux-gnu/libgcc_s.so.1
40f33000-40f34000 rw-p 0001c000 08:06 7078836
/lib/i386-linux-gnu/libgcc_s.so.1
40f34000-40f35000 rw-p  00:00 0
40f35000-416ac000 r-xp  08:06 7351127
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so
416ac000-416bc000 rw-p 00777000 08:06 7351127
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so
416bc000-416bd000 rw-p  00:00 0
417a6000-4188f000 rw-p  00:00 0
41df3000-433d9000 r-xp  08:06 7350997
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so
433d9000-43447000 rw-p 015e6000 08:06 7350997
/opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so
43447000-43449000 rw-p  00:00 0
bfd11000-bfd34000 rw-p  00:00 0  [stack]

>   stop error

Can anybody tell me where is the error and how to get rid of this problem?

Thanks in advenced.


--Debojyoti Mukherjee--


-- 
Scientific Officer - D,
Applied Physics Division,
Bhabha Atomic Research Center,
Mumbai - 400085,
India.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/49e6c14f/attachment.htm>

[Wien] Is there any relationship between DOS(E_F) and conductivity?

2012-06-28 Thread Fecher, Gerhard 
Fast answer:
compare Fe and Cu and you have it.

The conductivity depends not only on the DOS at Ef but also on the setails of 
the bandstructure.
There is no way to compare whether Sodium, Copper, or Gold are more metallic or 
not.

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]" im Auftrag von "saeid pourmasoud 
[sa_pourmasoud2007 at yahoo.com]
Gesendet: Donnerstag, 28. Juni 2012 06:45
An: wien at zeus.theochem.tuwien.ac.at
Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity?

Dear All,
We are working on two different metallic compounds. I have calculated
total DOS at Fermi level, DOS(E_F), for these two compounds. Our
result shows that the DOS(E_F) of the first compound is larger than
the  DOS(E_F) of the second compound. Can I conclude from this
observation that the first compound is more metallic than the second
compound? Can we compare conductivity of these two compounds using
their total DOS values at Fermi levels? Can you cite a reference in
this respect?
Best regards,
S. Pourmasoud

[Wien] Problem with wien2k 11

2012-06-28 Thread Jameson Maibam 
Dear Prof. Blaha,
I have installed wien2k11 in my dell core2duo laptop with composer xe 11 update 
9 (l_fcompxe_intel64_2011.11.339_1). I can sucessfully run TiC, VC, ScC and 
similar compounds in fcc structure. But when I tried to calculate ZrO2 in 
monoclinic structure I got the following error:ZrO2 problem
Calculating ZrO2 in /home/james/ZrO2on localhost.localdomain with PID 8700
using WIEN2k_11.1 (Release 14/6/2011) in /home/james/wien2k
start   (Thu Jun 28 14:24:27 IST 2012) with lapw0 (40/99 to go)
cycle 1 (Thu Jun 28 14:24:27 IST 2012)  (40/99 to go)
>   lapw0   (14:24:27) 5.979u 0.380s 0:06.37 99.6%  0+0k 0+6320io 0pf+0w
>   lapw1   (14:24:34) Abort (core dumped)
2.369u 0.289s 0:03.73 70.7% 0+0k 1688+5168io 9pf+0w
error: command   /home/james/wien2k/lapw1 lapw1.def   failed
>   stop error
In another case I installed wien2k11 in my hp corei3 with composer xe 
11.9.2011. In this case even TiC is unable to run. The following message came:
LAPW0 ENDforrtl: severe (174): SIGSEGV, segmentation fault occurred>   stop 
error
Please help me to get me out of these problems.

Yours sincerely
Jameson Maibam
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/1e927e9f/attachment.htm>

[Wien] Is there any relationship between DOS(E_F) and conductivity?

2012-06-28 Thread Vladimir Timochevski 
Hello S. Pourmasoud,

To calculate conductivity (in a "bandstructure" approach), you also need 
to know how many electronic states have non-zero momentum in your 
transport direction (in simple words ...). In other words, you need to 
calculate the Fermi surface projection on the plane, normal to your 
transport direction. Therefore, as Gerhard noticed, conductance also 
depends on details of electronic structure - Fermi surface topology. You 
can check this ref on how to use this approach to calculate transport 
properties:
Phys. Rev. B 57, 8907 (1998).

Vladimir.

===
Dr. Vladimir Timoshevskii (Timochevski)
Department of Physics, McGill University,
3600 rue University, Montreal, QC
Canada H3A 2T8
Tel: +1 (514) 396-8935
Fax: +1 (514) 398-8434
===




On 06/28/12 05:04, Fecher, Gerhard wrote:
> Fast answer:
> compare Fe and Cu and you have it.
>
> The conductivity depends not only on the DOS at Ef but also on the setails of 
> the bandstructure.
> There is no way to compare whether Sodium, Copper, or Gold are more metallic 
> or not.
>
> 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]" im Auftrag von"saeid pourmasoud 
> [sa_pourmasoud2007 at yahoo.com]
> Gesendet: Donnerstag, 28. Juni 2012 06:45
> An: wien at zeus.theochem.tuwien.ac.at
> Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity?
>
> Dear All,
> We are working on two different metallic compounds. I have calculated
> total DOS at Fermi level, DOS(E_F), for these two compounds. Our
> result shows that the DOS(E_F) of the first compound is larger than
> the  DOS(E_F) of the second compound. Can I conclude from this
> observation that the first compound is more metallic than the second
> compound? Can we compare conductivity of these two compounds using
> their total DOS values at Fermi levels? Can you cite a reference in
> this respect?
> Best regards,
> S. Pourmasoud
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


--

[Wien] Problem in LDA+U calculation

2012-06-28 Thread Hena Das 
Thank you for the solution, it is working now.


From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at 
[t...@theochem.tuwien.ac.at]
Sent: Wednesday, June 27, 2012 1:54 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Problem in LDA+U calculation

I have the same problem and the error message in case.outputorbup is
"Conflict in atom orb. number: lorb   3 ne ll   2".
The reason is that in case.dmatup(dn), the blocks for a given atom are
ordered in increasing value of l (even if they are not ordered in case.indmc),
while orb thinks that the order is like in case.inorb.
I solved the problem by ordering the values of l in case.inorb (don't
forget to also order the values of U and J accordingly):
  1 2 2 3
  2 2 2 3
  3 1 2
Then it runs.

Another unrelated problem: during init_lapw, lstart complains about the
values of R0 in case.struct. You have to regenerate case.struct, such that
the values of R0 (they are set automatically) are ok. The values of R0
should never be set manually.


On Wed, 27 Jun 2012, Hena Das wrote:

> @Robert: Yes I used Wien2k orb executables.
> @Tran: I followed your suggestion and tried to do the same in Wien2k. The 
> same error appeared even in Wien2k.
> I tried both options :   1 2 3 2
> 2 2 3 2
>&
> 1 2 2 3
> 2 2 2 3
> Below are the case.indmc and case.inorb files that I have used:
> case.indmc
> -9.  Emin cutoff energy
>  3   number of atoms for which density matrix is 
> calculated
>  1  2  3  2   index of 1st atom, number of L's, L1
>  2  2  3  2   dtto for 2nd atom, repeat NATOM times
>  3  1  2  dtto for 2nd atom, repeat NATOM times
>  0 0   r-index, (l,s)index
> case.inorb
>   1  3  0 nmod, natorb, ipr
> PRATT  1.0BROYD/PRATT, mixing
>   1 2 3 2
>   2 2 3 2
>   3 1 2  iatom nlorb, lorb
>   1  nsic 0..AMF, 1..SIC, 2..HFM
>0.53 0.07
>0.43 0.07U J (Ry)
>0.53 0.07
>0.43 0.07
>0.43 0.07
>
> I hope I am not using any wrong input. Can you please check.
>
> Hena
>
> 
> From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
> zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran 
> at theochem.tuwien.ac.at]
> Sent: Wednesday, June 27, 2012 3:22 AM
> To: wien at zeus.theochem.tuwien.ac.at
> Subject: Re: [Wien] Problem in LDA+U calculation
>
> Dear Hena,
>
> Actually, it should work with WIEN2k (I don't know with Wienncm).
> I have tried myself on NiO with
> l=1 and 2 on nickel and l=1 on oxygen and it's running properly.
> The first thing you should do is to try with WIEN2k and
> see if it works or not. If it works with WIEN2k, but not with
> Wienncm, it could be that also a c-shell script of Wienncm has to be
> modified.
>
> But just in case, you can also try this:
>
> replace
>
>   1 2 3 2
>   2 2 3 2
>
> by
>
>   1 2 2 3
>   2 2 2 3
>
> in case.indmc and case.inorb
>
> F. Tran
>
> On 25.06.2012 17:45, Hena Das wrote:
>
> >I am doing a scf calculation for a particular non-collinear spin
> >configuration. A am using LDA+U method. When I use the following
> >case.inorb and case.indmc files:
> >case.inorb
> > 1  3  0 nmod, natorb, ipr
> >PRATT  1.0BROYD/PRATT, mixing
> >  1 1 3
> >  2 1 3
> >  3 1 2
> >  1  nsic 0..AMF, 1..SIC, 2..HFM
> >   0.65 0.07U J (Ry)
> >   0.65 0.07
> >   0.45 0.07
> >case.indmc
> >-9.  Emin cutoff energy
> > 3   number of atoms for which density matrix is
> >calculated
> > 1  1  3  index of 1st atom, number of L's, L1
> > 2  1  3  dtto for 2nd atom, repeat NATOM times
> > 3  1  2  index of 1st atom, number of L's, L1
> > 0 0   r-index, (l,s)index
> >
> >the program executes properly without any error. However when I use the
> >other set of case.inorb and case.indmc files:
> >case.inorb
> >  1  3  0 nmod, natorb, ipr
> >PRATT  1.0BROYD/PRATT, mixing
> >  1 2 3 2
> >  2 2 3 2
> >  3 1 2
> >  1  nsic 0..AMF, 1..SIC, 2..HFM
> >   0.65 0.07
> >   0.45 0.07U J (Ry)
> >   0.65 0.07
> >   0.45 0.07
> >   0.45 0.07
> >case.indmc
> >-9.  Emin cutoff energy
> > 3   number of atoms for which density matrix is
> >calculated
> > 1  2  3  2  index of 1st atom, number of L's, L1
> > 2  2  3  2  dtto for 2nd atom, repeat NATOM times
> > 3  1  2  index of 1st atom, number of L's, L1
> > 0 0   r-index, (l,s)index
> >the program stops by giving the error: error

[Wien] spin and orbital moments

2012-06-28 Thread Kateryna Foyevtsova 
Dear Wien2k developers,

I use wien2k version 11.1 to run spin-polarized GGA+U calculations with
SO coupling for a molibdenum oxide.
The symmetry of the system is the following

bleblebles-o calc. M||  1.00  1.00 -1.00
P   15 2 P-
 RELA
 13.669712 13.669712 13.669712 60.00 60.00 60.00

As you see, I set magnetization axis to 1 1 -1, which should be in terms
of (non-orthogonal) lattice vectors.
With the help of xcrysden and case.outsymso, I can deduce that this
direction corresponds to the 0.577350, 0.816497, 0 direction in terms of
the cartesian global coordinate system.

When I converge the electron density with (without using any previously
converged non-relativistic calculation)

runsp_lapw -p -orb -so -dm

I get the following data for the first and the last iteration on one of
the Mo atoms:

1. iteration:
:SPI005:  SPIN MOMENT:   0.46560   0.80642  -0.53749 PROJECTION ON M
1.07518
:ORB005:  ORBITAL MOMENT: -0.08361 -0.01872  0.02851 PROJECTION ON M
-0.06454
:MMI005: MAGNETIC MOMENT IN SPHERE   5=1.86180

last iteration (converged solution):
:SPI005:  SPIN MOMENT:   0.61653   1.06239  -0.70860 PROJECTION ON M
1.41804
:ORB005:  ORBITAL MOMENT: -0.08361 -0.01872  0.02851 PROJECTION ON M
-0.06454
:MMI005: MAGNETIC MOMENT IN SPHERE   5=1.43149

Now, I am struggling to understand two things:
1) In which coordinate system are SPI005 and ORB005 given?
If they were given in the global cartesian coordinate system, they would
be parallel to 0.577350, 0.816497, 0, but they are not.

2) Why for the first iteration MMI005 is not even roughly equal to
SPI005 + ORB005?

Thank you very much!
Kateryna Foyevtsova

P.S. When I perform relativistic calculations starting with a
preconverged electron density of the non-relativistic solution I get the
same final result.

[Wien] Problem in LDA+U calculation

2012-06-28 Thread t...@theochem.tuwien.ac.at 
Ok. There was another problem with your case.struct: the RMT of
some atoms were too small, leading to core leakage (during init_lapw).
Also, with LDA+U it is better to use large RMT because U is applied only
inside the sphere.

On Thu, 28 Jun 2012, Hena Das wrote:

> Thank you for the solution, it is working now.
> 
> 
> From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
> zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran 
> at theochem.tuwien.ac.at]
> Sent: Wednesday, June 27, 2012 1:54 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] Problem in LDA+U calculation
> 
> I have the same problem and the error message in case.outputorbup is
> "Conflict in atom orb. number: lorb   3 ne ll   2".
> The reason is that in case.dmatup(dn), the blocks for a given atom are
> ordered in increasing value of l (even if they are not ordered in case.indmc),
> while orb thinks that the order is like in case.inorb.
> I solved the problem by ordering the values of l in case.inorb (don't
> forget to also order the values of U and J accordingly):
>   1 2 2 3
>   2 2 2 3
>   3 1 2
> Then it runs.
> 
> Another unrelated problem: during init_lapw, lstart complains about the
> values of R0 in case.struct. You have to regenerate case.struct, such that
> the values of R0 (they are set automatically) are ok. The values of R0
> should never be set manually.
> 
> 
> On Wed, 27 Jun 2012, Hena Das wrote:
> 
> > @Robert: Yes I used Wien2k orb executables.
> > @Tran: I followed your suggestion and tried to do the same in Wien2k. The 
> > same error appeared even in Wien2k.
> > I tried both options :   1 2 3 2
> > 2 2 3 2
> >&
> > 1 2 2 3
> > 2 2 2 3
> > Below are the case.indmc and case.inorb files that I have used:
> > case.indmc
> > -9.  Emin cutoff energy
> >  3   number of atoms for which density matrix is 
> > calculated
> >  1  2  3  2   index of 1st atom, number of L's, L1
> >  2  2  3  2   dtto for 2nd atom, repeat NATOM times
> >  3  1  2  dtto for 2nd atom, repeat NATOM times
> >  0 0   r-index, (l,s)index
> > case.inorb
> >   1  3  0 nmod, natorb, ipr
> > PRATT  1.0BROYD/PRATT, mixing
> >   1 2 3 2
> >   2 2 3 2
> >   3 1 2  iatom nlorb, lorb
> >   1  nsic 0..AMF, 1..SIC, 2..HFM
> >0.53 0.07
> >0.43 0.07U J (Ry)
> >0.53 0.07
> >0.43 0.07
> >0.43 0.07
> >
> > I hope I am not using any wrong input. Can you please check.
> >
> > Hena
> >
> > 
> > From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
> > zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at 
> > [tran at theochem.tuwien.ac.at]
> > Sent: Wednesday, June 27, 2012 3:22 AM
> > To: wien at zeus.theochem.tuwien.ac.at
> > Subject: Re: [Wien] Problem in LDA+U calculation
> >
> > Dear Hena,
> >
> > Actually, it should work with WIEN2k (I don't know with Wienncm).
> > I have tried myself on NiO with
> > l=1 and 2 on nickel and l=1 on oxygen and it's running properly.
> > The first thing you should do is to try with WIEN2k and
> > see if it works or not. If it works with WIEN2k, but not with
> > Wienncm, it could be that also a c-shell script of Wienncm has to be
> > modified.
> >
> > But just in case, you can also try this:
> >
> > replace
> >
> >   1 2 3 2
> >   2 2 3 2
> >
> > by
> >
> >   1 2 2 3
> >   2 2 2 3
> >
> > in case.indmc and case.inorb
> >
> > F. Tran
> >
> > On 25.06.2012 17:45, Hena Das wrote:
> >
> > >I am doing a scf calculation for a particular non-collinear spin
> > >configuration. A am using LDA+U method. When I use the following
> > >case.inorb and case.indmc files:
> > >case.inorb
> > > 1  3  0 nmod, natorb, ipr
> > >PRATT  1.0BROYD/PRATT, mixing
> > >  1 1 3
> > >  2 1 3
> > >  3 1 2
> > >  1  nsic 0..AMF, 1..SIC, 2..HFM
> > >   0.65 0.07U J (Ry)
> > >   0.65 0.07
> > >   0.45 0.07
> > >case.indmc
> > >-9.  Emin cutoff energy
> > > 3   number of atoms for which density matrix is
> > >calculated
> > > 1  1  3  index of 1st atom, number of L's, L1
> > > 2  1  3  dtto for 2nd atom, repeat NATOM times
> > > 3  1  2  index of 1st atom, number of L's, L1
> > > 0 0   r-index, (l,s)index
> > >
> > >the program executes properly without any error. However when I use the
> > >other set of case.inorb and case.indmc files:
> > >case.inorb
> > >  1  3  0 nmod, natorb, ipr
> > >PRATT  1.0BROYD/PRATT, mixing
> > >  1 2 3 2
> > >  2 2 3 2
> > >  3 1 2
> > >  1  nsic 0..AM

[Wien] Problem in LDA+U calculation

2012-06-28 Thread Hena Das 
Okay...Thanks.


From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at 
[t...@theochem.tuwien.ac.at]
Sent: Thursday, June 28, 2012 11:36 AM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Problem in LDA+U calculation

Ok. There was another problem with your case.struct: the RMT of
some atoms were too small, leading to core leakage (during init_lapw).
Also, with LDA+U it is better to use large RMT because U is applied only
inside the sphere.

On Thu, 28 Jun 2012, Hena Das wrote:

> Thank you for the solution, it is working now.
>
> 
> From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
> zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at [tran 
> at theochem.tuwien.ac.at]
> Sent: Wednesday, June 27, 2012 1:54 PM
> To: A Mailing list for WIEN2k users
> Subject: Re: [Wien] Problem in LDA+U calculation
>
> I have the same problem and the error message in case.outputorbup is
> "Conflict in atom orb. number: lorb   3 ne ll   2".
> The reason is that in case.dmatup(dn), the blocks for a given atom are
> ordered in increasing value of l (even if they are not ordered in case.indmc),
> while orb thinks that the order is like in case.inorb.
> I solved the problem by ordering the values of l in case.inorb (don't
> forget to also order the values of U and J accordingly):
>   1 2 2 3
>   2 2 2 3
>   3 1 2
> Then it runs.
>
> Another unrelated problem: during init_lapw, lstart complains about the
> values of R0 in case.struct. You have to regenerate case.struct, such that
> the values of R0 (they are set automatically) are ok. The values of R0
> should never be set manually.
>
>
> On Wed, 27 Jun 2012, Hena Das wrote:
>
> > @Robert: Yes I used Wien2k orb executables.
> > @Tran: I followed your suggestion and tried to do the same in Wien2k. The 
> > same error appeared even in Wien2k.
> > I tried both options :   1 2 3 2
> > 2 2 3 2
> >&
> > 1 2 2 3
> > 2 2 2 3
> > Below are the case.indmc and case.inorb files that I have used:
> > case.indmc
> > -9.  Emin cutoff energy
> >  3   number of atoms for which density matrix is 
> > calculated
> >  1  2  3  2   index of 1st atom, number of L's, L1
> >  2  2  3  2   dtto for 2nd atom, repeat NATOM times
> >  3  1  2  dtto for 2nd atom, repeat NATOM times
> >  0 0   r-index, (l,s)index
> > case.inorb
> >   1  3  0 nmod, natorb, ipr
> > PRATT  1.0BROYD/PRATT, mixing
> >   1 2 3 2
> >   2 2 3 2
> >   3 1 2  iatom nlorb, lorb
> >   1  nsic 0..AMF, 1..SIC, 2..HFM
> >0.53 0.07
> >0.43 0.07U J (Ry)
> >0.53 0.07
> >0.43 0.07
> >0.43 0.07
> >
> > I hope I am not using any wrong input. Can you please check.
> >
> > Hena
> >
> > 
> > From: wien-bounces at zeus.theochem.tuwien.ac.at [wien-bounces at 
> > zeus.theochem.tuwien.ac.at] on behalf of tran at theochem.tuwien.ac.at 
> > [tran at theochem.tuwien.ac.at]
> > Sent: Wednesday, June 27, 2012 3:22 AM
> > To: wien at zeus.theochem.tuwien.ac.at
> > Subject: Re: [Wien] Problem in LDA+U calculation
> >
> > Dear Hena,
> >
> > Actually, it should work with WIEN2k (I don't know with Wienncm).
> > I have tried myself on NiO with
> > l=1 and 2 on nickel and l=1 on oxygen and it's running properly.
> > The first thing you should do is to try with WIEN2k and
> > see if it works or not. If it works with WIEN2k, but not with
> > Wienncm, it could be that also a c-shell script of Wienncm has to be
> > modified.
> >
> > But just in case, you can also try this:
> >
> > replace
> >
> >   1 2 3 2
> >   2 2 3 2
> >
> > by
> >
> >   1 2 2 3
> >   2 2 2 3
> >
> > in case.indmc and case.inorb
> >
> > F. Tran
> >
> > On 25.06.2012 17:45, Hena Das wrote:
> >
> > >I am doing a scf calculation for a particular non-collinear spin
> > >configuration. A am using LDA+U method. When I use the following
> > >case.inorb and case.indmc files:
> > >case.inorb
> > > 1  3  0 nmod, natorb, ipr
> > >PRATT  1.0BROYD/PRATT, mixing
> > >  1 1 3
> > >  2 1 3
> > >  3 1 2
> > >  1  nsic 0..AMF, 1..SIC, 2..HFM
> > >   0.65 0.07U J (Ry)
> > >   0.65 0.07
> > >   0.45 0.07
> > >case.indmc
> > >-9.  Emin cutoff energy
> > > 3   number of atoms for which density matrix is
> > >calculated
> > > 1  1  3  index of 1st atom, number of L's, L1
> > > 2  1  3  dtto for 2nd atom, repeat NATOM times
> > > 3  1  2  index of 1st atom, number of L's, L1
> > > 0 0   r-index, (l,s)index
> > >

[Wien] optics calculation with spin orbit coupling

2012-06-28 Thread soumyajyoti haldar 
Dear Wien2k users and Prof. Blaha

I am trying to calculate magneto-optical properties of some 3d transition
metal.
For this purpose we need to do spin orbit coupling calculation first. For
normal optics calculation with spin-polarization option we need to do
addjoint_lapw to join case.outputjoint(up/dn) and form case.joint file.
Then we proceed with "x kram"
My confusion is do we need to do addjoint_lapw also for spin polarized
spin-orbit coupling case since the spins are not independent any more.

any clarification will be very helpful.

Thanks and regards

-- 
Soumyajyoti Haldar, PhD Student

Department of Physics and Astronomy, Materials Theory
?ngstr?m Laboratory, Office ?13235 | Uppsala University
Box 516, SE-75120, Uppsala, SWEDEN

Phone: (+46) 18 471 5860
Mobile: (+46) 070 0399 394
http://www.physics.uu.se/en/page/soumyajyoti-haldar
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/e40dfe9d/attachment.htm>

[Wien] Problem with wien2k 11

2012-06-28 Thread Peter Blaha 
You have to read the mailing list and search it for such problems.
It was addressed several time recently:

Most likely (unless you do something else wrong) it is the version of ifort.
As far as we know, the last stable release is: composerxe-2011.3.174

More recent versions are all more or less wrong when using the mkl.

Am 28.06.2012 16:42, schrieb Jameson Maibam:
> Dear Prof. Blaha,
> I have installed wien2k11 in my dell core2duo laptop with composer xe 11
> update 9 (l_fcompxe_intel64_2011.11.339_1).I can sucessfully run TiC,
> VC, ScC and similar compounds in fcc structure. But when I tried to
> calculate ZrO2 in monoclinic structure I got the following error:
> ZrO2 problem
> Calculating ZrO2 in /home/james/ZrO2
> on localhost.localdomain with PID 8700
> using WIEN2k_11.1 (Release 14/6/2011) in /home/james/wien2k
> start (Thu Jun 28 14:24:27 IST 2012) with lapw0 (40/99 to go)
> cycle 1 (Thu Jun 28 14:24:27 IST 2012) (40/99 to go)
>>   lapw0   (14:24:27) 5.979u 0.380s 0:06.37 99.6%  0+0k 0+6320io 0pf+0w
>>   lapw1   (14:24:34) Abort (core dumped)
> 2.369u 0.289s 0:03.73 70.7% 0+0k 1688+5168io 9pf+0w
> error: command /home/james/wien2k/lapw1 lapw1.def failed
>>   stop error
> In another case I installed wien2k11 in my hp corei3 with composer xe
> 11.9.2011. In this case even TiC is unable to run. The following message
> came:
> LAPW0 END
> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>  > stop error
> Please help me to get me out of these problems.
> Yours sincerely
> Jameson Maibam
>
>
> ___
> 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
+43-1-5880115671

[Wien] Runtime Error

2012-06-28 Thread Peter Blaha 
What I just ansfered in a different thread also holds for your problem.

Am 28.06.2012 10:46, schrieb Debojyoti Mukherjee:
> Dear Wien2k Users,
>
> I am using Ubuntu operating system with Intel Fortran compiler to
> compile wien2k. The compilation showed no error; but at the time of
> running the code I am finding the following error:
>
>
>
> hup: Command not found.
>   LAPW0 END
> *** glibc detected *** /home/debojyoti/Software/wien2k/lapw1:
> munmap_chunk(): invalid pointer: 0x09709f88 ***
> === Backtrace: =
> /lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x40de4e42]
> /lib/i386-linux-gnu/libc.so.6(+0x74525)[0x40de5525]
> /home/debojyoti/Software/wien2k/lapw1[0x80d04f2]
> /home/debojyoti/Software/wien2k/lapw1[0x8082d54]
> /home/debojyoti/Software/wien2k/lapw1[0x80939a5]
> /home/debojyoti/Software/wien2k/lapw1[0x807ca21]
> /home/debojyoti/Software/wien2k/lapw1[0x804b0c4]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x40d8a4d3]
> === Memory map: 
> 08048000-08193000 r-xp  08:06 7744711
> /home/debojyoti/Software/wien2k/lapw1
> 08193000-0819b000 rw-p 0014a000 08:06 7744711
> /home/debojyoti/Software/wien2k/lapw1
> 0819b000-0840b000 rw-p  00:00 0
> 094de000-097a rw-p  00:00 0  [heap]
> 4000-4002 r-xp  08:06 7078795
> /lib/i386-linux-gnu/ld-2.15.so 
> 4002-40021000 r--p 0001f000 08:06 7078795
> /lib/i386-linux-gnu/ld-2.15.so 
> 40021000-40022000 rw-p 0002 08:06 7078795
> /lib/i386-linux-gnu/ld-2.15.so 
> 40022000-40023000 r-xp  00:00 0  [vdso]
> 40023000-40025000 rw-p  00:00 0
> 40025000-40371000 r-xp  08:06 7350966
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so
> 40371000-40378000 rw-p 0034b000 08:06 7350966
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_intel.so
> 40378000-4037d000 rw-p  00:00 0
> 4037d000-40529000 r-xp  08:06 7351033
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so
> 40529000-4052d000 rw-p 001ac000 08:06 7351033
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_sequential.so
> 4052d000-40cff000 r-xp  08:06 7348996
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so
> 40cff000-40d08000 rw-p 007d2000 08:06 7348996
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_core.so
> 40d08000-40d13000 rw-p  00:00 0
> 40d24000-40d4e000 r-xp  08:06 7078847
> /lib/i386-linux-gnu/libm-2.15.so 
> 40d4e000-40d4f000 r--p 00029000 08:06 7078847
> /lib/i386-linux-gnu/libm-2.15.so 
> 40d4f000-40d5 rw-p 0002a000 08:06 7078847
> /lib/i386-linux-gnu/libm-2.15.so 
> 40d5-40d67000 r-xp  08:06 7078895
> /lib/i386-linux-gnu/libpthread-2.15.so 
> 40d67000-40d68000 r--p 00016000 08:06 7078895
> /lib/i386-linux-gnu/libpthread-2.15.so 
> 40d68000-40d69000 rw-p 00017000 08:06 7078895
> /lib/i386-linux-gnu/libpthread-2.15.so 
> 40d69000-40d6b000 rw-p  00:00 0
> 40d6b000-40d6e000 r-xp  08:06 7078828
> /lib/i386-linux-gnu/libdl-2.15.so 
> 40d6e000-40d6f000 r--p 2000 08:06 7078828
> /lib/i386-linux-gnu/libdl-2.15.so 
> 40d6f000-40d7 rw-p 3000 08:06 7078828
> /lib/i386-linux-gnu/libdl-2.15.so 
> 40d7-40d71000 rw-p  00:00 0
> 40d71000-40f1 r-xp  08:06 7078815
> /lib/i386-linux-gnu/libc-2.15.so 
> 40f1-40f12000 r--p 0019f000 08:06 7078815
> /lib/i386-linux-gnu/libc-2.15.so 
> 40f12000-40f13000 rw-p 001a1000 08:06 7078815
> /lib/i386-linux-gnu/libc-2.15.so 
> 40f13000-40f16000 rw-p  00:00 0
> 40f16000-40f32000 r-xp  08:06 7078836
> /lib/i386-linux-gnu/libgcc_s.so.1
> 40f32000-40f33000 r--p 0001b000 08:06 7078836
> /lib/i386-linux-gnu/libgcc_s.so.1
> 40f33000-40f34000 rw-p 0001c000 08:06 7078836
> /lib/i386-linux-gnu/libgcc_s.so.1
> 40f34000-40f35000 rw-p  00:00 0
> 40f35000-416ac000 r-xp  08:06 7351127
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so
> 416ac000-416bc000 rw-p 00777000 08:06 7351127
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_vml_p4m3.so
> 416bc000-416bd000 rw-p  00:00 0
> 417a6000-4188f000 rw-p  00:00 0
> 41df3000-433d9000 r-xp  08:06 7350997
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so
> 433d9000-43447000 rw-p 015e6000 08:06 7350997
> /opt/intel/composer_xe_2011_sp1.10.319/mkl/lib/ia32/libmkl_p4m3.so
> 43447000-43449000 rw-p  00:00 0
> bfd11000-bfd34000 rw-p  00:00 0  [stack]
>
>  >   stop error
>
> Can anybody tell me where is the error and how to get rid of this problem?
>
> Thanks in advenced.
>
>
> --Debojyoti Mukher

[Wien] optics calculation with spin orbit coupling

2012-06-28 Thread Peter Blaha 
No, you don't need addjoint.

Am 28.06.2012 19:27, schrieb soumyajyoti haldar:
> Dear Wien2k users and Prof. Blaha
>
> I am trying to calculate magneto-optical properties of some 3d
> transition metal.
> For this purpose we need to do spin orbit coupling calculation first.
> For normal optics calculation with spin-polarization option we need to
> do addjoint_lapw to join case.outputjoint(up/dn) and form case.joint
> file. Then we proceed with "x kram"
> My confusion is do we need to do addjoint_lapw also for spin polarized
> spin-orbit coupling case since the spins are not independent any more.
>
> any clarification will be very helpful.
>
> Thanks and regards
>
> --
> Soumyajyoti Haldar, PhD Student
>
> Department of Physics and Astronomy, Materials Theory
> ?ngstr?m Laboratory, Office ?13235 | Uppsala University
> Box 516, SE-75120, Uppsala, SWEDEN
>
> Phone: (+46) 18 471 5860
> Mobile: (+46) 070 0399 394
> http://www.physics.uu.se/en/page/soumyajyoti-haldar
>
>
> ___
> 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
+43-1-5880115671

[Wien] Fw: Is there any relationship between DOS(E_F) and conductivity?

2012-06-28 Thread saeid pourmasoud 
Hello Dr. Validimir Timoshevskiiand Dr. Gerhard H. Fecher
I do really thank you for your nice answers.

best regards,
Saeid


- Forwarded Message -
From: Vladimir Timochevski 
To: A Mailing list for WIEN2k users  
Sent: Thursday, June 28, 2012 7:34 PM
Subject: Re: [Wien] Is there any relationship between DOS(E_F) and conductivity?
 
Hello S. Pourmasoud,

To calculate conductivity (in a "bandstructure" approach), you also need to 
know how many electronic states have non-zero momentum in your transport 
direction (in simple words ...). In other words, you need to calculate the 
Fermi surface projection on the plane, normal to your transport direction. 
Therefore, as Gerhard noticed, conductance also depends on details of 
electronic structure - Fermi surface topology. You can check this ref on how to 
use this approach to calculate transport properties:
Phys. Rev. B 57, 8907 (1998).

Vladimir.

===
Dr. Vladimir Timoshevskii (Timochevski)
Department of Physics, McGill University,
3600 rue University, Montreal, QC
Canada H3A 2T8
Tel: +1 (514) 396-8935
Fax: +1 (514) 398-8434
===




On 06/28/12 05:04, Fecher, Gerhard wrote:
> Fast answer:
>
 compare Fe and Cu and you have it.
> 
> The conductivity depends not only on the DOS at Ef but also on the setails of 
> the bandstructure.
> There is no way to compare whether Sodium, Copper, or Gold are more metallic 
> or not.
> 
> 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]" im Auftrag von"saeid pourmasoud 
> [sa_pourmasoud2007 at yahoo.com]
> Gesendet: Donnerstag, 28. Juni 2012 06:45
> An: wien at zeus.theochem.tuwien.ac.at
> Betreff: [Wien] Is there any relationship between DOS(E_F) and conductivity?
> 
> Dear All,
> We are working on two different metallic compounds. I have calculated
> total DOS at Fermi level, DOS(E_F), for these two compounds. Our
> result shows that the DOS(E_F) of the first compound is larger than
> the? DOS(E_F) of the second compound. Can I conclude from this
> observation that the first compound is more metallic than the second
> compound? Can we compare conductivity of these two compounds using
> their total DOS values at Fermi levels? Can you cite a reference in
> this respect?
> Best regards,
>
 S. Pourmasoud
> ___
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien


-- 

___
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/20120628/2d2916bd/attachment-0001.htm>

[Wien] (no subject)

2012-06-28 Thread Abdelouahab Riyah 
http://www.stanekstanek.pl/tkpofh.html
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20120628/86a00038/attachment.htm>

[Wien] spin and orbital moments

2012-06-28 Thread Gavin Abo 
1) In which coordinate system are SPI005 and ORB005 given?

In Appendix C (http://www.wien2k.at/reg_user/textbooks/) of "New notes 
about Hyperfinefield calculations (ps)", it mentions that the subroutine 
/couplx/ (of lapwdm) now calculates matrices of all components of spin 
and orbital momentum in the "crystal coordinate system 
(sx,sy,sz,lx,ly,lz)". Therefore, *I believe the x, y, and z values of 
SPIxxx and ORBxxx are also in the crystal coordinate system (CCS), while 
the M values ("PROJECTION ON M" values) are parallel to the 
magnetization. *

If your good with reading fortan, you can look into the code. I don't 
full understand what is going on in the code, but I believe the 
"direction to M" (in your case: 1 1 -1) specified in case.inso is read 
in SRC_lapwdm/lapwdm.f. Then, the angles theta and phi between the 
"direction to M" and CCS are calculated in SRC_lapwdm/angle.f. Next, the 
x, y, and z values of SPIxxx and ORBxxx are calculated in the CCS. The 
x, y, and z values are written to case.outputdm(up/dn) and 
case.scfdm(up/dn), while a Cartesian to spherical equation [r = 
sin(theta)*(cos(phi)*x+sin(phi)y)+cos(theta)*z] is used to calculate the 
radius (M) using the x, y, and z, theta, and phi values before writing 
to the same output files as performed by SRC_lapwdm/output.f.

2) Why for the first iteration MMI005 is not even roughly equal to 
SPI005 + ORB005?

SPIxxx is the spin moment calculated from selected electrons only 
(usually d or f).

MMIxxx is the sum from all electrons (s, p, d and f states) inside the 
atomic sphere xxx.

ORBxxx is the orbital magnetic moment.

So*MMIxxx = SPIxxx + ORBxxx is not necessarily true.*

See the reference links below for more information:

http://zeus.theochem.tuwien.ac.at/pipermail/wien/2011-September/015296.html
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2008-April/010820.html
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2005-January/004399.html

On 6/28/2012 9:18 AM, Kateryna Foyevtsova wrote:
> Dear Wien2k developers,
>
> I use wien2k version 11.1 to run spin-polarized GGA+U calculations with
> SO coupling for a molibdenum oxide.
> The symmetry of the system is the following
>
> bleblebles-o calc. M||  1.00  1.00 -1.00
> P   15 2 P-
>   RELA
>   13.669712 13.669712 13.669712 60.00 60.00 60.00
>
> As you see, I set magnetization axis to 1 1 -1, which should be in terms
> of (non-orthogonal) lattice vectors.
> With the help of xcrysden and case.outsymso, I can deduce that this
> direction corresponds to the 0.577350, 0.816497, 0 direction in terms of
> the cartesian global coordinate system.
>
> When I converge the electron density with (without using any previously
> converged non-relativistic calculation)
>
> runsp_lapw -p -orb -so -dm
>
> I get the following data for the first and the last iteration on one of
> the Mo atoms:
>
> 1. iteration:
> :SPI005:  SPIN MOMENT:   0.46560   0.80642  -0.53749 PROJECTION ON M
> 1.07518
> :ORB005:  ORBITAL MOMENT: -0.08361 -0.01872  0.02851 PROJECTION ON M
> -0.06454
> :MMI005: MAGNETIC MOMENT IN SPHERE   5=1.86180
>
> last iteration (converged solution):
> :SPI005:  SPIN MOMENT:   0.61653   1.06239  -0.70860 PROJECTION ON M
> 1.41804
> :ORB005:  ORBITAL MOMENT: -0.08361 -0.01872  0.02851 PROJECTION ON M
> -0.06454
> :MMI005: MAGNETIC MOMENT IN SPHERE   5=1.43149
>
> Now, I am struggling to understand two things:
> 1) In which coordinate system are SPI005 and ORB005 given?
> If they were given in the global cartesian coordinate system, they would
> be parallel to 0.577350, 0.816497, 0, but they are not.
>
> 2) Why for the first iteration MMI005 is not even roughly equal to
> SPI005 + ORB005?
>
> Thank you very much!
> Kateryna Foyevtsova
>
> P.S. When I perform relativistic calculations starting with a
> preconverged electron density of the non-relativistic solution I get the
> same final result.
> ___
> 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/20120628/8766850e/attachment.htm>