Open liquidnode opened 3 years ago
I think there are two things at play here:
The function_string
for the dz2
orbital shouldn't be z**2
, but something like 3*z**2 - 1
(with appropriate prefactors to normalize). That's if we represent cos(theta) as z
and take the orbital shape as defined by Wannier90 (see screenshot below). Note that you can choose the function_string
to be anything you like, but I think here it won't solve the problem because of the second point
Somehow we need to teach sympy
that x**2 + y**2 + z**2 == 1
, then it could represent x**2
as a linear combination of the others. Alternatively we could also replace x
, y
, z
with cos(theta)
, sin(theta)cos(phi)
, sin(theta)sin(phi)
- not sure which is easier for sympy
to solve in the end. In the numeric implementation it should be fairly straightforward, just pick only random vectors on the unit sphere.
I'm not sure exactly what you're proposing w.r.t. using the rotation operator - are you suggesting to represent the orbital in terms of quantum numbers, instead of as a function?
Thank you for your suggestions and the clarification of the function basis. I have quickly implemented them for my d-orbital system and _expr_to_vector seems to execute without any problems, though I have not checked if the resulting reps are correct. In detail, I first replaced the d entry in _orbital_constants.py with
'd': ['sqrt(5/(16*pi))*(3*z**2-1)',
'sqrt(15/(4*pi))* z*x',
'sqrt(15/(4*pi))* z*y',
'sqrt(15/(16*pi))* (x**2 - y**2)',
'sqrt(15/(16*pi))* 2 * x*y'
],
I also replaced vals = [(k, random_fct()) for k in VEC]
in _expr_to_vector with
theta = np.random.sample() * np.pi
phi = np.random.sample() * np.pi * 2.0
X = np.sin(theta) * np.cos(phi)
Y = np.sin(theta) * np.sin(phi)
Z = np.cos(theta)
vals = [(VEC[0], X), (VEC[1], Y), (VEC[2], Z)]
It seems that only the numeric part of _expr_to_vector is used, so I did not do any alteration to the sympy part.
Yes, I suggested to compute the orbital reps using quantum numbers, though that would be a bit unpractical, since the entire code is currently based on the function basis. Also since Wannier90 is also based on this basis, one should also always first transform into the quantum number basis before applying the rotation operator. Now I think it would be best to stay in the function basis.
It seems like get_repr_matrix can not compute the orbital-representation of some rotations, like for example the 3-fold rotation {{0,0,1},{1,0,0},{0,1,0}} of d-orbtials. I think the problem can be traced back to _expr_to_vector, where this function tries to in this example represent x^2 ( the z^2 orbital after the 3-fold rotation) as a linear combination of z^2, xz, yz, x^2 - y^2, xy, which is not possible. Although it should obviously be possible to represent the 3-fold rotation in the d-orbital basis.
One could instead implement the orbital representation using a rotation operator https://en.wikipedia.org/wiki/Rotationoperator(quantum_mechanics).