Closed hongyi-zhao closed 2 years ago
Now that we utilize the irep data in the BC book, i.e. Tab. 5.7 and 6.13, we have to conform to the convention in the BC book. The BC book defines such spin rotation matrices and we just follow them. As for why the authors of the BC book chose such definitions, we don't know either.
However, there indeed is freedom to name the spin rotation due to the two-to-one homomorphism from SU(2) to SO(3). It's known that, if g \in SU(2) maps to R \in SO(3), then -g also maps to R. For example, the BC book defines {{0,-1},{1,0}}
as C2y
, but in principle -{{0,-1},{1,0}}
can also be defined as C2y
.
I mean, on the basis of following the basic principles of the original book, increase the efficiency, logic, readability, and maintainability of the code. Believing everything in books is worse than having no books at all, and, as you have found, there are mistakes and flaws in the original book too.
As an example, I noticed that gtpack
can display the representations corresponding to O(3) and SU(2) conveniently:
But I also noticed that the rotation matrix given by gtpack
is not in the same format as the one used by BC book:
I understand your meaning.
One of the purposes of SpaceGroupIrep
package is to facilitate learning the BC book. The results output by the package are designed to be the same with the BC book (except the typos & mistakes in the BC book). To achieve this goal, we have to adopt the definitions in the BC book.
For example, the following is the double-valued irep of SG 167 (in Tab.6.13 on page 537 of the BC book) The generators of "Z" point include {barC3+|001}. The spin rotation matrix of barC3+ is minus the one of C3+. Only we use the same definitions as in the BC book can we obtain the correct Herring's little group which isomorphic to the abstract group G_48^9 given in the Tab.5.1 of the BC book.
The O(3) matrix that gtpack gives uses the Cartesian bases, while the BC book use the basic vectors of the primitive cell as bases whose merit is that all the matrix elements are integers. And actually, if one only want to get the rotation matrix under Cartesian bases, he/she does not need any third-party package. The build-in RotationMatrix
function of mathematica is enough.
Here are two pages from the ppt of my group-theory course for reference:
Also this can be obtained by the build-in functions of mathematica:
One can see that the above matrix is different from the "C3+"
in the BC book.
But what's interesting is the "C3+"
matrix in the BC book happens to be the same with the one from gtpack
.
Why should they be in the same format?
In fact, the difference lies in the bases they used. Yes, bases appear again!
The O(3) matrix that gtpack gives uses the Cartesian bases, while the BC book use the basic vectors of the primitive cell as bases whose merit is that all the matrix elements are integers.
Later, I thought about it for a second time and also understood the difference between them. One is based on the representation of basis in Cartesian coordinate system, and the other is corresponding to "Jones' faithful representation symbols" using fractional coordinate system, as you've described here.
As for the spin rotation matrix, one can simply use the following expression [喀兴林《高等量子力学》]
Also this can be obtained by the build-in functions of mathematica:
Sorry for my weak theoretical foundation. I wonder why don't you use the following computation method based on the expression shown in [喀兴林《高等量子力学》]:
PauliMatrix /@ {1, 2, 3}
MatrixExp[-I*(1/\[HBar])*\[Phi] ({n1, n2, n3} . %)] //
ExpToTrig // MatrixForm
% /. {\[Phi] -> 2 Pi/3, n1 -> 0, n2 -> 0, n3 -> 1} // MatrixForm
Though the above calculation will give a strange result as follows, but it seems more consistent to the formula given by the book [喀兴林《高等量子力学》]:
But what's interesting is the
"C3+"
matrix in the BC book happens to be the same with the one fromgtpack
.
This is indeed a subtle underlying presentation problem that should be used self-consistently in a package.
Sorry for my weak theoretical foundation. I wonder why don't you use the following computation method based on the expression shown in [喀兴林《高等量子力学》]:
PauliMatrix /@ {1, 2, 3} MatrixExp[-I*(1/\[HBar])*\[Phi] ({n1, n2, n3} . %)] // ExpToTrig // MatrixForm % /. {\[Phi] -> 2 Pi/3, n1 -> 0, n2 -> 0, n3 -> 1} // MatrixForm
Though the above calculation will give a strange result as follows, but it seems more consistent to the formula given by the book [喀兴林《高等量子力学》]:
The answer has been given above, see here.
BTW: there is extra hbar in your calculation, because
Thank you for pointing out my logical mistake. Another view is to look at the relationship above from Lie algebra: Pauli matrices, after multiplication by i
, are so-called infinitesimal generators. These are elements of the Lie algebra su(2) of SU(2) group, and for such elements X the exponential mapping t↦exp(tX)
gives a one-parameter subgroup of the Lie group.
You are right. The following is captured from my ppt.
I noticed that in SpaceGroupIrep
, the rotation matrix is represented by a matrix corresponding to O(3)
, which means that det(O(3))=+/-1
, instead of the SO(3), which only includes the ones whose determinant is 1.
Side remark: It must be pointed out that Lie algebra is just one of the representation theories of SU(2), as explained here. In general, there are many group representation theories, just as there are many representation theories of quantum mechanics. They have their own advantages and disadvantages, so they are suitable for different fields. Researchers must choose according to their needs, and even invent new representation theories according to specific problems.
All rotations in 3D space are just O(3), not only SO(3).
The "rotation" I mentioned above is a generalized concept which contains "proper rotation" (det = 1) and "improper rotation" (det=-1). In spite of being called "rotation group", SO(3) only contains proper rotations. It is O(3) that contains both proper and improper rotations. Mirror and inversion are both improper rotations.
Here are two pages from the ppt of my group-theory course for reference:
Below are some other methods to prove the crystallographic restriction theorem:
https://mathworld.wolfram.com/CrystallographyRestriction.html https://en.wikipedia.org/wiki/Crystallographic_restriction_theorem
As for the spin rotation matrix, one can simply use the following expression [喀兴林《高等量子力学》]
Also this can be obtained by the build-in functions of mathematica: One can see that the above matrix is different from the
"C3+"
in the BC book. But what's interesting is the"C3+"
matrix in the BC book happens to be the same with the one fromgtpack
.
I calculated all the SU(2) matrix representations, using the possible permutations of Pauli matrices as generators:
myfunc[pauli_] :=
MatrixExp[-I*\[Phi] ({n1, n2, n3} . pauli)/2] /. {\[Phi] -> 2 Pi/3,
n1 -> 0, n2 -> 0, n3 -> 1} // ExpToTrig // MatrixForm
Table[{i, myfunc[PauliMatrix /@ i ]}, {i,
Permutations[{1, 2, 3}]}] // MatrixForm
As you can see, only three sets of non-repetitive SU(2) matrix representations are obtained and none of them is equivalent to the one used by SpaceGroupIrep
:
I really want to find a method to construct all the SU(2) matrix representations corresponding to the O(3) matrices used in BC book. I think that the correspondence between O(3) and SU(2) representation must have a self-contained algorithm in the same monograph/tool/package.
The best way to construct the SU(2) used the BC book is to refer to the BC book, although it cannot solve all problems.
In fact, the SU(2) matrix in the BC book uses the bases {spin-down, spin-up}, which is different from the usually used {spin-up, spin-down} as used by This point has been mentioned in my paper
A similarity transformation by the matrix {{0,1},{1,0}} can relate the two equations. This actually is a bases issue again!
The best way to construct the SU(2) used the BC book is to refer to the BC book, although it cannot solve all problems.
Do you mean the cases of improper rotations by saying "although it cannot solve all problems", as you have commented here?
Do you mean the cases of improper rotations by saying "although it cannot solve all problems", as you have commented here?
No. I mean the BC book only defines its own convention, but it dose not say much about its relation to other conventions, e.g. about the SU(2) matrix.
Anyway, though the BC book is the world-famous monograph, I think this is not a good style/habit, especially for researchers working in natural sciences.
Although it's not good, it's inevitable and ubiquitous in scientific community. Researchers usually favor to use concepts/terminology/convention for their taste.
In fact, the SU(2) matrix in the BC book uses the bases {spin-down, spin-up}, which is different from the usually used {spin-up, spin-down} as used by This point has been mentioned in my paper
A similarity transformation by the matrix {{0,1},{1,0}} can relate the two equations. This actually is a bases issue again!
I rechecked the related description in the book written by the developers of gtpack
, and found the following explanation on page 29:
As you can see, gtpack
uses the matrix −u
, i.e, -R
mentioned above, as the standard. This is consistent with the results calculated below:
Is strange. This is different from the result above https://github.com/goodluck1982/SpaceGroupIrep/issues/12#issuecomment-1031393364
I've also noticed this strange problem, as shown below:
And asked the author of gtpack
about this and some related questions. The following is the full content of my email for your reference:
Some problems when using your gtpack package.
from: Hongyi Zhao hongyi.zhao@gmail.com to: wolfram.hergert@physik.uni-halle.de
Dear Prof. Dr. Wolfram Hergert,
I'm very glad to learn and use your wonderful gtpack package. However, I also encountered some problems in use, as follows:
- gtpack can't be reloaded repeatedly, even I've wiped my variables/functions and removed all the symbols from the kernel with the following commands, as commented here [1]:
ClearAll[Evaluate[$Context<>""]]; Remove[Evaluate[$Context<>""]];
Basically, I mean, if I try to run the following command sequences:
<< GroupTheory`;
ClearAll[Evaluate[$Context <> "*"]];
Remove[Evaluate[$Context <> "*"]];
<< GroupTheory`
The following error will be triggered:
Error: The axis label x already exists! $Aborted
As we all know, when a user enters a partial string at the beginning of a command, Mathematica can prompt the user for all possible candidate commands. But I can't see this feature for all commands/functions defined in gtpack package. Considering that there are many custom commands and function names in the package, this is very inconvenient for users.
I've noticed that the "SU(2)" matrix has the following two different forms.
When running the following command:
GTSU2Matrix[2 Pi/3, {0, 0, 1}] // MatrixForm
The result is as follows:
\left( \begin{array}{cc} -\frac{1}{2}+\frac{i \sqrt{3}}{2} & 0 \ 0 & -\frac{1}{2}-\frac{i \sqrt{3}}{2} \ \end{array} \right)
When running the following command:
GTChangeRepresentation["SU(2)"] GTGetMatrix[C3z] // MatrixForm
The result is as follows:
\left( \begin{array}{cc} \frac{1}{2}+\frac{i \sqrt{3}}{2} & 0 \ 0 & \frac{1}{2}-\frac{i \sqrt{3}}{2} \ \end{array} \right)
Please refer to the attachment for details.
Any hints for these differences and questions will be highly appreciated.
[1] https://mathematica.stackexchange.com/a/884
Regards, HZ
I noticed that the following list is used for building the correspondence between the O(3) and SU(2):
Why not direct calculate/derive the SU(2) based on the group isomorphism between SU(2) and O(3)? BTW, I noticed a Mathematica package here and hope it can give some clues/hints/tips.
Regards, HZ