Top Page > Browsing

Problems with convergence Date: 2012/10/20 20:45 Name: Jan Rusz Dear Prof. Ozaki, I am often encountering problems with reaching convergence with OpenMX. An example input file is attached at the end of this message. I tried two different mixing schemes rmm-diisk and gr-pulay, I reduced the mixing parameters, played around (not exhaustively) with starting iteration and history parameters, but with no luck. Do you please have some general advice for handling various classes of problematic cases? I have another question: in the documentation you write that the number of processors used is limited to number of atoms in the system. But what about systems with few atoms, but a lot of k-points? For example for calculations of magneto-crystalline anisotropy, we often study not so large systems, but we use tens of thousands of k-points. In such situations a parallelization over k-points could be rather efficient. Finally, can one enforce by some option in the input file the caluclation of density matrix and Fermi level to be done by single diagonalization per k-point? You mentioned in Userguide that this algorithm becomes active only if spin multiplicity times the number of k-points is smaller than number of available CPUs. For systems with few atoms the matrices will not be that large, so perhaps the memory savings are not that essential. Thank you in advance. Best regards Jan Rusz --------------- input file --------------- # File Name # scf.restart on System.CurrrentDirectory ./ # default=./ System.Name s4p3d2nr2 level.of.stdout 1 # default=1 (1-3) level.of.fileout 1 # default=1 (1-3) #DATA.PATH ../../../DFT_DATA11 # default=../DFT_DATA11 # # Definition of Atomic Species # Species.Number 2 <Definition.of.Atomic.Species Fe Fe6.0H-s2p1d1f1 Fe_PBE11H P P7.0-s1p1d1 P_PBE11 Definition.of.Atomic.Species> # # Atoms # Atoms.Number 9 Atoms.SpeciesAndCoordinates.Unit FRAC # Ang|AU <Atoms.SpeciesAndCoordinates 1 Fe 0.59461 0.0000 0.5000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 2 Fe 0.000000 0.59461 0.5000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 3 Fe -0.59461 -0.59461 0.5000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 4 Fe 0.25683 0.0000 0.0000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 5 Fe 0.000000 0.25683 0.0000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 6 Fe -0.25683 -0.25683 0.0000 9.0 7.0 90.0 0.0 90.0 0.0 1 off 7 P 0.000000 0.0000 0.5000 3.0 2.0 90.0 0.0 90.0 0.0 1 off 8 P 0.333333 0.666667 0.0000 3.0 2.0 90.0 0.0 90.0 0.0 1 off 9 P 0.666667 0.333333 0.0000 3.0 2.0 90.0 0.0 90.0 0.0 1 off Atoms.SpeciesAndCoordinates> Atoms.UnitVectors.Unit Ang # Ang|AU <Atoms.UnitVectors 5.8710 0.0000 0.0000 -2.9355 5.0844 0.0000 0.0000 0.0000 3.4660 Atoms.UnitVectors> # # SCF or Electronic System # scf.XcType GGA-PBE # LDA|LSDA-CA|LSDA-PW scf.SpinPolarization NC # On|Off CHANGE TO NC FOR MAG scf.ElectronicTemperature 300.0 # default=300 (K) scf.energycutoff 150.0 # default=150 (Ry) scf.maxIter 100 # default=40 scf.EigenvalueSolver band # Recursion|Cluster|Band scf.Kgrid 8 8 8 # means n1 x n2 x n3 scf.Mixing.Type gr-pulay # Simple|Rmm-Diis|Gr-Pulay scf.Init.Mixing.Weight 0.050 # default=0.30 scf.Min.Mixing.Weight 0.001 # default=0.001 scf.Max.Mixing.Weight 0.020 # default=0.40 scf.Mixing.History 5 # default=5 scf.Mixing.StartPulay 50 # default=6 scf.criterion 1.0e-8 # default=1.0e-6 (Hartree) scf.Constraint.NC.Spin on scf.Constraint.NC.Spin.v 1.0 scf.SpinOrbit.Coupling on # # MD or Geometry Optimization # MD.Type nomd # Nomd|Opt|DIIS|NVE|NVT_VS|NVT_NH

Page: [1]

Re: Problems with convergence ( No.1 ) Date: 2012/10/22 17:01 Name: Jan Rusz Dear Prof. Ozaki, I add another observation: After the initial 50 iterations ("scf.Mixing.StartPulay 50") the new mixing routine starts and I copy/paste here a few interations from *.DFTSCF files: SCF= 50 NormRD= 0.029866445787 Uele= -138.011795716984 SCF= 51 NormRD= 0.029866445787 Uele= -138.011763935503 SCF= 52 NormRD= 0.136526993510 Uele= -138.009492585432 SCF= 53 NormRD= 0.136526993510 Uele= -138.011492530299 SCF= 54 NormRD= 0.085726742777 Uele= -138.006783425406 SCF= 55 NormRD= 0.085726742777 Uele= -138.011455439785 SCF= 56 NormRD= 0.140415763532 Uele= -138.005924460914 SCF= 57 NormRD= 0.140415763532 Uele= -138.011151506355 SCF= 58 NormRD= 0.150263169566 Uele= -138.018107601910 SCF= 59 NormRD= 0.150263169566 Uele= -138.011439253316 I find it curious that the "NormRD" is identical in pairs of iterations. This behavior remains until the end. Also, when the new mixing routine starts, the NormRD initially goes up quite significantly. Right now, the system appears to converge, but very very slowly. I did similar calculations with WIEN2k MSR1 mixing routine with default parameters and it converged in 40-50 steps. While in OpenMX a single iteration is much faster (at my present computational parameters by factor of 4-5), the number of iterations needed by OpenMX are hundreds and as a result, the calculation is in fact much slower. For our project, this is a testing calculation and we will need to deal with larger systems. Therefore we expect that OpenMX will be much faster. But we would need to understand better, how to optimize the mixing parameters. Thank you in advance Jan Rusz Re: Problems with convergence ( No.2 ) Date: 2012/11/29 01:17 Name: Kamaram  <kmunira@mint.ua.edu> Hi, Did you ever find a solution to your problem? I am having the same. Kamaram Re: Problems with convergence ( No.3 ) Date: 2012/11/30 22:54 Name: Jan Rusz Hello, unfortunately I did not. Temporarily using WIEN2k that converges for these systems very well. Jan

Page: [1]