Hello,
I am struggling with getting my calculations to converge. I am ruunning interaction energy scan of iodide with benzene, nma and other compounds. I tried using SOSCF, MOM, DAMPING options but none is working. I uploaded the input and output for the case of NMA for you to have a look and hopefully you can tell me what am I doing wrong or what I can do to get to convergence.
Thank you,
Mirna
Hello,
Here is the error that I get :
=> Loading Basis Set <=
Name: ANONYMOUSA6868012
Role: ORBITAL
Keyword: BASIS
atoms 1, 3, 5, 7, 9, 11 entry C line 144 file /home/mirna.damergi1/yes/envs/p4env/share/psi4/basis/def2-tzvppd.gbs
atoms 2, 4, 6, 8, 10, 12 entry H line 14 file /home/mirna.damergi1/yes/envs/p4env/share/psi4/basis/def2-tzvppd.gbs
atoms 13 entry I line 2463 (ECP: line 3806) file /home/mirna.damergi1/yes/envs/p4env/share/psi4/basis/def2-tzvppd.gbs
!!! WARNING: ECP capability is in beta. Please check occupations closely. !!!
I tried to change the number of iterations (using maxiter), set SOSFC and MOM to true, set the orthogonalization to canonical. Yet, my systems with Iodide do not converge neither with def2-tzvppd or with def2-tzvpd.
Should I set SAD_FRAC_OCC to true ? This option appears below the Expert SAD Guess Algorithm.
Thank you for your help,
Mirna
Sorry it took so long to get back to you. Looking at the output it appears that SOSCF does help considerably, you might try setting SOSCF_MAX_ITER = 15 and SOSCF_CONV=1.e-4 to tighten up the SOSCF iterations.
The next Psi4 release will also have the ability to do root finding for all SCF Wavefunction which might perform more optimally in this scenario as well.
Hello,
Unfortunately, although my calculations are getting to further steps, I still have a problem of convergence. Attached are two outputs from the same calculations.
The only difference is the range of distances I am using :
Thank you.
dimer.dat (583.7 KB)
dimer2.dat (431.2 KB)
While looking over your other topic, I noticed something dubious about your input file.
You are moving two ions away from each other but using a closed-shell reference. Have you tried switching to an open-shell reference, reference uks? It gets harder and harder to converge the closed-shell equations as the two parts of the system move away from each other, and the meaning of the closed-shell solution is less and less physical.
Also as I said in the other topic, try using guess read, so computations after your first one can use the orbitals from the previous geometry, which should be close to the ones you actually want.
Hello @jmisiewicz,
Thank you for your detailed answer in Convergene Algorithms. I will answer here as my answer is related to this topic.
After switching to the cc-pvdz basis set, reference uks or rohf and using the read guess, I still encounter convergence issues. Actually, with the others set-up (sad guess, default reference and cc-pvqz or def2-tzvppd basis sets), the calculations with Chloride and Bromide converged. I also have a problem with the fact that the cc-pvdz basis is not defined for iodide which I am interested in. The basis sets available for Iodide contains ECP (def2-tzvppd) or PP (pseudopotential, cc-pvdz-pp) basis sets. Mind you, the cc-pvdz-pp is not already defined for iodide so I used the Psi4 basis set library route from user-defined basis set section to add it as cc-pvdz-pp-ri.gbs in the Psi4 basis set library(I am net to GitHub so I did not know if it is worth a PR or not). Once it will be verified and added, I will try to run Iodide using this basis set. However, I doubt it will work.
Just so you have the big picture of what I am doing, here is a rough summary. I am calculating interaction energy scan from 1.5 to 6.0 Angstroms of Iodide, Chloride or Bromide with compounds such as benzene, imidazole, indole, methanol, methanethiol, methylguanidium and N-methylacetamide among others. For Chloride and Bromide, I was able to try several basis sets (cc-pvqz, def2-tzvppd) as they are available for them. The real struggle is with iodide.
I can upload all the inputs that worked with iodide to let you see and maybe you will be able to help me with my issue.
Thank you again for your time and help.
Just so you know, I’m not going to be looking at this directly for a few days. At this point, I need to try to run inputs myself, but I keep running into a bug when I try to run your input files. Your input files are fine. This is an unintended consequence of fixing another bug. I’ll look into this again when that’s fixed.
Thank you. I will then upload inputs with different systems and explain in more details what I am trying to do.
Hello @jmisiewicz,
Setting the guess to read and the reference to uks instead of rohf does not help. So I uploaded input (.txt)/output(.dat) files of calculations that end up with (phet, benz) / without (nma) converging. Please note, that the three output of calculations converged using 3 differents parameters in the inputs.
Thank you for your help,
Mirna
benz-scan_pi_i-dimer.txt (3.1 KB)
nma-scan_nh_i-dimer.txt (3.0 KB)
phet-scan_120_i-dimer.txt (2.9 KB)
phet-scan_pi_i-dimer.txt (3.2 KB)
nma-scan_nh_i-dimer.dat (103.9 KB)
phet-scan_120_i-dimer.dat (1.3 MB)
benz-scan_pi_i-dimer.dat (1.8 MB)
I’ll give them a look, but I’m in the thick of some problems of my own right now, so it may be some time before I can work on this again.
Ping me again if I don’t respond in a week. Of course, anybody else is welcome to take a look while I’m otherwise occupied.
I’ve (finally!) been able to fix Psi so that your input file will run on the latest version, so I can start investigating this more carefully. The newest version of Psi has new-and-improved counterpoise correction technology.
What you’ve found is a catastrophic failure of the basis projection system. There is no reason why -6892 hartrees in the small basis should project to +590 hartrees in the large basis. Casting up doesn’t even preserve the orbital occupation. I have no idea how that happens. This is most definitely a bug. I tried swapping your ECP containing basis set for a non-ECP containing basis set, and sane behavior was restored. As I was afraid of, this is an ECP bug.
I’ll pass the word on to the other developers. I don’t think there’s much you can do.
On second thought, I was premature. (I’m posting again to make absolutely sure you see this.)
You must not use basis_guess with a basis set containing ECPs. Try an optimization where you don’t use that setting, and tell me how it goes.
It’s taken a while, but we have the developer version of Psi4 on conda!
Follow the instructions for Linux -> Conda -> Nightly here. Let me know if you’re still having problems. Now that we’ll be using the same version of Psi, investigating should be easier.
You should still be wary about basis_guess when ECPs are involved, though. I think you’ll be safe if you select a guess basis using the same size ECP.
psi will at least now stop if your basis_guess basis and your primary orbital basis have different numbers of ECP electrons. but yes, good to use set basis_guess def2-sv(p) with an orbital basis with ECP.