MolSSI-BSE / basis_set_exchange

A repository for quantum chemistry basis sets
https://molssi-bse.github.io/basis_set_exchange/
BSD 3-Clause "New" or "Revised" License
151 stars 44 forks source link

vDZP basis #266

Open susilehtola opened 1 year ago

susilehtola commented 1 year ago

Published in J. Chem. Phys. 158, 014103 (2023).

I did some preliminary work in the basis_set_exchange-historical branch to convert the format into something that the BSE can parse.

The problem I ran into is that F has a peculiar ECP, which reads in ORCA format

  NewECP F 
  N_core  2
  lmax  f
 s    2
  1     22.35040000  102.59795200    2
  2     11.17520000   19.04966300    2
 p    2
  1     26.47680000  -15.14396000    2
  2     13.23840000    2.80292100    2
 d    0
 f    1
  1      1.00000000    0.00000000    2
  end

This means that there is no d-f projector, which might be tricky for i/o...

susilehtola commented 5 months ago

Reading through the paper, it seems as if the ECP is correct:

For the ECP-2-MWB of the elements boron and fluorine, we discovered in the course of this project that the exponents of the d-f projector Gaussian functions are very small ⁠, leading to artificial potentials in larger molecules. This resulted in inconsistent NCI energies with ECP-caused errors of several kcal mol−1. For boron, we remedied this problem by increasing the exponent and adapting the corresponding Gaussian-ECP prefactor such that both typical thermochemistry results in GMTKN55 and NCI energies of boron model complexes are optimally described compared to accurate all-electron reference data. Afterward, the corresponding p-f projector was fine-tuned to account for the modified d-f projector. For fluorine, no beneficial effects of modifying the d-f projector were observed compared to its removal, so we deleted it from the fluorine ECP.

However, it will cause issues in many programs which typically assume that the projectors are continuous in l. A fix could be to add a D type projector with a vanishingly small coefficient.

marcelmbn commented 5 months ago

At this point, thank you again for your initiative to include the vDZP basis set into the basis set exchange database.

For the sake of consistency, I would refer to the below discussion, as it deals with the same topic: https://github.com/pyscf/pyscf/pull/2085#issuecomment-1951321264

I think (and hope) that the above-mentioned approach should solve this problem. Please let me know your thoughts about!

marcelmbn commented 5 months ago

FYI: For implementing the basis set into ORCA, I've set up a super simple Python script, reading the basis set in ORCA and reading it into a Python type. Outputting this to another format should be quite easy. Only an idea, maybe you don't need it at all or have better solutions. https://github.com/marcelmbn/ORCAbasissets

susilehtola commented 5 months ago

@marcelmbn if you want to contribute a proper ORCA reader into the Basis Set Exchange, that would be welcome. There is already a big bunch of readers in the BSE, you can follow their examples.

susilehtola commented 5 months ago

It also appears that the BSE cannot parse the vDZP basis in Turbomole format, either, since the basis set has been given in a format which is not really what is used in the Turbomole library.

susilehtola commented 5 months ago

@bennybp do you have time to work on this? It seems there would be interest in many codes to have this in BSE

susilehtola commented 5 months ago

My stabs so far are at https://github.com/MolSSI-BSE/basis_set_exchange-historical/tree/master/grimme

marcelmbn commented 5 months ago

It also appears that the BSE cannot parse the vDZP basis in Turbomole format, either, since the basis set has been given in a format which is not really what is used in the Turbomole library.

This might be. The basis functions itself are given in TURBOMOLE format but the identifiers (atom type/symbol) and the separators might be different from what BSE expects.

marcelmbn commented 5 months ago

Regarding this commit: https://github.com/MolSSI-BSE/basis_set_exchange-historical/commit/2db19e29bb95ccb4ec49e582f47c7d7d70b1b46e

Is there a specific reason why you've chosen a coefficient value infinitely close to zero instead of exactly 0.0?

susilehtola commented 5 months ago

The reason is in the commit message: this was what I agreed upon with Grimme. Having a function with exactly one function with zero coefficient can break sanity checks.

Message ID: @.***>