RI-MP2/def2-tzvppd convergence issue for calculations with iodide

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

dimer.txt (3.2 KB)
dimer.dat (67.9 KB)

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.

Thank you for getting back at me. I will try this and let you know how it went.

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 :

  • dimer.dat : 2.0 to 3.0 angstrom; ends successfully.
  • dimer2.dat : 3.0 to 5.0 angstrom; does not converge.
    This brings me to a question, is it possible to continue the calculation when we fail to get to convergence ?

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.

Just out of interest, does setting guess core instead of guess sad help?

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.

Thank you for your support. I will work on it and update you.

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.

Hello,

Thank you for all your previous suggestions and your updated version of Psi4.

Although there are some improvements, I am still encountering convergence issues. For instance, I am running 5 different interaction energy scans with methylguanidium (mguan) and iodide (please refer to picture attached). Only one scan (h12_180) converged successfully (dimer.dat) and the 4 others do not converged.

Initially, the distance scan ranges from 2.0 to 6.0 with a step of 0.1. In the case of mguan, the calculation does not run beyond a distance of 3.8 (h31_180), 4.3 (n1_perp_, 4.4 (n3_perp) and 4.7 (h11_180).

Attached are the output (.dat) files for each scan.

Thank you,
Mirna


scan_n3_perp_i.dat (2.4 MB)
scan_n1_perp_i.dat (2.3 MB)
scan_h31_180_i.dat (1.8 MB)
scan_h12_180_i.dat (3.8 MB)
scan_h11_180_i.dat (2.6 MB)

With the 1.3 release h31_180 finished without issues for me. I removed the small basis set guess.

Confirming what hokru said. h31_180 works fine for me on 1.3rc3. Try the stable release here.