Derive the SU(2) from the corresponding O(3) matrices under the appropriate basis, instead of using a list in the source code.

[hongyi-zhao]

I noticed that the following list is used for building the correspondence between the O(3) and SU(2):

(* Note that the matrix of C32- in BC book tab 6.1 and 6.7 are wrong. C34+ in the tab 6.1 of my BC
   book is also wrong, but the one in the pdf version is right. *)
SpinRot0=<|"E"->{{1,0},{0,1}}, "C2x"->{{0,-I},{-I,0}},
  "C2y"->{{0,-1},{1,0}}, "C2z"->{{-I,0},{0,I}},
  "C31+"->{{1+I,1-I},{-1-I,1-I}}/2, "C32+"->{{1+I,-1+I},{1+I,1-I}}/2,
  "C33+"->{{1-I,-1-I},{1-I,1+I}}/2, "C34+"->{{1-I,1+I},{-1+I,1+I}}/2,
  "C31-"->{{1-I,-1+I},{1+I,1+I}}/2, "C32-"->{{1-I,1-I},{-1-I,1+I}}/2,
  "C33-"->{{1+I,1+I},{-1+I,1-I}}/2, "C34-"->{{1+I,-1-I},{1-I,1-I}}/2,
  "C4x+"->{{1,-I},{-I,1}}/Sqrt[2], "C4y+"->{{1,1},{-1,1}}/Sqrt[2],
  "C4z+"->{{1+I,0},{0,1-I}}/Sqrt[2], "C4x-"->{{1,I},{I,1}}/Sqrt[2],
  "C4y-"->{{1,-1},{1,1}}/Sqrt[2], "C4z-"->{{1-I,0},{0,1+I}}/Sqrt[2],
  "C2a"->{{0,-1+I},{1+I,0}}/Sqrt[2], "C2b"->{{0,-1-I},{1-I,0}}/Sqrt[2],
  "C2c"->{{-I,I},{I,I}}/Sqrt[2], "C2d"->{{-I,-1},{1,I}}/Sqrt[2],
  "C2e"->{{-I,-I},{-I,I}}/Sqrt[2], "C2f"->{{I,-1},{1,-I}}/Sqrt[2],
  "C6+"->{{I+Sqrt[3],0},{0,-I+Sqrt[3]}}/2, "C3+"->{{1+I Sqrt[3],0},{0,1-I Sqrt[3]}}/2,
  "C2"->{{-I,0},{0,I}}, "C3-"->{{1-I Sqrt[3],0},{0,1+I Sqrt[3]}}/2,
  "C6-"->{{-I+Sqrt[3],0},{0,I+Sqrt[3]}}/2, "C21p"->{{0,-I},{-I,0}},
  "C22p"->{{0,I+Sqrt[3]},{I-Sqrt[3],0}}/2, "C23p"->{{0,I-Sqrt[3]},{I+Sqrt[3],0}}/2,
  "C21pp"->{{0,-1},{1,0}}, "C22pp"->{{0,-1+I Sqrt[3]},{1+I Sqrt[3],0}}/2,
  "C23pp"->{{0,-1-I Sqrt[3]},{1-I Sqrt[3],0}}/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

[goodluck1982]

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.

[hongyi-zhao]

I mean, on the basis of following the basic principles of the original book, improvement in 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:

BTW, I also noticed that the rotation matrix given by gtpack is not in the same format as the one used by BC book:

[goodluck1982]

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.

[goodluck1982]

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. 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:

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 from gtpack.

[hongyi-zhao]

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 from gtpack.

This is indeed a subtle underlying presentation problem that should be used self-consistently in a package.

[goodluck1982]

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

[hongyi-zhao]

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.

[goodluck1982]

You are right.
The following is captured from my ppt.

[hongyi-zhao]

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.

[goodluck1982]

All rotations in 3D space are just O(3), not only SO(3).

[hongyi-zhao]

Then, how to interpret the description here?:

and here:

[goodluck1982]

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.

[hongyi-zhao]

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

[hongyi-zhao]

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 from gtpack.

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.

[goodluck1982]

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!

[hongyi-zhao]

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?

[goodluck1982]

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.

[hongyi-zhao]

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.

[goodluck1982]

Although it's not good, it's inevitable and ubiquitous in scientific community. Researchers usually favor to use concepts/terminology/convention for their taste.

[hongyi-zhao]

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:

[goodluck1982]

Is strange. This is different from the result above #12 (comment)

[hongyi-zhao]

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 [email protected]
to: [email protected]

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:

1. 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

2. 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.

3. 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

[hongyi-zhao]

See the following reply given by gtpack developers:

Dear Prof Zhao,


Thanks for your question.


> 1. 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]:


I recommend using "Needs["GroupTheory`"]" instead of Get (or "<<"). To reload everything, I usually quit the Mathematica kernel. 


> 2. 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.


That's a good point! We will look into it. However, to obtain an overview of all implemented commands you can use


?GT*


> 3. I've noticed that the "SU(2)" matrix has the following two different forms.


It is important to mention that for SU(2) we obtain 4 matrices mediating three-fold rotations about the z-axis. We denote them by C3z, C3zi, DC3z, DC3zi (double group).

Please find attached a picture. Unfortunately, the GTSU2Matrix command seems to involve an overall factor of -1 which is not consistent with it's definition. I will repair this for the next version of GTPack. Thanks for spotting a bug! (e.g. a rotation about 2pi should give minus the identity matrix, which is not the case right now).


I hope these comments help. Please let me know if you have further questions.


Kind regards

Matthias Geilhufe

[goodluck1982]

I see, the above "C3z" is the same with the "C3+" in the BC book, not directly from the equation

I guess, maybe gtpack also uses the named SU(2) matrices in the BC book directly.

[goodluck1982]

What are the detailed contents of the two gauges?

[hongyi-zhao]

The related description in gtpack's book:

Related description in the book referred by gtpack:

[goodluck1982]

I have to say that it's my first time to know the Cartan gauge. What I have been using is just the Pauli gauge, because it's very natural that inversion has no impact on the axial vector spin, although I did not know its name.

[hongyi-zhao]

Other supplementary or more detailed explanations:

1. The following is from the explanation in this book:

2. Please also see some comments here and here.

[goodluck1982]

Thank you for your information!