Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_repr_matrix is unable to compute the rep of some rotations #12

Open
liquidnode opened this issue Nov 6, 2020 · 2 comments
Open

Comments

@liquidnode
Copy link

liquidnode commented Nov 6, 2020

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/Rotation_operator_(quantum_mechanics).

@greschd
Copy link
Member

greschd commented Nov 6, 2020

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
    image

  • 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?

@liquidnode
Copy link
Author

liquidnode commented Nov 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants