Adds user option for ScreeningType::None

[EricaCMitchell]

Description

Add ScreeningType::None as a user option and sets ScreeningType::Schwarz as the default. This should allow use of mixed basis set types to be used in integrals as well.

User API & Changelog headlines

N/A

Dev notes & details

• Breaks out of setup_sieve() in twobody.cc before exception can be thrown
• Adds "NONE" to list of options in read_options.cc

Checklist

• Tests added for any new features
• All or relevant fraction of full tests run](http://psicode.org/psi4manual/master/build_planning.html#how-to-run-a-subset-of-tests)

Status

• Ready for review
• Ready for merge

[jturney]

Looks good!

[davpoolechem]

So I cross-checked this with the CompositeJK methods, and; as I somewhat suspected might happen, the CompositeJK methods do not work with screening none. SCF_TYPE DFDIRJ+LINK segfaults, while SCF_TYPE DFDIRJ+COSX gives the wrong answer, from my testing.

The composite methods partially implement the screening machinery within themselves instead of relying entirely on the TwoBodyAOInt::shell_significant() function for sieving. Some TwoBodyAOInt member functions, such as TwoBodyAOInt::shell_pair_values (used in DF-DirJ), and TwoBodyAOInt::shell_pair_significant (used in LinK) are used to assist with this. However, these functions rely on values that (specifically, shell_pair_values_, screening_threshold_squared_, and max_integral_) are initialized during the call to TwoBodyAOInt::create_sieve_pair_info, which is never called when screening_type is set to none due to the return upon registering ScreeningType::None for the sieve during TwoBodyAOInt::setup_sieve. That's where I suspect these problems are coming from.

Given this wasn't caught by CI, it may be reasonable to add a new test for different JK methods at different screening types, but that wouldn't be for this PR.

[loriab]

lgtm, thanks!

I agree with DP that a parametrize on the test_erisieve going through the scf_types could be a good precaution -- we can schedule that as a group programming segment.

[davpoolechem]

Talking to @loriab some, I'll be happy to let this PR be merged in as-is, and fix up the issues I brought up earlier in other PRs.