Translation of fragment not orthogonal to original fragment

[efertitta]

I encountered the following error during fragmentation when calling for the externally corrected CCSD, with an orbital filter (relevant part of the input below). It seems it's not an issue in Vayesta but a problem caused by asymmetry in the MF (it works fine in Gamma, but fails with larger k-point grid). How can be addressed?

[CRITICAL]|      Translation(0.000000,0.000000,0.500000) of fragment Co not orthogonal to original fragment (overlap= 1.0e+00)!
Traceback (most recent call last):
  File "/cluster/projects/nn8040k/SEP-QUEST/BIGMAP/LiCoO2/KPOINTS/Vayesta_GTH_GDF_FCI_ext_method2/version2/LiCoO2_primitive/K_2/cell_111/spin_0/Embedding.py", line 80, in <module>
    with emb.iao_fragmentation() as f:
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/fragmentation/fragmentation.py", line 74, in __exit__
    fragments_sym = self.emb.create_transsym_fragments(translation, fragments=self.fragments)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/qemb/qemb.py", line 1045, in create_transsym_fragments
    return self.create_symmetric_fragments(symmetry, fragments=fragments, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/qemb/qemb.py", line 928, in create_symmetric_fragments
    raise RuntimeError("Overlapping fragment spaces (overlap= %.1e)" % fragovlp)
RuntimeError: Overlapping fragment spaces (overlap= 1.0e+00)

INPUT

emb = vayesta.ewf.EWF(mf, solver='CCSD', bath_options=dict(bathtype='mp2', threshold=eta))
fci_frags = []
with emb.iao_fragmentation() as f:
    fci_frags.append(f.add_atomic_fragment('Co', orbital_filter=['3d'], solver="FCI", bath_options=dict(bathtype="dmet"), store_wf_type="CCSDTQ", auxiliary=True))
    ccsd_frags = f.add_all_atomic_fragments(solver="CCSD", bath_options=dict(bathtype="mp2", threshold=eta))
for cc_frag in ccsd_frags:
    cc_frag.add_external_corrections(fci_frags, correction_type="external", projectors=2, low_level_coul=False)
emb.kernel()

[ghb24]

Can you provide the pyscf input to create the mf object?

[efertitta]

hi @ghb24, of course, this is the mf part

import os
import numpy as np
import pyscf
from pyscf.pbc import gto, scf, df

here = os.path.dirname(__file__)

cell = gto.Cell()

cell.a = np.array([[ 1.40562849,  0.81153999,  4.63648548],[-1.40562849,  0.81153999,  4.63648548],[ 0.,         -1.62307997,  4.63648548]])
cell.atom = [['Li', [0.0, 0.0, 0.0]], ['Co', [0.0, 1.62307997235, 2.31824273875]], ['O', [-6.492169233150939e-19, 2.400065585912509e-11, 3.338364128103741]], ['O', [1.4056284884, 0.8115399861759994, 1.2981213493962593]]]

cell.spin = 0
cell.unit = 'A'
cell.verbose = 4
cell.basis= 'gth-dzvp-molopt-sr'
cell.pseudo='gth-hf-rev'
cell.ke_cutoff = 200.0
cell.precision = 1.e-8
cell.build()

kpts = cell.make_kpts([2]*3)

print('Running HF')
mf = scf.KRHF(cell, kpts)
mf.with_df = df.GDF(cell, kpts)
mf.with_df.auxbasis = 'def2-qzvpp-ri'
mf.level_shift = 0.05
mf.max_cycle = 700
mf.chkfile = os.path.join(here,'hf.chk')
mf.kernel()

[efertitta]

Here is how I am attempting the Externally correction with FCI run on Cobalt only

emb = vayesta.ewf.EWF(mf, solver='CCSD', bath_options=dict(bathtype='mp2', threshold=1.e-3), solver_options=dict(diis_space=12, level_shift=0.05, diis_start_cycle = 2))

fci_frags = []
with emb.iao_fragmentation() as f:
    fci_frags.append(f.add_atomic_fragment('Co', solver="FCI", bath_options=dict(bathtype="dmet"), store_wf_type="CCSDTQ", auxiliary=True))
    ccsd_frags = f.add_all_atomic_fragments(solver="CCSD", bath_options=dict(bathtype="mp2", threshold=eta))

for cc_frag in ccsd_frags:
     cc_frag.add_external_corrections(fci_frags, correction_type="external", projectors=1)

emb.kernel()

[ghb24]

@abhishekkhedkar09 : Could you test this? I think it should be as simple as adding

cell.space_group_symmetry = True
cell.symmorphic = True

before the cell.build()
and
kpts = cell.make_kpts([2, 2, 2], space_group_symmetry=True, time_reversal_symmetry=True, symmorphic=True) to the kpnt builder, to enforce time-reversal symmetry...?

[efertitta]

I tried your suggestions but did not help, unfortunately
What I was trying to do was to have FCI solved only on 3d of Co and use this to correct the CCSD part as such:

emb = vayesta.ewf.EWF(mf, solver='CCSD', bath_options=dict(bathtype='mp2', threshold=1.e-3))
fci_frags = []
with emb.iao_fragmentation() as f:
    fci_frags.append(f.add_atomic_fragment('Co', orbital_filter=['3d'], solver="FCI", bath_options=dict(bathtype="dmet"), store_wf_type="CCSDTQ", auxiliary=True))
    ccsd_frags = f.add_all_atomic_fragments(solver="CCSD", bath_options=dict(bathtype="mp2", threshold=eta))
for cc_frag in ccsd_frags:
     cc_frag.add_external_corrections(fci_frags, correction_type="external", projectors=1)
emb.kernel()

This does not work, however I noticed that if you call for f.add_all_atomic_fragments the fragmentation proceeds smoothly (but the FCI crashes because the full DMET space for Co is too large)
So I tried to use the following workaround based on the same syntax in f.add_all_atomic_fragments and this actually works without any problem

emb = vayesta.ewf.EWF(mf, solver='CCSD', bath_options=dict(bathtype='mp2', threshold=1.e-3))
fci_frags = []
with emb.iao_fragmentation() as f:
      for atom in range(emb.kcell.natm):
          if atom == 1: #Co-index is 1
             fci_frags.append(f.add_atomic_fragment(atom, orbital_filter=['3d'], solver="FCI", bath_options=dict(bathtype="dmet"), store_wf_type="CCSDTQ", auxiliary=True))
      ccsd_frags = f.add_all_atomic_fragments(solver="CCSD", bath_options=dict(bathtype="mp2", threshold=eta))
for cc_frag in ccsd_frags:
     cc_frag.add_external_corrections(fci_frags, correction_type="external", projectors=1)
emb.kernel()

Why does this work? Am I now adding the Co fragments in every cell and symmetrizing afterwards???

[abhishekkhedkar09]

@efertitta I will test the above two as well and get back to you. Could you please provide the error you get in the first one above? If passed a string to add_atomic_fragment('Co' ... it is converted into a list in Vayesta so it should work...

[efertitta]

@abhishekkhedkar09 I get the following error when using the first syntax above

[CRITICAL]|      Translation(0.000000,0.000000,0.500000) of fragment Co not orthogonal to original fragment (overlap= 1.0e+00)!
Traceback (most recent call last):
  File "/cluster/projects/nn8040k/SEP-QUEST/BIGMAP/LiCoO2/KPOINTS/Vayesta_GTH_GDF_FCI_ext_method2/version2/LiCoO2_primitive/K_2/cell_111/spin_0/Embedding.py", line 80, in <module>
    with emb.iao_fragmentation() as f:
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/fragmentation/fragmentation.py", line 74, in __exit__
    fragments_sym = self.emb.create_transsym_fragments(translation, fragments=self.fragments)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/qemb/qemb.py", line 1045, in create_transsym_fragments
    return self.create_symmetric_fragments(symmetry, fragments=fragments, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cluster/home/edoardof/.local/lib/python3.11/site-packages/Vayesta/vayesta/core/qemb/qemb.py", line 928, in create_symmetric_fragments
    raise RuntimeError("Overlapping fragment spaces (overlap= %.1e)" % fragovlp)
RuntimeError: Overlapping fragment spaces (overlap= 1.0e+00)

[abhishekkhedkar09]

@efertitta
Turns out specifying atomic fragments by string method like this: "Co" selects all (in this case, all 8 due to kmesh [2,2,2]) instances of "Co" atoms into a single fragment. That is why the overlap was ~1.0. We will have this behaviour fixed soon, but in the meantime specifying add_atomic_fragment([1] ... ) should fix the problem...

[abhishekkhedkar09]

I have marked this issue with enhancement feature request so that we'd circle back to this.