Top Page > Browsing

Two questions about PDOS calculation of CoO. Date: 2021/12/02 13:33 Name: K.Usami Dear OpenMX developers and users, I am trying to analyze the electronic state of materials using PDOS for each magnetic quantum 'm' obtained by OpenMX. As an exercise, I ran the SCF&DOS calculations on the original 'NiO-sFLL.dat' in the 'work' directory and plotted the PDOS for the five d-orbitals of Ni.Then, I could see the double degenerate e_g orbital and the triple degenerate t_2g orbital. Next, I did the same calculation for CoO, replacing Ni with Co in 'NiO-sFLL.dat', and I have two questions about the results.If anyone knows the cause of one or both, please comment. (1) When calculated with the same settings except for the atom species and coordinates, the PDOS of d_xy and d_yz was doubly degenerate, but that of the other three orbitals was a completely non-degenerate shape. So, I raised 'Dos.kgrid' to 30:30:30 and ran the calculation again, and confirmed a reliable degenerate structure. However, I do not know why it was necessary to increase the 'Dos.kgrid' in the case of CoO. The input file is shown below, ================================================ # Definition of Atomic Species Species.Number 2 <Definition.of.Atomic.Species Co Co6.0S-s2p2d2f1 Co_CA19S O O5.0-s2p2d1 O_CA19 Definition.of.Atomic.Species> <Hubbard.U.values # eV Co 1s 0.0 2s 0.0 1p 0.0 2p 0.0 1d 7.0 2d 0.0 1f 0.0 O 1s 0.0 2s 0.0 1p 0.0 2p 0.0 1d 0.0 Hubbard.U.values> <Hund.J.values # eV Co 1s 0.0 2s 0.0 1p 0.0 2p 0.0 1d 1.0 2d 0.0 1f 0.0 O 1s 0.0 2s 0.0 1p 0.0 2p 0.0 1d 0.0 Hund.J.values> # Atoms Atoms.Number 4 Atoms.SpeciesAndCoordinates.Unit AU # Ang|AU <Atoms.SpeciesAndCoordinates 1 Co 0.000000 0.000000 0.000000 9.0 6.0 off 2 Co 3.970000 3.970000 0.000000 6.0 9.0 off 3 O 3.970000 0.000000 0.000000 3.0 3.0 off 4 O 3.970000 3.970000 3.970000 3.0 3.0 off Atoms.SpeciesAndCoordinates> Atoms.UnitVectors.Unit AU # Ang|AU <Atoms.UnitVectors 7.940000 3.970000 3.970000 3.970000 7.940000 3.970000 3.970000 3.970000 7.940000 Atoms.UnitVectors> # SCF or Electronic System scf.XcType LSDA-CA # LDA|LSDA-CA|GGA-PBE # DFT+U part # scf.Hubbard.U On # On|Off, default=off scf.Hubbard.Occupation dual # onsite|full|dual, default=dual scf.DFTU.Type 2 # 1:Simplified(Dudarev)|2:General, default=1 scf.dc.Type sFLL # sFLL|sAMF|cFLL|cAMF, default=sFLL scf.Slater.Ratio 0.625 # default=0.625 scf.Yukawa off # default=off ############## scf.SpinPolarization On # On|Off scf.ElectronicTemperature 300.0 # default=300 (K) scf.energycutoff 150.0 # default=150 (Ry) scf.maxIter 200 # default=40 scf.EigenvalueSolver band # Recursion|Cluster|Band scf.Kgrid 6 6 6 # means 4x4x4 scf.Mixing.Type rmm-diis # Simple|Rmm-Diis|Gr-Pulay scf.Init.Mixing.Weight 0.20 # default=0.30 scf.Min.Mixing.Weight 0.01 # default=0.001 scf.Max.Mixing.Weight 0.30 # default=0.40 scf.Kerker.factor 1.00 # default=1.00 scf.Mixing.History 5 # default=5 scf.Mixing.StartPulay 6 # default=6 scf.criterion 1.0e-7 # default=1.0e-6 (Hartree) # DOS and LDOS Dos.fileout on # on|off , default=off Dos.Erange -10.0 10.0 # default = -20 20 Dos.Kgrid 9 9 9 # default = Kgrid1 Kgrid2 Kgrid3 ================================================ (2) In the above input file, I replaced the unit vector and atomic configuration with the CIF information prepared from the Net as follows, and performed the same calculations. ================================================ Atoms.SpeciesAndCoordinates.Unit AU # Ang|AU <Atoms.SpeciesAndCoordinates 1 Co 0.000000 0.000000 0.000000 9.0 6.0 off 2 Co 0.000000 3.970000 3.970000 6.0 9.0 off 3 O 0.000000 3.970000 0.000000 3.0 3.0 off 4 O 3.970000 0.000000 0.000000 3.0 3.0 off Atoms.SpeciesAndCoordinates> Atoms.UnitVectors.Unit AU # Ang|AU <Atoms.UnitVectors -3.970000 7.950000 3.970000 3.970000 0.000000 3.970000 3.970000 0.000000 -3.970000 Atoms.UnitVectors> >>>> Dos.Kgrid 30 30 30 # default = Kgrid1 Kgrid2 Kgrid3 ================================================ As a result, despite the high value of 'Dos.kgrid', some d-orbitals show a completely non-degenerate shape. Is it difficult to get a reliable PDOS for each magnetic quantum number with OpenMX? Best regards, K.Usami

Page: [1]

Re: Two questions about PDOS calculation of CoO. ( No.1 ) Date: 2021/12/02 20:19 Name: K.Usami PS, Regarding question (2), I failed to take into account that the space group is different when I distinguish between two Co by the initial number of electrons and not. I apologize for the lack of consideration, and as for question (1), if you know anything about it, please let me know. Regards, K.usami Re: Two questions about PDOS calculation of CoO. ( No.2 ) Date: 2021/12/02 20:55 Name: T. Ozaki Hi, Though I didn't consider your issue thoroughly, I wonder that the degeneracy of five d-orbitals can be broken by not only crystal symmetry, but also the electron correlation in the plus U method. In case of NiO, the charge state is Ni^(2+) and O^(2-) which means that Ni^(2+) has 8 electrons. The 5 of 8 lectrons populate in the majority t2g and eg orbitals, and the remaining 3 electron populate the minory t2g orbitals, where there is no effect causing orbital ordering. On the other hand, Co^(2+) in CoO has 7 electrons, and the majority t2g and eg orbitals are occupied by the 5 of 7 electrons. The remaining 2 electrons try to populate the minory t2g orbitals, and they choose a situation that only the two t2g orbitals are occupied, and the other is empty. This is so called orbital ordering. As a result, the degeneracy of the minority t2g orbitals is broken, and the broken symmetry affects to the majority orbitals via a broken symmetry in the potential, which is a famous example about how the plus U method works. I guess that this is what you observed. Regards, TO Re: Two questions about PDOS calculation of CoO. ( No.3 ) Date: 2021/12/05 00:21 Name: K.Usami Dear T. Ozaki Thank you for the reply. I now understand how localized electron correlation causes the degenerate breakdown. I think I need to learn more about the Plus-U method. By the way, according to the theory above, the t2g orbitals should be non-degenerate, but why did the degeneracy recover when <Dos.kgrid> was raised? Regards, K. Usami

Page: [1]