Page 1 of 1

BSSE and counterpoise correction in solvent

Posted: 26 Feb 2020, 08:43
by taylor
I am confused about how to run a counterpoise-corrected calculation of BSSE in a solvent. All attempts to use SubSystems and .INTERACTIONENERGY fail with segfaults. But if we explicitly construct a calculation with the ghost basis using Phantom, then the calculation fails to converge in the SCF but anyway the energy in each iteration is absolute garbage (should be -1700 Eh and is -4400...). I am wondering whether with ghost atoms present there is something amiss with the automatic cavity generation?

Best regards
Pete

Re: BSSE and counterpoise correction in solvent

Posted: 26 Feb 2020, 09:23
by rob
Hello Pete,
I suspect the ghost atoms are also getting their own sphere. I am unaware of the options to run CP correction with LSDALTON, could you post a minimal example of the .dal and .mol files? I'll then try to troubleshoot.
Thanks!
Roberto

Re: BSSE and counterpoise correction in solvent

Posted: 26 Feb 2020, 13:43
by taylor
This is unfortunately the smallest example we have immediately to hand. I can try to fudge something together but I wanted to give you something sooner rather than later. This is old-skool with an explicit ghost basis, not using the fancy INTERACTIONENERGY option in LSDalton. Although this will run 100 iterations if allowed (and then abort) this is not necessary. The energy should be about -1703 and the moment it produces anything else it can be killed. Note that without solvent this calculation works fine, converges in 13 iterations...

Best regards
Pete
P.S. The stupid website will not accept a .pcm file, so it is here inline. This is the stuff you sent me for DMF.

Code: Select all

UNITS = ANGSTROM
MEDIUM
{
  SOLVERTYPE = IEFPCM
  PROBERADIUS = 1.385
  NONEQUILIBRIUM = True
  SOLVENT = EXPLICIT
  GREEN<INSIDE>
  {
    TYPE = VACUUM
  }
  GREEN<OUTSIDE>
  {
    TYPE = UNIFORMDIELECTRIC
    EPS = 35.688
    EPSDYN = 2.0463
  }
}

CAVITY
{
                TYPE = GEPOL
                AREA = 0.3
                MODE = IMPLICIT
}

Re: BSSE and counterpoise correction in solvent

Posted: 28 Feb 2020, 10:33
by rob
Hello Pete,
I think you've hit a couple of problems (jackpot?)
Problem 1 The monomer cavity is generated when setting phantom atoms. It seems the consensus (see papers attached) is to use the dimer cavity throughout when evaluating CP corrections for BSSE.

I've streamlined your example to a water dimer (attached mol file) to highlight this problem. If you run with:

Code: Select all

lsdalton nod3 h2o_dimer dmf
and look at the output file, under the

Code: Select all

~~~~~~~~~~ PCMSolver ~~~~~~~~~~
section, you'll see that the monomer cavity is generated when passing phantom atoms. I'm not sure how to always pass the full list of atoms to PCMSolver. There's now an issue on GitLab to ask for help on this and come up with a fix https://gitlab.com/dalton/lsdalton/issues/75
As a (tedious) workaround: you can explicitly set the list of spheres to use to generate the cavity in the PCM input file. For the water dimer example:

Code: Select all

UNITS = ANGSTROM
MEDIUM
{
  SOLVERTYPE = IEFPCM
  PROBERADIUS = 1.385
  NONEQUILIBRIUM = True
  SOLVENT = EXPLICIT
  GREEN<INSIDE>
  {
    TYPE = VACUUM
  }
  GREEN<OUTSIDE>
  {
    TYPE = UNIFORMDIELECTRIC
    EPS = 35.688
    EPSDYN = 2.0463
  }
}

CAVITY
{
  TYPE = GEPOL
  AREA = 0.3 
  MODE = EXPLICIT
  SPHERES = [
    -1.551007,   -0.11452,     0.,        1.824, # O1
    -1.93425901,  0.762503,    0.,        1.44, # H1
    -0.599677,    0.040712,    0.,        1.44, # H2
     1.350625,    0.111469,    0.,        1.824, # O2
     1.68039801, -0.373741,   -0.758561,  1.44, # H3
     1.68039801, -0.373741,    0.758561,  1.44  # H4
  ]
}
Note:
  • You can use Angstrom or atomic units.
  • The scaling of the radii by 1.2 will not be automatically applied. You need to do that by hand.
Problem 2 With your specific choice of cavity you hit a numerical instability in PCMSolver. One of the solvent response matrices is no longer symmetric positive-definite. I use Cholesky to form its inverse, hence the garbage numbers you reported. I am preparing a patch you can apply to the code to use LU rather than Cholesky.