Closed awvwgk closed 2 years ago
Any idea why conda is solving for dftd3-python 0.4.1 rather than the latest? Mamba does find the correct version just fine.
Probably just have to set an explicit version requirement.
Edit: Looks like the opt-dispersion.yaml
environment does not solve with mamba under the constraints in the CI:
❯ mamba env create -n qcng-test --file test.yaml
psi4/label/dev/noarch [====================] (00m:00s) Done
psi4/label/dev/linux-64 [====================] (00m:00s) Done
conda-forge/noarch [====================] (00m:02s) Done
conda-forge/linux-64 [====================] (00m:06s) Done
Looking for: ['psi4', 'blas=[build=mkl]', 'intel-openmp!=2019.5', 'rdkit', 'dftd3==3.2.1', "dftd3-python[version='>=0.5.1']", 'dftd4-python', "mp2d[version='>=1.1']", 'gcp', 'geometric', 'optking', 'pymdi', 'python', 'pyyaml', 'py-cpuinfo', 'psutil', "qcelemental[version='>=0.24.0']", "pydantic[version='>=1.0.0']", 'msgpack-python', 'pytest', 'pytest-cov', 'codecov', 'pip', 'python=3.8']
Encountered problems while solving:
- nothing provides requested intel-openmp !=2019.5
- nothing provides gcc-5-mp needed by psi4-1.2a1.dev419+809f363-py36_0
❯ cat test.yaml
name: qcng-test
channels:
- psi4/label/dev
- conda-forge
dependencies:
- psi4
- blas=*=mkl
- intel-openmp!=2019.5
- rdkit
- dftd3 3.2.1
- dftd3-python >=0.5.1
- dftd4-python
- mp2d >=1.1
- gcp
- geometric
- optking
- pymdi
- python
- pyyaml
- py-cpuinfo
- psutil
- qcelemental >=0.24.0
- pydantic>=1.0.0
- msgpack-python
- pytest
- pytest-cov
- codecov
- pip
- pip:
- pyberny
- python=3.8
At first read-through, this lgtm. Thanks very much for working on this! I am hopefully finishing up libint2 work soon. Then shifting psi4 to the new d3 and gcp implementations is next on my agenda.
Friendly bump, what is necessary to move this patch forward?
lgtm, thank you!
Fwiw, I don't find any interference wrt the older implementations in downstream testing so far. Would you like to rebase so correct CI lanes run, or would you like me to rebase and force-push to your branch?
Friendly bump, what is necessary to move this patch forward?
Apologies, the Psi4 release got busy. I held out hope until the beginning of May that we could transition to the new harnesses, but I didn't make it.
btw, if you do the rebase, be aware I added this to get tests to pass https://github.com/MolSSI/QCEngine/blob/master/devtools/conda-envs/opt-disp.yaml#L14 . Possibly it interferes with this PR.
Will have to check, I had the idea to update the CODATA version in all our programs, however the test accuracy is lower than the change in conversion factors...
From what I remember differences were quite small. Maybe physconst change effect on the geometry -- I don't remember if it originates in angstroms.
Small enough to trip off the contributed tests unfortunately, I'll have to check the reference values for DFT-D3 and DFT-D4 to make sure the CODATA change doesn't affect any energy / gradient in the last digits.
Small enough to trip off the contributed tests unfortunately, I'll have to check the reference values for DFT-D3 and DFT-D4 to make sure the CODATA change doesn't affect any energy / gradient in the last digits.
Any suggestions on solving the test failure? Do reference results or physconst need adjusting here?
Any suggestions on solving the test failure? Do reference results or physconst need adjusting here?
I need to update the reference results, which is quite unfortunate.
Has been a while since I looked last into this patch, currently have a couple of other projects I want to move forward now that my only have three months of my PhD time in Bonn left. Hopefully I'll come back to this one soon.
I need to update the reference results, which is quite unfortunate.
Has been a while since I looked last into this patch, currently have a couple of other projects I want to move forward now that my only have three months of my PhD time in Bonn left. Hopefully I'll come back to this one soon.
Understood -- finishing up definitely takes priority.
If it's a matter of reference values, not correctness, would it be reasonable if I loosened the checks and filed an issue to be revisited later? Or was it contributions from physconst vs. correctness that you wanted to check up on first?
Loosening the thresholds is an option.
Closes #341
Description
Implement harness for DFT-D3 Python API with native QCSchema support. Allows access to the parameter database and adds those entries to the definitions in the dispersion resources.
Changelog description
Implement harness for DFT-D3 Python API
Status