Inconsistent result of overlap matrix of cc-pVDZ for H2 compared to libcint

[frankwswang]

The overlap matrix I got from the following code

from pyscf import gto
mol = gto.M(unit ='bohr', atom='H 0 0 0; H 1 0 0', basis='cc-pvdz')
s = mol.intor('int1e_ovlp')

has a few matrix elements quite different from what I would get by using libcint. Specifically, at indices: [0, 0], [1, 0], [5, 0], [6, 0], [7, 0], [0, 1], [5, 1], [5, 2], [0, 5], [1, 5], [2, 5], [5, 5], [6, 5], [0, 6], [5, 6], [0, 7].

[hebrewsnabla]

You may need to check the way you generate _env (compare with gto.mole.make_env), especially the structure convention of _env and the normalization step. If this does not help, you can post some demo codes describing how you use libcint and what results you have got.

[frankwswang]

You may need to check the way you generate _env (compare with gto.mole.make_env), especially the structure convention of _env and the normalization step. If this does not help, you can post some demo codes describing how you use libcint and what result you have got.

Hi! Thanks for the reply! This is the result I got from mol._env:

[ 0.          0.          0.          0.          0.          0.
  0.          0.          0.          0.          0.          0.
  0.          0.          0.          0.          0.          0.
  0.          0.          0.          0.          0.          0.
  1.          0.          0.          0.         13.01        1.962
  0.4446      0.57976406  0.98341958  1.11930215  0.122       0.52153673
  0.727       1.95840453]

But I couldn't make gto.mole.make_env(mol._atm, mol._basis) as it would prompt

AttributeError("'numpy.int32' object has no attribute 'isalpha'")

On the other hand, it's kind of hard for me to post a clean demo code using libcint because I was wrapping it using a programming language called Julia and designed a proprietary data type to represent the basis function. I can, however, give you the result I got from my code (the ordering of angular momentum part of GTO is (1,0,0), (0,1,0), (0,0,0) in cartesian representation):

  1.0        0.903687  0.0       0.0       0.0       0.858338  0.836484  -0.378876  0.0       0.0
  0.903687   1.0       0.0       0.0       0.0       0.836484  0.940823  -0.129713  0.0       0.0
  0.0        0.0       1.0       0.0       0.0       0.378876  0.129713   0.1898    0.0       0.0
  0.0        0.0       0.0       1.0       0.0       0.0       0.0        0.0       0.695239  0.0
  0.0        0.0       0.0       0.0       1.0       0.0       0.0        0.0       0.0       0.695239
  0.858338   0.836484  0.378876  0.0       0.0       1.0       0.903687   0.0       0.0       0.0
  0.836484   0.940823  0.129713  0.0       0.0       0.903687  1.0        0.0       0.0       0.0
 -0.378876  -0.129713  0.1898    0.0       0.0       0.0       0.0        1.0       0.0       0.0
  0.0        0.0       0.0       0.695239  0.0       0.0       0.0        0.0       1.0       0.0
  0.0        0.0       0.0       0.0       0.695239  0.0       0.0        0.0       0.0       1.0

I was able to reproduce this result in other packages like gbasis and pyqint, but not the one from PySCF. An interesting discovery was that when I used the PySCF interface function gbasis.wrappers.from_pyscf in gbasis to generate the basis set, I got the same result as what PySCF would generate. I suspect there's something wrong with the basis set building process in PySCF?

[hebrewsnabla]

First, are you using exactly the same basis set as PySCF? You can compare PySCF's built-in basis set in pyscf/gto/basis with yours. Second, whatever wrapper you use, you must pass a _env to libcint. Could you print it out and compare it with PySCF's mol._env?

[hebrewsnabla]

Oh, I found that if I copy the cc-pvdz basis set from BSE, I can reproduce your result with PySCF. PySCF's built-in cc-pvdz is different from BSE's default version of cc-pvdz but the same as BSE's "Optimize General Contractions" version of cc-pvdz.

[frankwswang]

Oh, I found that if I copy the cc-pvdz basis set from BSE, I can reproduce your result with PySCF. PySCF's built-in cc-pvdz is different from BSE's default version of cc-pvdz but the same as BSE's "Optimize General Contractions" version of cc-pvdz.

Oh, thanks for the reply! Later I noticed as well that the basis set data I used was different from the one in PySCF, but I didn't know which configuration the basis set in PySCF corresponds to. Thanks for the clarification!