we are currently encountering a “problem” when we try to perform an intramolecular SAPT (FISAPT) calculation on a cobalt complex.
When using the standard options (see below), the basis sets jun-cc-pvdz is obviously not available for cobalt.
set {
basis jun-cc-pvdz
scf_type df
guess sad
freeze_core true
}
energy('fisapt0')
An error message indicates that this basis set is not available for cobalt and a similar error also occurs when we simply use cc-pvdz as basis. However, when we modify the input as follows, the calculation terminates without any errors:
set {
basis cc-pvdz
MINAO_BASIS cc-pvdz
scf_type df
guess sad
freeze_core true
}
energy('fisapt0')
However, the SAPT results in this analysis are obviously incorrect, as exchange and interaction energies are in a range of 10 million kJ/mol. Of course, there could be other sources of error besides the choice of basis set, but this seems the most probable one at this time.
Do you have any advice for us how to proceed with this FISAPT analysis? Is there a simple way to generate the jun-cc-pvdz basis for cobalt or are there other suitable basis sets to carry out the FISAPT analysis?
I think I know your problem. You just need a decontracted cc-pVTZ basis set for Co for the MINAO basis role. I believe I even know the fix, just need to test it first.
Thank you very much for the basis set and all your effort.
The calculations run smoothly and complete without any error message. However, we have encountered another problem and wonder whether the FISAPT approach can be used at all for our complexes. In this complex, the cobalt ion is coordinated to a methylated cyclopentadienyl anion (Cp*) and an acetate ligand. In some cases, a substituted pyridine is coordinated as a third ligand as well. We are interested in the interactions between the cyclopentadienyl ligand and the other ligands and had planned to do FISAPT for that.
We first started with the input shown below for the complex including Cp* and acetate, which is an overall positively charged species.
memory 5 gb
molecule CpCo_CO_OAc_S{
0 1
O -1.91636 -1.07911 -0.41180
O -1.91658 1.07908 -0.41061
C -2.59437 -0.00002 -0.53903
C -4.04473 0.00006 -0.83804
H -4.51285 0.89826 -0.43992
H -4.51219 -0.90034 -0.44418
H -4.17024 0.00274 -1.92481
--
0 1
C 1.10310 1.17140 0.68054
C 0.77427 -0.00150 1.45562
C 0.21680 -0.00337 2.83056
C 0.89794 2.57607 1.12748
C 1.55774 0.72983 -0.57941
C 1.55826 -0.72753 -0.58109
C 1.93879 -1.56899 -1.74640
C 1.93787 1.57445 -1.74256
C 1.10393 -1.17236 0.67783
C 0.89950 -2.57813 1.12172
H 0.92024 -3.27365 0.28628
H -0.05221 -2.69801 1.63875
H 1.69257 -2.86303 1.81833
H -0.38542 0.88231 3.02525
H 1.04276 -0.00285 3.55030
H -0.38309 -0.89094 3.02374
H 0.91382 3.27290 0.29301
H 1.69356 2.86137 1.82104
H -0.05168 2.69343 1.64885
H 1.57713 1.15396 -2.68148
H 3.02869 1.62756 -1.81335
H 1.55886 2.58956 -1.65076
H 1.57412 -1.14845 -2.68381
H 1.56384 -2.58564 -1.65526
H 3.02961 -1.61773 -1.82002
--
1 1
Co -0.3338849 0.0001070 -0.2138702
symmetry c1
no_reorient
no_com
}
# => Standard Options <= #
basis {
assign aug-cc-pvdz
assign Co aug-cc-pvdz
}
set {
scf_type df
guess sad
freeze_core true
}
energy('fisapt0')
This resulted in an error message that charge and multiplicity do not match. Interestingly, when randomly assigning charges to the fragment (that in total sums up to an overall charge of 1), the calculation terminates normally but (probably not surprising) the SAPT analysis results in nonsense values (e.g., values around +/- 1700 kJ/mol). As a consequence, we tried to define the link selection manually, but again we ended up with nonsense values.
Does anybody have any suggestions on how we can perform these FISAPT calculations for complexes of this kind or are there calculations (currently) impossible to perform? Any hint is highly appreciated.
The charge and multiplicity error you get comes from the fact that your second fragment has 15 H and 10 C, so that’s 75 electrons and it cannot be a singlet with a charge of 0. Similarly, your first fragment has 3 H, 2 O and 2 C, which without a charge gives 31 electrons so it cannot be a singlet either (unless I miscounted in which case I apologize).
The way the FISAPT code works is by localizing orbitals, then identifying the bonding ones (based on the atomic partial charge). The bonding orbitals are then attributed to fragment C, and a proton from the interacting partner is also formally attributed to fragment C to avoid modifying the fragment charge.
So, I am not sure about the bonding situation in Cp*…Co, but the code can really support 2 electron/2 center bonds. If there is anything like 5 C atoms coordinated to a Co, you’re probably going to get weird results. A possible fix is to tell the code there is no link between Cp* and Co, this way the code will not try to move orbitals or protons around. My advice would be to have a look at the localized orbitals to get a better idea of what you want the code to do with them.