Greetings, everyone!
I’m fairly new to using Psi4 for DFT calculations, and I’ve been having troubles with SCF non-convergence in studying a non-covalent interaction between water and zinc cation system at a b3lyp level of theory. Given the simplicity of the system, I’m really confounded as to the reason behind this non-convergence. I’d really appreciate it if some of the more seasoned users in this forum could help me out!
Kindly find my input file below:
molecule {
0 1
H 0.76000 -0.58700 0
O 0 0 0
H -0.76000 -0.58700 0
--
2 1
Zn 0 3 0
}
set {
basis 6-31G*
scf_type df
guess sad
reference rks
}
optimize('b3lyp')
And here’s the tail end of the SCF calculations:
@DF-RKS iter 90: -1854.59927519761118 -9.55472e-01 3.25756e-03 ADIIS/DIIS
@DF-RKS iter 91: -1853.61857209758432 9.80703e-01 2.55821e-02 ADIIS/DIIS
@DF-RKS iter 92: -1853.62703880685171 -8.46671e-03 2.53219e-02 ADIIS/DIIS
@DF-RKS iter 93: -1853.62297854120516 4.06027e-03 2.54584e-02 ADIIS/DIIS
@DF-RKS iter 94: -1853.62618769173014 -3.20915e-03 2.53443e-02 ADIIS/DIIS
@DF-RKS iter 95: -1853.63156450183374 -5.37681e-03 2.51643e-02 ADIIS/DIIS
As y’all can see, the RMS seems to oscillate at around 2.5e-02
, and fails to reach convergence. I’ve tried increasing the max_iter
as well as using damping, but nothing seems to budge.
Thank you very much in advance for any suggestions you might have!
This isn’t a simple system at all. Sure, the geometry is simple, but Zinc has many low-lying electronic states, and that makes converging the SCF hard. That said, this is no excuse. There are some DFT convergence tricks that exist and that would help, but that Psi can’t do yet. I would love to add those, but alas, there’s not enough time in the day.
Here’s what I can say:
- The 6-31G* basis set is too small to capture the noncovalent interaction between Zn and O that are 3 A apart from each other. If you insist on an Pople-style basis set, you need something with + symbols. For DFT, Ahlrichs-type basis sets are a better default, although there are exceptions! When I switch the basis set, convergence improves.
- Your SCF is flipping occupation. It can’t decide if the orbitals are [11, 1, 4, 3] or [10, 1, 4, 4]. You can help Psi out either by picking an occupation, i.e., setting
docc
in options, or by disabling symmetry altogether by setting symmetry c1
in the molecule block. I’ve tried both. Disturbingly, I’m getting a lower energy by turning symmetry off than by choosing an irrep. That might mean symmetry-breaking, but more likely means Psi’s SCF convergence is doing worse than I thought for this system. I have tools to investigate this for Hartree-Fock, but they don’t work for RKS GGA functionals yet. If all goes well, I’ll have them in time for the next release, but that’s a few months out still.
1 Like
Thanks for the insight, Dr. Misiewicz!
I tried both: used the Karlsruhe basis set as well as disabling symmetry. TZ and QZ both seem to bring convergence in the first iteration, albeit at different durations. However, I’m encountering another error and I hope you won’t mind if I inquire further.
EDIT: After further reading I understand how symmetry breaking leading to lower energies is concerning for this system. I’m still in the middle of looking into it and getting the geometry optimization to work with reasonable results. Cheers!
Since I’m trying to run an geom. optimization procedure, the process seems to run into a wall after the first SCF convergence with the following error message:
!-----------------------------------------------------------!
! !
! Engine::lmax_exceeded -- angular momentum limit exceeded !
! !
!-----------------------------------------------------------!
Based on previous posts, this seems to be an issue with the build, or the maximum angular momentum limit set by the basis set themselves. It also seems like rebuilding Psi4 while allowing larger MAX_AM_ERI
values. Would you perhaps have a suggestion on the fix to this problem if the installation is done through the Psi4conda-1.7-py38-Linux-x86_64.sh
Linux installer?
This is an issue with the installation, not the basis set itself. I always defer to @loriab for this particular error.