** caseGS.ham** (e.g. Ni2GS.ham) is the input file for

**, generating reduced matrix elements of the Hamiltonian for initial states. The reduced matrix elements are used for the calculation of the ground (or a few initial) states on which x-ray excitation occurs.**

*ham.GS*### What does *caseGS.ham* input file define?

*caseGS.ham*

**1. Point-group symmetry at the impurity site (if known)**

1) The point-group symmetry is used to find the block structure of the Hamiltonian

2) It determine number of independent parameters in crystal-field and impurity-bath hybridization amplitudes (functions)

**2. Configurations to be **taken into account for describing initial states

The bases are generated by the configuration-interaction scheme (Gunnarsson and Schohammer theory)

1) successive application of impurity-bath hybridization (charge-transfer from valence bands to the target ion) generates configurations with higher order of electron-hole pairs (see the bath in d^{1}L^{1}C^{1} configuration, for example) in the bath, see figure below.

2) the basis expansion starts with the configuration |d^{n}> (n-electron at the impurity site + filled bath up to Fermi energy, i.e. d^{1} configuration in the figure below)

**For the Anderson impurity model with the bath obtained with LDA+DMFT scheme**

When one wants to compute the core-level spectra on the valance states descried by LDA+DMFT, a care must be taken for the consistency in the solution of Anderson impurity model obtained by the configuration-interaction scheme here and in the DMFT self-consistent calculation. The configuration-interaction scheme has two approximations: (1) truncate configurations with higher-order electron-hole pairs (2) discretize the hybridization function of the Anderson impurity model (which describes the amplitude for exchanging electrons between the impurity site and bath). In the DMFT self-consistent calculation, one can use the continuous time Monte Carlo (CT-QMC) method which deals with the continuous hybridization function and all possible configurations. Thus, after the configuraiton-interaction calculation, it is recommended to compare the observables (e.g. reduced density matrix at the impurity site) with the ones in the CT-QMC result. To achieve a convergence, one may need to include higher configurations (and, in special cases, perhaps contributions from another set of the configurations which are generated from a different starting configuration, see M. Winder, A. Hariki, and Jan Kunes, arXiv: 2004:01428 [Link] ).

**3. Intra-configuration interaction (multiplet interaction)**

1) intra-atomic interaction of the Hamiltonian, e.g. Coulomb multiplet interaction, spin-orbit interaction, crystal field, magnetic field

2) the intra-atomic interaction (or its parameters) may depend on the electron filling of configurations and symmetry

**Note on onsite energy.**

Our code supports two ways to specify the on-site energy.**1)** as a charge-transfer(-like) energy (which follows convention in traditional core-level spectroscopy analysis)**2)** as a bare on-site energy. In the LDA+DMFT calculation, the bare energy is given by subtracting the double-counting correction (it is orbital and spin independent/diagonal shift) from the on-site energy in the LDA result.

The ** dc_info.dat** file (output of the DMFT code implemented in opw2x package) shows the value to be inputed as the charge-transfer energy (in

**). This value is calculated from the bare energy above, thus the two ways above are equivalent. Very importantly, the charge-transfer energy here is different and cannot be compared to the one in the cluster model because this value does not care the energy of the oxygen hole which will be naturally included later by the charge-transfer process in solving the Hamiltonian.**

*caseGS.and*To use the bare energy, the users provide this value as **user-defined operators** (which should be included for all configurations.) See below for details about how to include the user-defined operators.

*caseGS.ham*

*caseGS.ham*

========== Input for Hamil.f ========== Symmetry 1 (0:SO3, 1:Oh, 2:D4h, 3:D2h, 4:D3d, 5:Td, -1: user-defined) : symmetry No_Conf 4 : number of configurations to be included in the calculation No_Shell 3 : number of shells for active shells in the configurations PE-Shell 0 : index of photoelectron shell, if exists (it should not in ground-state calculation) Configuration: define configurations to be included in the ground-state calculation-1 -1 -1 : e/h rep. conversion (1: electron picture/ -1: hole picture) 1 D 2 L 0 L 0 : |d^{8}> 2 D 1 L 1 L 0 : |d^{9}L> 3 D 0 L 2 L 0 : |d^{10}L^{2}> 4 D 0 L 1 L 1 : |d^{10}LL> Diagonal Interaction (1:S-O 2:C.F. 3:Uvv 4:Ucv 5:M.F.): define intra-configuration interaction1 3 3 1.00 1.00 1.00 1.00 : configuration 1 has three interactions and three parameters. 1 1 2 1 3 1 : (spin-orbit interaction, acts on shell1), (crystal-field, acts on shell2), (direct Coulomb interaction, on shell3) 0.083 10.338 6.461 : spin-orbit coupling constant, F_{2}, F_{4}2 2 1 1.00 1.00 1.00 1.00 : crystal field parameters are defined below (since the number of independent parameters depend on the symmetry) 1 1 2 1 0.083 3 0 0 1.00 1.00 1.00 1.00 : no active configuration-diagonal interaction for d^{10}configuration 4 0 0 1.00 1.00 1.00 1.00

