Transformations between equivalent correlated sites

[EthanMakaresz]

Hi,

I want to perform a calculation on Mn3Sn, which has a kagome structure with 120 degree magnetic order originating from the Mn d-orbitals, as in the attached image. I'm using VASP for the DFT and cthyb for the DMFT.

My plan for the calculation is to perform non-magnetic DFT and do DMFT on only one of the Mn sites, then rotate the impurity self-energy to obtain the self-energy for the other Mn sites. The rotation should be a tensor product of an orbital rotation, coming from the point group symmetry operations relating the sites, and a spin rotation, to get the correct magnetic moment orientation. The spin part is simple, but I'm not sure how dft_tools handles the orbital rotation. Are these automatically handled with sumk.put_Sigma()? The rotation matrices I see when I load the h5 file using sumk are all the identity, and I can't find anywhere else in the code that applies a rotation to the impurity self-energy. Are the orbital rotations absorbed into the projector matrices, so that only the spin rotation has to be handled manually?

[the-hampel]

Hi @EthanMakaresz ,

When using VASP the rotation matrices in the hdf5 archive (dft_input/rot_mat) are generated from what you specify as TRANSFORM or using TRANSFILE in the plo.cfg file. Unfortunately the VASP interface has no way to do this automatically, so you have to do something like TRANSFILE = t2g.dat and then t2g.dat looks like:

# site 0
0.0 -0.70710678118 0.0 0.70710678118 0.0
0.0 0.70710678118 0.0 0.70710678118 0.0
0.0 0.0 0.0 0.0 1.0

# site 1
0.0 -0.70710678118 0.0 0.70710678118 0.0
0.0 0.70710678118 0.0 0.70710678118 0.0
0.0 0.0 0.0 0.0 -1.0

# site 2
0.0 -0.70710678118 0.0 0.70710678118 0.0
0.0 0.70710678118 0.0 0.70710678118 0.0
0.0 0.0 0.0 0.0 1.0

# site 3
0.0 -0.70710678118 0.0 0.70710678118 0.0
0.0 0.70710678118 0.0 0.70710678118 0.0
0.0 0.0 0.0 0.0 -1.0

this is an example for getting a t2g model for SrMoO3 (Imma unit cell, i.e. rotating by 45 deg).

This is also important to make the sites truly equivalent. Take note of the output of the converter if the reported local Hamiltonian are the same for each side (the rotations are applied there).

Quick site note, if you use the vasp/w90 interface the converter will determine the rotation matrices for you by making hloc diagonal and then finding for each site a rotation to the first site. Cleanest approach in my view here.

Now to the 2nd part of your question: the spin rotation alignment. Currently a spin alignment not along the chosen magnetization axis (arbitrary without SOC) would be manifested by off-diagonal terms in the self-energy which is not good. Or even worse terms between up-down. There is currently not to my knowledge something implemented to do this. However, what you can do is what is done in solid_dmft: just update the sumk.rot_mat entries for each side with your rotation of choice. You can just chain two or how many rotations you like in one matrix as long as they are unitary. That is what I would suggest here. But this has not been implemented yet automatically.

sumk.put_Sigma() will apply rot_mat automatically (https://triqs.github.io/dft_tools/unstable/_modules/triqs_dft_tools/sumk_dft.html#SumkDFT.put_Sigma):

        # rotation from local to global coordinate system:
        for icrsh in range(self.n_corr_shells):
            for bname, gf in self.Sigma_imp[icrsh]:
                if self.use_rotations:
                    gf << self.rotloc(icrsh,
                                      Sigma_imp[icrsh][bname],
                                      direction='toGlobal')
                else:
                    gf << Sigma_imp[icrsh][bname]

but only that one. Since one can chain these unitary transformations I would also like to keep it that way to not add overhead by more matrix multiplications.

Best,
Alex

[EthanMakaresz]

Hi @the-hampel,

Thanks, that's really helpful! What is the problem with off-diagonal spin entries in the self-energy? I was planning to treat the projectors and lattice Green's functions as spin-dependent with no up and down blocks, then sum over spins to get the charge density update. Is the problem just that I will have to modify the code to make this work, or is there a physics issue I'm not aware of?

Regards,
Ethan

[the-hampel]

Hi @EthanMakaresz ,

no there is no problem per-se. It is just then getting as complicated as SOC calculations I would say. Maybe it is worth thinking about directly flagging in the converter the calculation as SOC enabled. Then it will immediately not create up+down blocks but ud blocks. However, these are then twice as large. It might just be hard for QMC based impurity solvers. But no physics problem per-se.

Best,
Alex