Hi,
I'm running calculations using SQS structures, and usually need some "strange"
rprim vectors. During my experiments I discovered an obvious bug in abinit
concerning the calculation of the translation vectors. Here is an example.
The following is a part of the input file:
#Definition of the unit cell
acell 16.00 24.00 16.00
rprim 0.5 0.0 0.5
0.5 0.0 -0.5
0.0 1.0 0.0
And here is its transformation to translation vectors in the output file:
.Version 6.8.2 of ABINIT
== DATASET 1 ==================================================================
Real(R)+Recip(G) space primitive vectors, cartesian coordinates (Bohr,Bohr^-1):
R(1)= 8.0000000 0.0000000 8.0000000 G(1)= 0.0625000 0.0000000 0.0625000
R(2)= 12.0000000 0.0000000-12.0000000 G(2)= 0.0416667 0.0000000 -0.0416667
R(3)= 0.0000000 16.0000000 0.0000000 G(3)= 0.0000000 0.0625000 0.0000000
It is seen that R(2) and R(3) are obviously wrong: they should be (8.0,0.0,-8.0)
and (0.0,24.0,0.0). They result in wrong interatomic distances in the supercell and
incorrect results.
The erroreous behavior in the above example can be corrected by simultaneous changing
of the second and third columns in acell, rprim, and xcart matrices, but for other
rprims this trick doesn't work. Here is an example of such a situation:
#Definition of the unit cell
acell 16.00 48.00 16.00
rprim 0.5 0.5 0.0
0.5 -0.5 0.0
0.0 0.5 -0.5
== DATASET 1 ==================================================================
Real(R)+Recip(G) space primitive vectors, cartesian coordinates (Bohr,Bohr^-1):
R(1)= 8.0000000 8.0000000 0.0000000 G(1)= 0.0625000 0.0625000 0.0625000
R(2)= 24.0000000-24.0000000 0.0000000 G(2)= 0.0208333 -0.0208333 -0.0208333
R(3)= 0.0000000 8.0000000 -8.0000000 G(3)= 0.0000000 0.0000000 -0.1250000
The same problem is observed for 6.2.3 version.
A patch to the source files is urgently needed as many users of abinit can suffer
from this problem.
Regards,
- Alexander
a bug in rprim->translation vectors transformation
Moderator: bguster
Re: a bug in rprim->translation vectors transformation
I think what you are reporting is not a bug, it's the right answer in terms of the way rprim and acell and defined and the fact that fortran reads and writes in column-first format rather than row-first format. So for example rprim as input is given by column 1, then column 2, then column 3, and and output you are reading is written in the same way.
Josef W. Zwanziger
Professor, Department of Chemistry
Canada Research Chair in NMR Studies of Materials
Dalhousie University
Halifax, NS B3H 4J3 Canada
jzwanzig@gmail.com
Professor, Department of Chemistry
Canada Research Chair in NMR Studies of Materials
Dalhousie University
Halifax, NS B3H 4J3 Canada
jzwanzig@gmail.com
Re: a bug in rprim->translation vectors transformation
Hi Josef,
Thank you for your explanation, it looks reasonable and I succeeded to make my first example runnung
without errors. But I don't understand how to construct the rprim matrix for the second example (SQS
structures may need even more complex rprims).
My crystal has a primitive orthorhombic phase with a=16.4, b=48.0, c=16.0 Bohr (basically it stems
from the thallium iodide structure). For SQS structure I'm constructing I need the translation vectors of
R(1)=(8.2,24.0,0.0), R(2)=(8.2,-24.0,0.0), and R(3)=(0.0,24.0,-8.0) (in cartesian coordinates). (The structure
is not a face-centered orthorhombic.) To my shame, I can't imagine how to include +b/2=24 and -b/2=-24
shifts to all three vectors.
Can you explain how to do it?
Thank you in advance,
- Alexander
Thank you for your explanation, it looks reasonable and I succeeded to make my first example runnung
without errors. But I don't understand how to construct the rprim matrix for the second example (SQS
structures may need even more complex rprims).
My crystal has a primitive orthorhombic phase with a=16.4, b=48.0, c=16.0 Bohr (basically it stems
from the thallium iodide structure). For SQS structure I'm constructing I need the translation vectors of
R(1)=(8.2,24.0,0.0), R(2)=(8.2,-24.0,0.0), and R(3)=(0.0,24.0,-8.0) (in cartesian coordinates). (The structure
is not a face-centered orthorhombic.) To my shame, I can't imagine how to include +b/2=24 and -b/2=-24
shifts to all three vectors.
Can you explain how to do it?
Thank you in advance,
- Alexander
Re: a bug in rprim->translation vectors transformation
Hi,
I hope I found the solution of my problem. Please correct me if I'm wrong.
I applied the following short patch to src/42_geometry/mkrdim.F90 file:
--- mkrdim.F90.orig 2010-09-04 19:14:29.000000000 +0400
+++ mkrdim.F90 2011-12-13 23:30:16.000000000 +0400
@@ -58,7 +58,7 @@
do ii=1,3
do jj=1,3
- rprimd(ii,jj)=rprim(ii,jj)*acell(jj)
+ rprimd(ii,jj)=rprim(ii,jj)*acell(ii)
end do
end do
and after this all became reasonable:
1) rprim matrix now can be written in its natural form (without taking into account the order of
elements of 2D arrays in memory),
2) the change of columns in rprim doesn't influence the result,
3) all the atoms in different SQS (special quasirandom structures) constructed with different
rprims now are sitting on their proper positions and display correct interatomic distances, which
coincide with those calculated for the original structure.
Testing of the corrected abinit file found 21 failures in v1..v6 suite (about 600 tests): the failures
should be analyzed carefully, many of them appear for low-symmetry structures in which rprim
matrix is especially complex and can be affected by the change in sources.
Regards,
- Alexander
I hope I found the solution of my problem. Please correct me if I'm wrong.
I applied the following short patch to src/42_geometry/mkrdim.F90 file:
--- mkrdim.F90.orig 2010-09-04 19:14:29.000000000 +0400
+++ mkrdim.F90 2011-12-13 23:30:16.000000000 +0400
@@ -58,7 +58,7 @@
do ii=1,3
do jj=1,3
- rprimd(ii,jj)=rprim(ii,jj)*acell(jj)
+ rprimd(ii,jj)=rprim(ii,jj)*acell(ii)
end do
end do
and after this all became reasonable:
1) rprim matrix now can be written in its natural form (without taking into account the order of
elements of 2D arrays in memory),
2) the change of columns in rprim doesn't influence the result,
3) all the atoms in different SQS (special quasirandom structures) constructed with different
rprims now are sitting on their proper positions and display correct interatomic distances, which
coincide with those calculated for the original structure.
Testing of the corrected abinit file found 21 failures in v1..v6 suite (about 600 tests): the failures
should be analyzed carefully, many of them appear for low-symmetry structures in which rprim
matrix is especially complex and can be affected by the change in sources.
Regards,
- Alexander
Re: a bug in rprim->translation vectors transformation
NO - this patch may do what you want in this specific case, but it is not the way rprim works in abinit.
As Joe pointed out, the acell are the lengths by which the 3 vectors in rprim are multiplied _NOT_ the x y z cartesian scaling factors (the latter is interesting ONLY in the cubic or orthorhombic case, no trigonal, monoclinic, hexagonal etc... very limited).
If you have the primitive translations, just put them as rprim, I can't see what is complicated here:
acell 1 1 1
rprim
8.2 24.0 0.0
8.2 -24.0 0.0
0.0 24.0 -8.0
As Joe pointed out, the acell are the lengths by which the 3 vectors in rprim are multiplied _NOT_ the x y z cartesian scaling factors (the latter is interesting ONLY in the cubic or orthorhombic case, no trigonal, monoclinic, hexagonal etc... very limited).
If you have the primitive translations, just put them as rprim, I can't see what is complicated here:
acell 1 1 1
rprim
8.2 24.0 0.0
8.2 -24.0 0.0
0.0 24.0 -8.0
Matthieu Verstraete
University of Liege, Belgium
University of Liege, Belgium