CF and MIX param : No_params // Prameter-set for CF/ LD/ OP *** Delete Parameter lines if corresopnding No_Params=0 *** 1 1 0 1 0.32 : number of CF parameter = 1, 10Dq 2 1.0 1.0 : number of independent hybridization function = 2, for d system in Oh symmetry, e_{g}and t_{2g}orbitals Transition (6:Mix 7:Rad 8:C.I.) : transitions between configurations (inter-configuration interaction) 6 3 3 : for mixing type (6), number of mixing paths (=3 in this example) 2 1 3 2 4 2 : path : <f|H|g> (conf2-conf1), (conf3-conf2), (conf4-conf2) 1 1 1 777 0 0 (888: end / 777: GS_character / 555: Upd / 999: Lifetime) 888 0 0 ===== End of input =====

**How to determine the crystal field parameters? **

In conventional fitting analysis of core-level spectra, the crystal-field parameters are adjusted to reproduce the experimental spectra or are set to values estimated for a reference compound. In the DFT+DMFT approach, the crystal-field parameters are estimated by DFT calculations for realistic crystal structures via wannierization, thus are not adjustable parameters. The on-site energies of d- (or f-)states are provided by the DFT calculation (output file named ** case_hr.dat**), thus their energy splitting measures the crystal field parameters above in the figure. To covert the on-site energies in the DFT result to the parameters (see figure above) used in the code, one can use a command

**.**

*opw_cfspec*example : execute opw_cfspec for D system in D3d symmetryenter system (1:P/2:D/3:F) 2 enter symmetry (1:Oh /2:D4h /3:D3d /4:D2h) 3 ====> basis order must be Eg-pi(1:2) / A1g / Eg-sigma(1:2) !! enter eig(1:5) -1.0 -1.0 -0.5 1.0 1.0 ====> ed0 / 10Dq / a = -0.100000 1.833333 0.500000

**Note.** *F ^{0}* part is included in

*U*(isotropic part), see

_{dd}*H*above, which is given by users in

_{imp}**file (not in**

*caseGS.and***). In**

*caseGS.ham***file only**

*caseGS.ham**F*and F

^{2}^{4}integrals are provide by the users. This treatment (separation) is useful for the fitting analysis of core-level spectra where

*U*is usually treated as a fitting parameter. Note

_{dd}*U*contributes only to configuration diagonal energy which depends only on the electron filling in the d-shell of the configuration. In conventional fitting analysis,

_{dd}*F*and

^{2}*F*parameters are computed by the atomic Hartree Fock calculation. In the LDA+DMFT approach, the Slater integrals are estimated using

^{4}*ab*-initio method e.g. constrained random phase approximation (cRPA).

Example. user-defined diagonal energies for d shell (e.g. ** double-counting correction**)

Diagonal Interaction (1:S-O 2:C.F. 3:Uvv 4:Ucv 5:M.F.): define intra-configuration interaction1 4 3 1.00 1.00 1.00 1.00 : configuration 1 has three interactions and three parameters. 1 1 2 1 3 1 12 1 0.083 10.338 6.461 2 3 1 1.00 1.00 1.00 1.00 1 1 2 1 12 1 0.083 3 1 0 1.00 1.00 1.00 1.00 12 1 4 1 0 1.00 1.00 1.00 1.00 12 1

888 0 0 User Operator 1 !<< no. of user-operator sets : max. 8 12 10 !<< set index / no. of elements : index (to be consistent above) / no.of elements 1.00 !<< constant factor 1 1 -49.00000000 0.00000000 2 2 -49.00000000 0.00000000 3 3 -49.00000000 0.00000000 4 4 -49.00000000 0.00000000 5 5 -49.00000000 0.00000000 6 6 -49.00000000 0.00000000 7 7 -49.00000000 0.00000000 8 8 -49.00000000 0.00000000 9 9 -49.00000000 0.00000000 10 10 -49.00000000 0.00000000 ===== End of input =====

**Important note. **

The code does not check the symmetry property of the user-defined operators, i.e. the code does not check whether the user-defied operators break the point-group symmetry given in ** caseGS.ham** file This may make a big problem since the code automatically truncates the matrix elements of the user-defined operators between the Hamiltonian blocks even if exist (Note. the block structure of the Hamiltonian is determined by the symmetry property without the user-defined operators!). Thus, the users must change the symmetry if your operators break (lowers) the original one. If the lowered symmetry is unclear (does not exist), choose

**, which deals with the full Hamiltonian.**

*symmetry=-1***Do you want to give operators in different basis rep.?**

Users may want to stick to not the spherical harmonics basis (*l,m _{l}*) but to different representation, e.g. cubic harmonics. In such a case, users can provide the desired unitary transformation in

**case.ush**file (which rotates the basis in the atomic shell with angular momentum l). When the

**file is provided, the user-defined operators in**

*case.ush***directly acts on the new representation.**

*caseGS.ham*## For cluster model calculation