[Wien] Orbital polarization error
Roberto Iglesias
roberto.iglesias at psi.ch
Fri Oct 13 10:14:46 CEST 2006
Peter Blaha wrote:
> What was :DIS in the previous step. Any hints for divergence ?
In the previous spin-orbit calculation I had:
[l_iglesias at pc6096 SOC]$ grep :DIS k8000.scf
:DIS : CHARGE DISTANCE 0.6869217
:DIS : CHARGE DISTANCE 0.6592619
:DIS : CHARGE DISTANCE 0.2925013
:DIS : CHARGE DISTANCE 0.2942069
:DIS : CHARGE DISTANCE 0.2868454
:DIS : CHARGE DISTANCE 0.1023853
:DIS : CHARGE DISTANCE 0.0462499
:DIS : CHARGE DISTANCE 0.0406080
:DIS : CHARGE DISTANCE 0.0329126
:DIS : CHARGE DISTANCE 0.0103300
:DIS : CHARGE DISTANCE 0.0080825
:DIS : CHARGE DISTANCE 0.0069267
:DIS : CHARGE DISTANCE 0.0061518
:DIS : CHARGE DISTANCE 0.0015003
:DIS : CHARGE DISTANCE 0.0008944
:DIS : CHARGE DISTANCE 0.0006510
:DIS : CHARGE DISTANCE 0.0005419
:DIS : CHARGE DISTANCE 0.0003773
:DIS : CHARGE DISTANCE 0.0002431
:DIS : CHARGE DISTANCE 0.0001919
:DIS : CHARGE DISTANCE 0.0001569
:DIS : CHARGE DISTANCE 0.0001518
:DIS : CHARGE DISTANCE 0.0001345
:DIS : CHARGE DISTANCE 0.0000872
:DIS : CHARGE DISTANCE 0.0000348
:DIS : CHARGE DISTANCE 0.0000328
So it seems to be OK.
>
> Any hints for QTL-B values ?
> Check case.help* files if they contain '****'
Nothing at all regarding QTL-B or any '****' in the case.helpup/dn031 files.
>
> edit uplapw2.def and change unit 6 to 66. Then run
> lapw2c uplapw2.def
> and check the output at the terminal. How far does it come ?
Did as you said and
[l_iglesias at pc6096 k8000]$ lapw2c uplapw2.def
Running LAPW2 in single processor mode
Modus: TOT
no read error
RECPR LIST: NOFI
........................................................................................
KVEC( 296) = -5 -7 -8 13.8017 12
KVEC( 297) = -2 -6 -10 13.9014 12
SIZE INCLUDING STAR MEMBERS = 3073
time in recpr: 1.000000000000000E-002
BZ-integration with TETRA-program. icor=: 1
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image PC Routine Line Source
lapw2c 0807AB43 Unknown Unknown Unknown
lapw2c 08079F5F Unknown Unknown Unknown
lapw2c 0809CD75 Unknown Unknown Unknown
lapw2c 0804BDC5 Unknown Unknown Unknown
libc.so.6 00B1EE23 Unknown Unknown Unknown
lapw2c 0804BD01 Unknown Unknown Unknown
So the information on the bands, wave functions and charges does not appear
> Error already in FERMI, or in CLMs of X-th atom, or in Fourier ?
How should I know?
>
> Any other error message ?
No, only "Error in LAPW2" is written in the uplapw2.error file
Thank you!
Roberto
>
>
> Roberto Iglesias schrieb:
>> Hi!
>>
>> I have tried your suggestions, adding -traceback to the SRC_lapw2 Makefile. Then recompiled and used the new
>> lapw2c executable in a terminal run. And this is what I got:
>>
>> [l_iglesias at pc6096 k8000]$ x lapw0
>> LAPW0 END
>> 0.871u 0.036s 0:00.89 101.1% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x orb -up
>> ORB END
>> 0.039u 0.002s 0:00.04 75.0% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x orb -dn
>> ORB END
>> 0.041u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x lapw1 -up
>> LAPW1 END
>> 5.744u 1.112s 0:06.82 100.4% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x lapw1 -dn
>> LAPW1 END
>> 5.730u 1.138s 0:06.90 99.4% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x lapwso -up -orb
>> LAPWSO END
>> 2.555u 0.159s 0:02.74 98.5% 0+0k 0+0io 0pf+0w
>> [l_iglesias at pc6096 k8000]$ x lapw2 -c -up -so
>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>> Image PC Routine Line Source
>> lapw2c 0807AB43 Unknown Unknown Unknown
>> lapw2c 08079F5F Unknown Unknown Unknown
>> lapw2c 0809CD75 Unknown Unknown Unknown
>> lapw2c 0804BDC5 Unknown Unknown Unknown
>> libc.so.6 00B1EE23 Unknown Unknown Unknown
>> lapw2c 0804BD01 Unknown Unknown Unknown
>> 0.011u 0.003s 0:00.01 100.0% 0+0k 0+0io 0pf+0w
>> error: command /home/l_iglesias/WIEN2k/lapw2c uplapw2.def failed
>>
>>
>> So I cannot see any information on either the routines or the lines. Should I search in a different place?
>>
>> Thanks for the input!
>>
>> Roberto
>>
>>
>> Laurence Marks wrote:
>>> If you are using ifort, add -traceback to the Makefile in SRC_lapw2
>>> then recompile (make ; cp lapw2 ../). This will give you line numbers
>>> as well as routine names so it can be traced.
>>>
>>> On 10/12/06, Roberto Iglesias <roberto.iglesias at psi.ch> wrote:
>>>> Yes, there is something strange in case.output2up. The information on the bands, wave functions and charges
>>>> does not appear, the file is truncated below:
>>>>
>>>>> BZ-integration with TETRA-program. icor=: 1
>>>> The corresponding .output2dn seems to be correct, though.
>>>>
>>>> Running the last command from the terminal gives the same STDOUT as before, which I did not post. This is it:
>>>>
>>>>> LAPW0 END
>>>>> LAPW1 END
>>>>> LAPW1 END
>>>>> LAPWSO END
>>>>> LAPW2 END
>>>>> LAPW2 END
>>>>> LAPWDM END
>>>>> CORE END
>>>>> CORE END
>>>>> MIXER END
>>>>> in cycle 2 ETEST: 0 CTEST: 0
>>>>> LAPW0 END
>>>>> ORB END
>>>>> ORB END
>>>>> LAPW1 END
>>>>> LAPW1 END
>>>>> LAPWSO END
>>>>> forrtl: severe (174): SIGSEGV, segmentation fault occurred
>>>>> Image PC Routine Line Source
>>>>> lapw2c 0807AB43 Unknown Unknown Unknown
>>>>> lapw2c 08079F5F Unknown Unknown Unknown
>>>>> lapw2c 0809CD75 Unknown Unknown Unknown
>>>>> lapw2c 0804BDC5 Unknown Unknown Unknown
>>>>> libc.so.6 00B1EE23 Unknown Unknown Unknown
>>>>> lapw2c 0804BD01 Unknown Unknown Unknown
>>>> Thanks for your suggestion!
>>>>
>>>> Roberto
>>>>
>>>>
>>>>
>>>>
>>>> Laurence Marks wrote:
>>>>> It's often hard to find exactly where the errors are. Try:
>>>>> 1) Looking at the case.output2XX files
>>>>> 2) Running the last command by hand at the terminal
>>>>>
>>>>> On 10/12/06, Roberto Iglesias <roberto.iglesias at psi.ch> wrote:
>>>>>> Hello all!
>>>>>>
>>>>>> I've seen a problem exactly as mine in the mailing list, but no answers. Please, follow the link:
>>>>>>
>>>>>> http://zeus.theochem.tuwien.ac.at/pipermail/wien/2003-August/000533.html
>>>>>>
>>>>>> The only difference is that my inorb file looks like:
>>>>>>
>>>>>> 2 1 0 nmod, natorb, ipr
>>>>>> PRATT, 1.0 mixmod, amix
>>>>>> 1 1 2 iatom nlorb, lorb
>>>>>> 1 nmodop (in the original post it had 0 value)
>>>>>> 1 Ncalc
>>>>>> 1. 1. 1. direction of M
>>>>>>
>>>>>> This is my case.dayfile:
>>>>>>
>>>>>> start (Thu Oct 12 17:03:27 CEST 2006) with lapw0 (200/20 to go)
>>>>>>
>>>>>> cycle 1 (Thu Oct 12 17:03:27 CEST 2006) (200/20 to go)
>>>>>>
>>>>>> > lapw0 (17:03:27) 0.877u 0.023s 0:00.89 100.0% 0+0k 0+0io 0pf+0w
>>>>>> > lapw1 -up (17:03:28) 5.728u 0.977s 0:06.77 98.8% 0+0k 0+0io 0pf+0w
>>>>>> > lapw1 -dn (17:03:34) 5.728u 0.989s 0:06.72 99.7% 0+0k 0+0io 0pf+0w
>>>>>> > lapwso -up -orb (17:03:41) 3.806u 0.880s 0:04.70 99.5% 0+0k 0+0io 0pf+0w
>>>>>> > lapw2 -c -up -so (17:03:46) 7.481u 0.567s 0:08.08 99.5% 0+0k 0+0io 0pf+0w
>>>>>> > lapw2 -c -dn -so (17:03:54) 7.443u 0.581s 0:08.09 99.1% 0+0k 0+0io 0pf+0w
>>>>>> > lapwdm -up -so -c (17:04:02) 0.598u 0.090s 0:00.68 100.0% 0+0k 0+0io 0pf+0w
>>>>>> > lcore -up (17:04:03) 0.011u 0.019s 0:00.03 66.6% 0+0k 0+0io 0pf+0w
>>>>>> > lcore -dn (17:04:03) 0.019u 0.011s 0:00.03 66.6% 0+0k 0+0io 0pf+0w
>>>>>> > mixer (17:04:03) 0.057u 0.027s 0:00.08 87.5% 0+0k 0+0io 0pf+0w
>>>>>> :ENERGY convergence: 0 0.00001 0
>>>>>> :CHARGE convergence: 0 0.0001 0
>>>>>>
>>>>>> cycle 2 (Thu Oct 12 17:04:03 CEST 2006) (199/19 to go)
>>>>>>
>>>>>> > lapw0 (17:04:03) 0.877u 0.027s 0:00.90 98.8% 0+0k 0+0io 0pf+0w
>>>>>> > orb -up (17:04:04) 0.041u 0.001s 0:00.04 100.0% 0+0k 0+0io 0pf+0w
>>>>>> > orb -dn (17:04:04) 0.039u 0.002s 0:00.04 75.0% 0+0k 0+0io 0pf+0w
>>>>>> > lapw1 -up (17:04:04) 5.702u 1.024s 0:06.73 99.8% 0+0k 0+0io 0pf+0w
>>>>>> > lapw1 -dn (17:04:11) 5.725u 0.987s 0:06.71 99.8% 0+0k 0+0io 0pf+0w
>>>>>> > lapwso -up -orb (17:04:18) 2.542u 0.182s 0:02.72 100.0% 0+0k 0+0io 0pf+0w
>>>>>> > lapw2 -c -up -so (17:04:21) 0.010u 0.003s 0:00.01 100.0% 0+0k 0+0io 0pf+0w
>>>>>> error: command /home/l_iglesias/WIEN2k/lapw2c uplapw2.def failed
>>>>>>
>>>>>> > stop error
>>>>>>
>>>>>>
>>>>>> The comment in uplapw2.error file is just "Error in LAPW2".
>>>>>>
>>>>>>
>>>>>> I had previously performed a spin orbit calculation, with the direction of M set also as 1. 1. 1., and it
>>>>>> reached convergence without problems.
>>>>>> And also in my case, calculations along 0. 0. 1. and 1. 1. 0 run perfectly.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Roberto
>>>>>>
>>>>>> --
>>>>>> ------------------------------------------
>>>>>> Roberto Iglesias
>>>>>> High Temperature Materials Project
>>>>>> Laboratory for Materials Behaviour
>>>>>> Nuclear Energy and Safety Department
>>>>>> OHLD/013
>>>>>> PAUL SCHERRER INSTITUT
>>>>>> CH-5232 Villigen PSI
>>>>>> phone: +41 (0)56 310 54 81
>>>>>> fax: +41 (0)56 310 35 65
>>>>>> e-mail: roberto.iglesias at psi.ch
>>>>>> Internet: www.psi.ch
>>>>>> -----------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
More information about the Wien
mailing list