You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first (and most alarming looking) failure, the scf ene: computed value (-1.7055776) does not match (-1.6561385) has to do with nwchem versions. The root that nwc finds varies btwn versions, so it fails for me locally, too, but passes with the c-f version in CI. Not a great test case, I admit, but nothing to be concerned about.
The geometric or rdkit fails look like error msg formatting of some kind. Those would need investigation.
Thanks for the update. Most or all are gcp errors? Is there any chance it's detecting the wrong gcp -- there's a system one (https://manpages.ubuntu.com/manpages/trusty/man1/gcp.1.html). Of the proper "geometric counter poise" project, there's two implementations -- the original with executable gcp and the newer preferred one with executable mctc-gcp. Does that provide any clues as to what's going wrong?
Now with the mctc-gcpexecutable there are 2 failures. The first failure was a runaway process that I killed after many hours. The second failure is a regular test failure.
Is the "regular test failure" the nwchem one with scf ene: computed value (-1.7055776) does not match (-1.6561385) to atol=3e-06 by difference (-0.0494391).? That one I know about -- the SCF root that nwchem finds differs by nwchem version.
test_hf_energy_module[hf uhf ae: psi4-dz-ene0] hangs for a very long time so I have to kill it
the ``test_atom_labels[nwchem] failure happens (scf ene: computed value (-1.7055776) does not match (-1.6561385) to atol=3e-06 by difference (-0.0494391).```)
the second (nwchem) one is the one I was thinking of -- the calculation can simply land on either of two roots. I get it "wrong" locally, too, b/c I leave the repo set to the answer that our CI nwc yields. Maybe I should make it pass for either correct value ...
========================================================================================= FAILURES ==========================================================================================
_____________________________________________________________________________________ test_dftd3_error ______________________________________________________________________________________
@using("dftd3")
def test_dftd3_error():
json_data = {
"molecule": qcng.get_molecule("eneyne"),
"driver": "energy",
"model": {"method": "b3lyp-d3(bj)"},
"keywords": {},
}
# Test driver
with pytest.raises(qcng.exceptions.InputError) as exc:
input_data = json_data.copy()
input_data["driver"] = "properties"
ret = qcng.compute(input_data, "dftd3", raise_error=True)
> assert "Driver properties not implemented" in str(exc.value)
E AssertionError: assert 'Driver properties not implemented' in 'Driver DriverEnum.properties not implemented for DFTD3.'
E + where 'Driver DriverEnum.properties not implemented for DFTD3.' = str(InputError('Driver DriverEnum.properties not implemented for DFTD3.'))
E + where InputError('Driver DriverEnum.properties not implemented for DFTD3.') = <ExceptionInfo InputError('Driver DriverEnum.properties not implemented for DFTD3.') tblen=4>.value
qcengine/programs/tests/test_dftd3_mp2d.py:47: AssertionError
===================================================================================== warnings summary ======================================================================================
I think a change I made to #465 will fix this error.
> assert "Driver properties not implemented" in str(exc.value)
E AssertionError: assert 'Driver properties not implemented' in 'Driver DriverEnum.properties not implemented for DFTD3.'
E + where 'Driver DriverEnum.properties not implemented for DFTD3.' = str(InputError('Driver DriverEnum.properties not implemented for DFTD3.'))
E + where InputError('Driver DriverEnum.properties not implemented for DFTD3.') = <ExceptionInfo InputError('Driver DriverEnum.properties not implemented for DFTD3.') tblen=4>.value
Activity
loriab commentedon Oct 10, 2022
The first (and most alarming looking) failure, the
scf ene: computed value (-1.7055776) does not match (-1.6561385)has to do with nwchem versions. The root that nwc finds varies btwn versions, so it fails for me locally, too, but passes with the c-f version in CI. Not a great test case, I admit, but nothing to be concerned about.The geometric or rdkit fails look like error msg formatting of some kind. Those would need investigation.
Thanks for report.
yurivict commentedon Nov 14, 2022
For the version 0.25.0 one test fails: qcengine-test-failures.txt
yurivict commentedon Aug 3, 2023
0.27.0 has 31 test failures: qcengine-0.27.0-tests.log
loriab commentedon Aug 4, 2023
Thanks for the update. Most or all are
gcperrors? Is there any chance it's detecting the wrong gcp -- there's a system one (https://manpages.ubuntu.com/manpages/trusty/man1/gcp.1.html). Of the proper "geometric counter poise" project, there's two implementations -- the original with executablegcpand the newer preferred one with executablemctc-gcp. Does that provide any clues as to what's going wrong?yurivict commentedon Aug 6, 2023
Yes, the gcp executable was unrelated.
Now with the
mctc-gcpexecutable there are 2 failures. The first failure was a runaway process that I killed after many hours. The second failure is a regular test failure.log
loriab commentedon Aug 6, 2023
Is the "regular test failure" the nwchem one with
scf ene: computed value (-1.7055776) does not match (-1.6561385) to atol=3e-06 by difference (-0.0494391).? That one I know about -- the SCF root that nwchem finds differs by nwchem version.yurivict commentedon Aug 7, 2023
Now I am rerunning the tests and
test_hf_energy_module[hf uhf ae: psi4-dz-ene0]hangs for a very long time so I have to kill itfailure happens (scf ene: computed value (-1.7055776) does not match (-1.6561385) to atol=3e-06 by difference (-0.0494391).```)loriab commentedon Aug 7, 2023
I don't know about the first (psi4) one -- it's pretty quick for me.
the second (nwchem) one is the one I was thinking of -- the calculation can simply land on either of two roots. I get it "wrong" locally, too, b/c I leave the repo set to the answer that our CI nwc yields. Maybe I should make it pass for either correct value ...
yurivict commentedon Jun 26, 2024
0.30.0 has 1 test failure:
Python-3.11
FreeBSD 14.1
loriab commentedon Jan 14, 2025
I think a change I made to #465 will fix this error.