-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add qcmanybody interface #203
base: master
Are you sure you want to change the base?
Conversation
cwd = os.path.abspath(os.getcwd()) | ||
test_folder = os.path.join(cwd, 'test_generated_files', request.function.__name__) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this is a better way to get the name of the test folder? Please confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, function.__name__
gets the name of the test function (e.g., test_lif_bsse
) but node.name
gets the per-test name that includes parametrization (e.g., test_lif_bsse[psi4-nocp]
). The previous function way was no trouble when the tests were run in serial, but it led to file overwriting when running pytest in parallel.
# different programs just for flexibility of testing | ||
pytest.param("psi4", marks=addons.using_psi4), | ||
pytest.param("cfour", marks=addons.using_cfour), | ||
pytest.param("nwchem", marks=addons.using_nwchem), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think geomeTRIC has a NWChem interface, but maybe that's okay if the intent is for QCEngine to call NWChem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, integrating QCManyBody for geomeTRIC's first-class engines is a separate project (and one I didn't even think of initially). This PR is purely so that geometric.run_json
can take the slightly different schema layout for an OptimizationInput holding an ordinary gradient specification vs. holding a many-body gradient specification. (The divergence isn't long-term; we're revising the schema.) So the PR is really only good for the run_json half of the QCEngine engine of geomeTRIC.
@@ -41,3 +42,81 @@ def test_rdkit_simple(localizer): | |||
# Currently in angstrom | |||
ref = np.array([0., 0., -0.0644928042, 0., -0.7830365196, 0.5416895554, 0., 0.7830365196, 0.5416895554]) | |||
assert np.allclose(ref, ret.xyzs[-1].ravel(), atol=1.e-5) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you confirmed that these tests can run locally? How long do the tests take?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's not much proof but see below. They take about a minute in parallel (and ordinarily one wouldn't have psi4, nwchem, and cfour all accessible). At the moment they need software versions that are unreleased.
> pytest -v geometric/tests/test_qcengine.py -n 8
================================================================= test session starts ==================================================================
platform linux -- Python 3.12.2, pytest-8.1.1, pluggy-1.4.0 -- /psi/toolchainconda/envs/qcmb312_pyd1/bin/python3.12
cachedir: .pytest_cache
rootdir: /psi/gits/geomeTRIC
configfile: pytest.ini
plugins: xdist-3.5.0, typeguard-4.2.1
8 workers [7 items]
scheduling tests via LoadScheduling
geometric/tests/test_qcengine.py::test_lif_bsse[cfour-nocp]
geometric/tests/test_qcengine.py::test_lif_bsse[nwchem-cp]
geometric/tests/test_qcengine.py::test_rdkit_simple
geometric/tests/test_qcengine.py::test_lif_bsse[psi4-cp]
geometric/tests/test_qcengine.py::test_lif_bsse[nwchem-nocp]
geometric/tests/test_qcengine.py::test_lif_bsse[psi4-nocp]
geometric/tests/test_qcengine.py::test_lif_bsse[cfour-cp]
[gw0] [ 14%] PASSED geometric/tests/test_qcengine.py::test_rdkit_simple
[gw3] [ 28%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[cfour-nocp]
[gw4] [ 42%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[cfour-cp]
[gw1] [ 57%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[psi4-nocp]
[gw2] [ 71%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[psi4-cp]
[gw5] [ 85%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[nwchem-nocp]
[gw6] [100%] PASSED geometric/tests/test_qcengine.py::test_lif_bsse[nwchem-cp]
=================================================================== warnings summary ===================================================================
/psi/gits/geomeTRIC/geometric/tests/addons.py:51: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
from pkg_resources import parse_version
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
======================================================= 7 passed, 8 warnings in 68.03s (0:01:08) =======================================================
Hi Lori, Thanks a lot for the contribution! Does QCManyBody automate the calls to Psi4, NWChem, Cfour to perform the single-point calculations needed for BSSE and MBE? That sounds very useful. I'm happy for this to become a part of the main branch but I'd like to ensure the tests can run on my local machine before I do that, so we can wait for the right versions of the MolSSI packages to be released first. What do you think?
|
You're welcome, thanks for taking a look! QCManyBody has two interfaces. So, yes, for the high level intf, you feed it a schema instance, and it toddles off to QCEngine and runs all the NWChem, Psi4, etc. gradients in serial for each of the subfragments the job needs, then returns to caller a schema with the summed-up many-body gradient. Or there's a low-level intf that supplies an iterator over needed subsystems/model chems, then you run the jobs, collect energies/gradients into a data structure, and hand that back to qcmanybody to sum up. Example for energies here. Dependencies are numpy and qcelemental. Glad to talk further if this would be useful to you.
Sure, perfectly fine. I should get the next QCManyBody release out today, but QCEngine may be a couple weeks. I'll ping this thread when the tests are actually runable :-) |
There's a project https://github.com/molSSI/QCmanybody for serving up BSSE corrections and MBE truncations. As it's integrated with QCEngine and has a nice schema interface, it's pretty easy to extend to optimizations with geomeTRIC, so here's some proposed changes. It'll require QCManyBody v0.3.0 and QCEngine v0.30.0 (neither of which are minted yet) and any QCEngine program harness that can do ghost atoms (Psi4, NWChem, Cfour known to work; GAMESS cannot).
Glad to answer any questions or make changes.