[Wien] resolution dependent F(HKL)s from lapw3 => now bug report
Laurence Marks
L-marks at northwestern.edu
Thu Feb 14 14:14:27 CET 2013
Thanks for the report. I believe Peter is on travel, otherwise he would
have responded.
---------------------------
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu 1-847-491-3996
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
On Feb 14, 2013 2:50 AM, "Georg Eickerling" <
georg.eickerling at physik.uni-augsburg.de> wrote:
> 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/
> =====================================================
> _______________________________________________
> 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/20130214/33c9c139/attachment.htm>
More information about the Wien
mailing list