[Wien] resolution dependent F(HKL)s from lapw3 => now bug report
Georg Eickerling
georg.eickerling at physik.uni-augsburg.de
Thu Feb 14 09:50:15 CET 2013
Dear WIEN2k users,
I finally want to report the bug which is responsible for the
resolution dependency of the calculated HKLs mentioned in this thread.
We have tracked down the problem to the file fourir.frc and in
particular to the lines 201 and 203 were the PW and the MT part of
the structure factors are finally added:
!_REAL STRF(K)=STRF(K)+F
!_COMPLEX STRF(K)=STRF(K)+conjg(F)
It turns out, that in some cases the order of the HKLs is not the
same for the two components, i.e. the array KZZ (used to obtain F in
the above lines) contains the HKLs in a different order than STRF(K)
assumes.
This bug only affects HKLs with the same sin theta/labmda, which
probably indicates a rounding error problem when sorting the
reflexes according to their st/l.
Example:
For st/l 1.1 the order of the reflexes in the MT AND the PW part is
5 -3 -5
3 -1 -7
so the result is correct.
In case of st/l = 1.2 this is not true: Here, the order of the HKLs
for the MT is
3 -1 -7
5 -3 -5
while in the PW part it is still
-3 -5 -5
-1 -3 -7
BUT in fourir.frc lapw3 simply adds up the reflexes in the order
they appear without checking for consistent HKLs - causing the
errors described below.
We did not track down the problem to the part were the "re-ordering"
is taking place, but we fixed it in a local version by using a new
array as intermediate storage for the "correct" order of HKLs. I do
not append this new version here as I see this more like a
workaround than a fix.
regards
Georg Eickerling
Am 23.08.2012 08:50, schrieb Georg Eickerling:
> Thank you very much for the replies!
>
> Here are some more details:
>
> Sphere part:
>
> st/l = 1.1:
> 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.00000 0.00107
> 0.00000 -0.01465
> 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.00000 -0.00030
> 0.00000 0.00410
>
> st/l = 1.2:
> 3 -1 -7 1.0767 -0.7386 -0.7411 -0.00127 0.00000 -0.00030
> 0.00000 0.00410
> 5 -3 -5 1.0767 -0.7523 -0.7411 0.00244 0.00000 0.00107
> 0.00000 -0.01465
>
> st/l = 1.3:
> -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.00000 0.00107
> 0.00000 -0.01465
> -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.00000 -0.00030
> 0.00000 0.00410
>
> st/l = 1.8
> -3 -5 -5 1.0767 -0.7523 -0.7411 0.00244 0.00000 0.00107
> 0.00000 -0.01465
> -1 -3 -7 1.0767 -0.7386 -0.7411 -0.00127 0.00000 -0.00030
> 0.00000 0.00410
>
> PW part:
>
> st/l = 1.1:
> -3 -5 -5 0.0665201058405473 1.0766653378172495
> -1 -3 -7 0.0345681054384858 1.0766653378172495
>
> st/l = 1.2:
> -3 -5 -5 0.0665201058405473 1.0766653378172495
> -1 -3 -7 0.0345681054384858 1.0766653378172495
>
> st/l = 1.3:
> -3 -5 -5 0.0665201058405473 1.0766653378172495
> -1 -3 -7 0.0345681054384858 1.0766653378172495
>
>
> stl/l = 1.8:
> -3 -5 -5 0.0665201058405473 1.0766653378172495
> -1 -3 -7 0.0345681054384858 1.0766653378172495
>
>
> But then:
>
>
> "Sum":
>
> st/l = 1.1:
> -3 -5 -5 1.0766653 -1.4379800081
> -1 -3 -7 1.0766653 -1.4425910379
>
> st/l = 1.2:
> -3 -5 -5 1.0766653 -1.4106390375
> -1 -3 -7 1.0766653 -1.4699320085
>
> st/l = 1.3:
> -3 -5 -5 1.0766653 -1.4379800081
> -1 -3 -7 1.0766653 -1.4425910379
>
> stl/l = 1.8:
> -3 -5 -5 1.0766653 -1.4379800081
> -1 -3 -7 1.0766653 -1.4425910379
>
>
>
> Second example at higher res (data in the order st/l =1.2, 1.3, 1.8):
>
> Sphere:
> 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.00000 0.00068
> 0.00000 0.00000
> 6 0 -6 1.1894 0.8887 0.8902 -0.00212 0.00000 0.00068
> 0.00000 0.00000
> 0 -6 -6 1.1894 -0.8887 -0.8902 0.00212 0.00000 -0.00068
> 0.00000 0.00000
>
> PW:
> 0 -6 -6 -0.0362599474060042 1.1893809383585805
> 0 -6 -6 -0.0362599474060042 1.1893809383585805
> 0 -6 -6 -0.0362599474060042 1.1893809383585805
>
> Sum:
> 0 -6 -6 1.1893809 1.7411783356
> 0 -6 -6 1.1893809 -1.8246688899
> 0 -6 -6 1.1893809 -1.8136982305
>
>
> This is a "default" run by the way, so I am using a GMAX of 12 which
> gives st/l = 1.8. What I see in addition in output3 is this:
>
> KVEC 0 -8 -8 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -1 -7 -9 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -2 -8 -8 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC 0 -6 -10 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -3 -7 -9 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -2 -6 -10 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -4 -8 -8 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -1 -5 -11 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -4 -6 -10 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -5 -7 -9 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -3 -5 -11 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC 0 -4 -12 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -6 -8 -8 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
> KVEC -2 -4 -12 IN DENSITY
> LIST NOT FOUND IN GENERATED K LIST
>
>
>
>
> Am 23.08.2012 07:37, schrieb Peter Blaha:
>> Thank's for the report. I'll check that.
>>
>> But in the meantime you could do some more analysis and compare the
>> case.output3 files of two different runs.
>> Are the differences coming from inside the spheres or from the
>> interstital
>> region ? (I expect the latter !)
>>
>> Am 22.08.2012 18:32, schrieb Georg Eickerling:
>>> Dear WIEN users,
>>>
>>> I noticed a strange behavior of lapw3 which I do not understand:
>>>
>>> Take for example a simple diamond case and calculate structure
>>> factors from clmsum, lets say up to sin theta/lambda = 1.0:
>>>
>>> 0 0 0 0.0000000 12.0000251726
>>> -1 -1 -1 0.2427814 -4.6536716863
>>> 0 0 -2 0.2803398 0.0000000000
>>> 0 -2 -2 0.3964603 -3.9459734623
>>> -1 -1 -3 0.4648909 -2.3988162763
>>> -2 -2 -2 0.4855627 0.2266152403
>>> 0 0 -4 0.5606796 -3.1297582248
>>> -1 -3 -3 0.6109864 2.2069300710
>>> 0 -2 -4 0.6268588 0.0000000000
>>> -2 -2 -4 0.6866894 2.8777607788
>>> -3 -3 -3 0.7283441 1.9393120414
>>> -1 -1 -5 0.7283441 1.9663566686
>>> 0 -4 -4 0.7929206 2.6458269883
>>> -1 -3 -5 0.8292562 1.8056937118
>>> -2 -4 -4 0.8410193 -0.0171687161
>>> 0 0 -6 0.8410193 0.0000000000
>>> 0 -2 -6 0.8865122 2.4363270068
>>> -3 -3 -5 0.9191554 -1.6841664183
>>> -2 -2 -6 0.9297818 -0.0087306004
>>> -4 -4 -4 0.9711255 -2.2589221048
>>>
>>> Repeating this calculation with sin theta/lambda = 1.1 and a diff
>>> with the old hkl will just show the additional reflections as
>>> expected:
>>>
>>> diff hkl.10 hkl.11
>>> 20a21,26
>>>> -1 -5 -5 1.0010132 1.6970975057
>>>> -1 -1 -7 1.0010132 1.5391902602
>>>> 0 -4 -6 1.0107794 0.0000000000
>>>> -2 -4 -6 1.0489354 -2.0944311378
>>>> -3 -5 -5 1.0766653 -1.4379800081
>>>> -1 -3 -7 1.0766653 -1.4425910379
>>>
>>> Now again repeat the calculation with sin theta/lambda = 1.2:
>>>
>>> diff hkl.11 hkl.12
>>> 25,26c25,32
>>> < -3 -5 -5 1.0766653 -1.4379800081
>>> < -1 -3 -7 1.0766653 -1.4425910379
>>> ---
>>>> -3 -5 -5 1.0766653 -1.4106390375
>>>> -1 -3 -7 1.0766653 -1.4699320085
>>>> 0 0 -8 1.1213591 1.9443586030
>>>> -3 -3 -7 1.1473400 1.3618747163
>>>> -4 -4 -6 1.1558705 0.0030399053
>>>> 0 -2 -8 1.1558705 0.0000000000
>>>> 0 -6 -6 1.1893809 1.7411783356
>>>> -2 -2 -8 1.1893809 -1.8133181764
>>>
>>> What happens here? Why are reflections which were exactly the same
>>> before suddenly different? Why I worry about this is, that if you go
>>> on increasing the resolution, the differences become more severe
>>> than in the example above, i.e. sin theta/lambda = 1.3:
>>>
>>> diff hkl.12 hkl.13
>>> 21,22c21,22
>>> < -1 -5 -5 1.0010132 1.6970975057
>>> < -1 -1 -7 1.0010132 1.5391902602
>>> ---
>>>> -1 -5 -5 1.0010132 -1.5542465484
>>>> -1 -1 -7 1.0010132 1.5480881986
>>>
>>> On the other hand, the differences "converge" for a given reflection
>>> but more and more become "affected", i.e. sin theta/lambda = 1.8
>>> vs. 1.2:
>>>
>>>
>>> diff hkl.12 hkl.18
>>> 21,22c21,22
>>> < -1 -5 -5 1.0010132 1.6970975057
>>> < -1 -1 -7 1.0010132 1.5391902602
>>> ---
>>>> -1 -5 -5 1.0010132 -1.5542465484
>>>> -1 -1 -7 1.0010132 1.5480881986
>>> 25,26c25,26
>>> < -3 -5 -5 1.0766653 -1.4106390375
>>> < -1 -3 -7 1.0766653 -1.4699320085
>>> ---
>>>> -3 -5 -5 1.0766653 -1.4379800081
>>>> -1 -3 -7 1.0766653 -1.4425910379
>>> 28c28
>>> < -3 -3 -7 1.1473400 1.3618747163
>>> ---
>>>> -3 -3 -7 1.1473400 -1.3370357923
>>> 31c31
>>> < 0 -6 -6 1.1893809 1.7411783356
>>> ---
>>>> 0 -6 -6 1.1893809 -1.8136982305
>>>
>>>
>>> Looking at the result of a refinement of a structural model against
>>> the different HKLs, the "high resolution version" seems to be
>>> "wrong" compared to the low-res one.
>>>
>>> Thank you very much in advance for any comments on this.
>>>
>>> regards
>>>
>>> Georg Eickerling
>>>
>>>
>>
>
>
--
============================
Dr. Georg Eickerling
Universitaet Augsburg
Institut fuer Physik
Lehrstuhl fuer Chemische Physik und Materialwissenschaften
Universitaetsstr. 1
86159 Augsburg
E-Mail: georg.eickerling at physik.uni-augsburg.de
Phone: +49-821-598-3362
FAX: +49-821-598-3227
WWW: http://www.physik.uni-augsburg.de/cpm/
=====================================================
More information about the Wien
mailing list