openff-toolkit: Antechamber/sqm fails on about 1% of input
In the first 300 molecules of our test_molecule database, antechamber/sqm has failed three times. These are used in calculating partial charges using the bcc and mul charge methods.
ZINC00335972 ZINC35326424 ZINC00160396
Both failures had C#N motifs. However, C#N motifs are not unique to the failure, as ZINC28286664 (which has one) was processed successfully. This bug may have something to do with the C#N motifs being connected to an aromatic system.
Larger and smaller molecules were processed successfully, as were singly and doubly charged molecules.
OE QuacPac did not have a problem calculating partial charges for the same molecules.
The error message in sqm.out was similar in each case:
QMMM: Unable to achieve self consistency to the tolerances specified
QMMM: No convergence in SCF after 1000 steps.
QMMM: E = -0.4629E+06 DeltaE = 0.5704E-08 DeltaP = 0.9306E-05
QMMM: Smallest DeltaE = 0.3434E-08 DeltaP = 0.1597E-04 Step = 986
Possible solutions:
- Check the protonation/geometry by eye to see if the problem is in file conversion
- Loosen the convergence criteria or increase the number of iterations allowed in sqm
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 29 (29 by maintainers)
I think this issue has been swept away by the currents of time. All the conda-forge ambertools that can be pulled in by our conda recipe will be version 19 or newer, so this should be a non-issue from now on.
We do have an AmberTools 19 (
ambertools19.9) package built via conda-forge here, but it’s currently only available forlinux: https://anaconda.org/conda-forge/ambertools/files Here’s the feedstock: https://github.com/conda-forge/ambertools-feedstockThe current issue is that it doesn’t yet build on
osxfor unknown reasons. There is an open PR to add this, so it may be valuable to see if we can get this to work, since it would drastically simplify our ability to stay up to date with AmberTools: When AmberTools releases a new patch update, all that’s required is to bump this line and the build logic will automatically apply the appropriate patch level, where the versioning scheme here is{major_release}.{patch_level}.Totally agree—right now, we just offer an open source alternative (even if it fails some fraction of the time) and move on until we get the resources to provide a more robust solution. But I think retreating from the principle that the force field uniquely encodes everything required to compute the energies would be a major mistake.
I agree with you on this, @jchodera :
Key words there being “ultimately” and “quantum chemist”, i.e., not necessarily right now, and not us. 😃
It’s not Jeff’s job to deal with this. And, whether we invest Consortium resources in trying to create a good open quantum solution would be something we’d have to sort out with the board.
That said, after discussions yesterday I think it seems likely Michael Schauperl will end up creating a good open solution for this, probably in collaboration with Lee-Ping’s group and with support from Jeff.
I disagree on this, @davidlmobley. Anything that affects force field predictions must be part of the force field definition, otherwise accuracy will be highly variable for users. We need an open, reliable way to assign partial charges. We will ultimately need to pair with a quantum chemist who can deliver this.