Closed Yoshanuikabundi closed 5 months ago
Seems to be re-emergence of #1767. Here @Yoshanuikabundi has identified that the issue only occurs when running with one core.
Ok I systematically ran ten charge assignments under the conditions that I believed led to the crash. 9 of them failed and 1 succeeded. So I think there is a stochastic element to the problem.
I also experimented with changing atom ordering, and specifying the conformers used to calculate charges. I had an atom ordering that worked every time, and an atom ordering that failed 9 times out of 10, so I generated a conformer for each ordering and then tried each conformer on the opposite ordering with the use_conformers
argument (after remapping the conformer). The conformers looked very similar and didn't have anything obviously wrong with them - the main difference was a 180 degree rotation of a hydroxyl group. Moreover, changing the conformer to one generated from the opposite ordering didn't change the results. I was really surprised to see this, but it seems to be the atom ordering itself and not the conformation.
Thanks for looking deeper into this.
Decisive morning-jeff is looking at this and sees two options:
I'm strongly in favor of the latter. I'll change the issue name to reflect this. @Yoshanuikabundi could you push the good atom ordering to https://github.com/openforcefield/openff-toolkit/pull/1846
Describe the bug Assigning charges with AmberTools can fail when
OMP_NUM_THREADS
is set to 1 (but not other values or when it is unset). This only happens for some inputs - for instance, simply changing the atom indexing for the test molecule can fix the issue.I found this trying to fix the OpenFF Docs cookbook - see https://github.com/openforcefield/openff-docs/actions/runs/8342106212/job/22829552667#step:7:249
To Reproduce
Output
Output for the above code is:
See also https://github.com/openforcefield/openff-docs/actions/runs/8342106212/job/22829552667#step:7:249
Computing environment (please complete the following information):
Output of running `conda list`
Additional context This is probably an upstream issue but I'm documenting it here anyway.