[QUESTION] Asymmetric overlap correctness

[3laaHisham]

Hello Everyone,

I will try to summarize my finding as far as I could. is_overlap_included: Return True or False to indicate that these two contractions' overlaps cannot be ignored. It comes in response to whether overlap screening is required by the basis. if required, we verify the possibility by checking whether the shells are far away, and can be screened or not.

If the first contraction overlap screening is not required, we return True. Otherwise, we calculate the distance between the centers of the two shells, and then the cutoff distance (or distance limit) which depends on the shells' minimum exponents and tolerance. If the distance between the two shells is greater than the cutoff, we return False, otherwise True.

Now, I have two questions in mind regarding overlap and asymmetric overlap in particular.

1. For Asymmetric overlap /gbasis/integrals/overlap.py Line 185: is checking for only the first contraction's ovr_screen sufficient?

if not contractions_one.ovr_screen:
   return True

While it does not pose any problems with Symmetric Overlap, but I don't know if the same logic can be applied with Asymmetric Overlap between two contractions from two different basis set. As one of them can be False and the other True?

2. in overlap_integral, I need to ask what does this format in Line 145

coord_type = [ct for ct in [shell.coord_type for shell in basis]]

serve rather than just using

coord_type = [shell.coord_type for shell in basis]

[PaulWAyers]

I honestly never thought about screening based on asymetric overlap. My tendency is to say that the asymmetric overlap case should be explicitly excluded. (Though I realize there would be cases where attempting a screening for an asymetric overlap integral might be useful, it seems like the sort of very special case that I feel we should only implement at the point someone encounters it in real life, unless it is very easy to support.)

[3laaHisham]

I honestly never thought about screening based on asymmetric overlap. My tendency is to say that the asymmetric overlap case should be explicitly excluded. (Though I realize there would be cases where attempting a screening for an asymmetric overlap integral might be useful, it seems like the sort of very special case that I feel we should only implement at the point someone encounters it in real life, unless it is very easy to support.)

While I don't really know how applicable it is in real life as I don't have much knowledge about QC. It can be actually said that it is already implemented.

in gbasis/integrals/overlap_asymm.py Line 63:

construct_array_contraction = staticmethod(Overlap.construct_array_contraction)

Which means that it already uses the method of Symmetric Overlap, which in turn checks for is_overlap_included. However, as I have stated before, it only check for the first contraction's screen requirement, not also the second (Knowing that in Symmetric case we don't really need to, as they both are the same). But maybe in the logic, they both need to require screening to apply it?

Moreover, I believe it would be really easy to fix if needed.