Resolve #1842 by setting OMP_NUM_THREADS=2 in toolkit showcase

[j-wags]

• Resolves The toolkit showcase stochastically fails with OMP_NUM_THREADS=1 and AmberToolsToolkitWrapper #1842 (doesn't solve the issue that certain combinations of molecule + n_cores + rdkit version + ambertools version leads to something going wrong in sqm, but at least gets examples CI running for another few months until we can replace this whole stack with NAGL)
• Add tests
• Update docstrings/documentation, if applicable
• Lint codebase
• Update changelog

[codecov]

Codecov Report

Merging #1846 (629a65d) into main (7c22c1e) will decrease coverage by 0.02%.
Report is 5 commits behind head on main.
The diff coverage is n/a.

Additional details and impacted files

[j-wags]

Oh goodness, the rabbit hole goes deeper.

[j-wags]

My current level of confusion.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[j-wags]

The original error was "charge assignment fails in sqm in linux/rdkit CI runs with the original atom ordering of the ligand and OMP_NUM_THREADS=1". @Yoshanuikabundi also told me that he was also able to reproduce this locally on his linux desktop.

I've tried reproducing this error in CI in this PR, locally on my M1 mac, and in a linux/amd64 docker container on the same mac. The only sqm failures I've seen are in macos/rdkit CI builds on this PR:

• FAILED: reorder the ligand atoms
• PASSED: running identical CI again
• FAILED: the same as above, but also forced OMP_NUM_THREADS=1
• FAILED: running identical CI again
• PASSED: resetting the ligand atom order and keeping OMP_NUM_THREADS=1

(note that the failures in the openff-docs builds were linux/rdkit, NOT the macos/rdkit ones that I'm getting here)

I think this means the error is stochastic and may not actually be based on atom ordering or OS.

I'm toying with the idea of having the AmberTools charge assignment pathway generate two conformers and try the second one if the first fails. On one hand, the behavior change would seem acceptable here, since it changes a random error into a valid outcome. On the other, it takes a relatively long time to fail on one conformer (~5-10 mins) and if there were a legitimate problem with the input then this change would double the the amount of time before the user got an error message.

So, I'm unsure here. I'll talk with @Yoshanuikabundi on Monday to determine if there's some way to more consistently reproduce the error so we can have a better grasp on options moving forward.

[mattwthompson]

If the number of threads/cores/solar flares is important, it would be useful to work that into the error message. The current failures are heavily obfuscated by the ValueError that eventually gets to the user