Top Page > Browsing

How to normalize charge density calculated from HOMO-LUMO Date: 2019/01/23 00:34 Name: Eike F. Schwier   <schwier@hiroshima-u.ac.jp> Hello everybody, I recently calculated a set of HOMO-LUMO cube's at different k-points. Using rho = sort(r^2 + i^2) I calculated the charge density associated with each HOMO-LUMO, I was now trying to compare the real space evolution of the charge density following a high symmetry direction in k-space. In order to compare the charge density quantitatively I wanted to ask if anybody could point me to a way of normalization of the cube files. The amount of points in the cube depends on the cutoff energy so that is easy to normalize, but when I look at the source code I cannot understand how the C matrix used to output the HOMO-LUMO relates to the LCAOs in the given band. Anybody could give me a hint/explanation? best wishes, Eike

Page: [1]

Re: How to normalize charge density calculated from HOMO-LUMO ( No.1 ) Date: 2019/01/23 00:55 Name: Mitsuaki Kawamura  <mkawamura@issp.u-tokyo.ac.jp> Dear Eike Hello, It is a little complicated to explain the code structure of OutData.c But I have a tool to compute the absolute value of an orbital at each position. https://drive.google.com/file/d/1JgvPaSF2mMOfI34TxPlcGvvJa4lzgKVh/view?usp=sharing You can see the usage by executing this without arguments. Best regards, Mitsuaki Kawamura ISSP, U-Tokyo Re: How to normalize charge density calculated from HOMO-LUMO ( No.2 ) Date: 2019/01/24 14:39 Name: Eike F. Schwier  <schwier@hiroshima-u.ac.jp> Dear Kawamura-san, thank you very much for sharing your code. I will try to use it for conversion and come back once I get some new results. best regards, Eike Re: How to normalize charge density calculated from HOMO-LUMO ( No.3 ) Date: 2019/08/16 18:10 Name: Eike F. Schwier Dear Kawamura-san, in the meantime I was able to plot the charge density, after checking your code. It turned out that I was missing a | |^2 . But now I have encountered a new problem. I was trying to look at the complex HOMO along a specific k-path in my system and I find that the phase of the homo behaves erratic. It seems that the phase rotates by pi and sometimes by pi/2. I.e. sometimes the sign of the real part of the homo changes from one k-point to the next and sometimes the real and imaginary parts exchange.(see VESTA plot of the cube files: https://www.dropbox.com/s/xb9a9ivetg26og1/openMX-homoPhase.pdf?dl=0) I tried to reproduce the error with the GaAs.dat from the wf_example folder. Modifying the number of basis functions and cut off energy seems to influence the behaviour, but does not resolve it. Electronic temperature, functional and k-grid did not seem to change the behaviour. I also tried to use the "scf.ProExpn.VNA off", but to no avail. Could you share your thoughts on this behaviour? Below I posted the input file with the highest basis set and cutoff I used (inspired by the basis and cutoff used in the PAO/VPS to compare openmx with wien2k). best regards, Eike # # File Name # System.CurrrentDirectory ./ # default=./ System.Name GaAs level.of.stdout 1 # default=1 (1-3) level.of.fileout 0 # default=1 (0-2) DATA.PATH /home/calc/src/openmx3.8.5/DFT_DATA13 # # # Definition of Atomic Species # Species.Number 2 <Definition.of.Atomic.Species Ga Ga7.0-s3p3d3f2 Ga_PBE13 As As7.0-s3p3d3f1 As_PBE13 Definition.of.Atomic.Species> # # Atoms # Atoms.Number 2 Atoms.SpeciesAndCoordinates.Unit FRAC # Ang|AU <Atoms.SpeciesAndCoordinates 1 Ga 0.0000 0.0000 0.0000 6.5 6.5 2 As 0.2500 0.2500 0.2500 7.5 7.5 Atoms.SpeciesAndCoordinates> Atoms.UnitVectors.Unit AU # Ang|AU <Atoms.UnitVectors 5.367 0.000 5.367 0.000 5.367 5.367 5.367 5.367 0.000 Atoms.UnitVectors> # # SCF or Electronic System # scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW scf.SpinOrbit.Coupling off # On|Off, default=off scf.SpinPolarization off # On|Off|NC scf.ElectronicTemperature 300.0 # default=300 (K) #scf.energycutoff 50.0 # default=150 (Ry) scf.Ngrid 32 32 32 scf.maxIter 100 # default=40 scf.EigenvalueSolver band # Recursion|Cluster|Band scf.Kgrid 14 14 14 # means n1 x n2 x n3 scf.Mixing.Type rmm-diisk # Simple|Rmm-Diis|Gr-Pulay scf.Init.Mixing.Weight 0.15 # default=0.30 scf.Min.Mixing.Weight 0.001 # default=0.001 scf.Max.Mixing.Weight 0.400 # default=0.40 scf.Mixing.History 25 # default=5 scf.Mixing.StartPulay 12 # default=6 scf.criterion 1.0e-8 # default=1.0e-6 (Hartree) scf.restart off # # MO output # MO.fileout on # on|off num.HOMOs 1 # default=2 num.LUMOs 0 # default=2 MO.Nkpoint 6 # default=1 <MO.kpoint 0 0 0.06 0 0 0.07 0 0 0.08 0 0 0.09 0 0 0.10 0 0 0.11 MO.kpoint> Re: How to normalize charge density calculated from HOMO-LUMO ( No.4 ) Date: 2019/08/16 18:36 Name: Mitsuaki Kawamura  <mkawamura@issp.u-tokyo.ac.jp> Dear Eike There is no relationship between phases of a Kohn-Sham orbital and another one. These phases are determined independently. The absolute value of the KS states can be comparable each other while the real- or imaginary- parts are not comparable. Best regards, Mitsuaki Kawamura Re: How to normalize charge density calculated from HOMO-LUMO ( No.5 ) Date: 2019/08/17 13:19 Name: Eike F. Schwier Dear Kawamura-san, thank you for the quick reply. It still seems puzzling to me that the phase is not random, but rather pi/2 and depending on the calculation parameter (cutoff, basis set). But am I correct in that, except for k = 0 0 0 (where the imaginary part of the homo is zero), there is no reasonable representation of the HOMOs with k != 0? I.e., since those HOMOs have both real and imaginary parts, we cannot look at those HOMOs and conclude anything from them. The only possibility is to calculate the charge density? best regards, Eike Re: How to normalize charge density calculated from HOMO-LUMO ( No.6 ) Date: 2019/08/20 00:42 Name: Mitsuaki Kawamura  <mkawamura@issp.u-tokyo.ac.jp> Dear Eike How about the Fig. 74 in the page below: https://docs.quantumwise.com/tutorials/spin_bloch_gnr/spin_bloch_gnr.html Best regards, Mitsuaki Kawamura Re: How to normalize charge density calculated from HOMO-LUMO ( No.7 ) Date: 2019/08/21 20:07 Name: Eike F. Schwier Dear Kawamura-san, yes this is what I was thinking the MO(k) would look like. But they are talking about Bloch functions, not Kohn-Sham orbitals. Am I correct in assuming this is the reason why they can analyse the complex MOs? Since their MOs are Bloch functions? best regards, Eike

Page: [1]