JW – Possible to keep return_topology kwarg? Otherwise vsite processing is hard.
JW – Backport switch_width bug?
(in chat) – SB – +1 for backport
SB – Also backport ELF10 fix
MT – Slide 11, charge differences significant?
SB – I ran similar scripts to this with small molecule. I found 330/~9000 mols showed charge differences greater than 1e-6. Then I took one of the molecules and looked at it, and recomputed charges 100-1000 times. But that always gave identical charges. Sometimes I’d catch issues on the order of 1e-2. That’s on the order of a small BCC, so I think that’s a significant difference.
MT – I haven’t done this as rigorously. But I’ve seen the same molecule sometimes pass and sometimes fail when running it repeatedly.
SB – Do you have a documented case of this?
MT – Unfortunately no, it was a while ago. I’ll try to isolate one of these cases this week.
SB – This reminds me of other issues like when fragmenter would fragment differently based on atom order (since that led to different conformers, and that led to different electronic structures) .
MT – I don’t want to dismiss the chance that this is a bug in Interchange, but this code is largely calling Toolkit methods, and it will be very hard/out of scope to get to the bottom of this.
SB – I’m not convinced that it will take a super long time. We can get a reproducing case and rerun it a bunch of times, then we can dig in.
General--
Show that charge differences are EITHER:
A bug in 0.10.X
Unavoidably stochastic (root cause is in OE or RD/AT implementation)
Run OE charge assignment for a mol 1000x, for each atom, calculate a charge average, and the deviation. If the deviation is greater that 1e-6, then we can conclude that the issue is stochastic.
SB – Approve
MT – Approve
WBO torsions slide -
MT – WBO interpolated torsion deviations significant? Variation on the order of 1e-5. SB, suggestions?
SB – Let’s do the same thing as the partial charges - Replicate calcs a ton of times, calculate deviation, determine whether the stochasticity is entirely due to OpenEye..
MT – Approve
SB – Approve
Vsites
JW – Should we aim to have the same behavior as before (bugs and all), or fix what we can, but possibly give different energies/geometries
SB – I’d prefer fewer bugs. And I’d like to review tests.
JW – Note that this means we won’t have a reference energy/geometry for vsites.
SB – That’s fine. And it’s OK to keep the wrong atom ordering, but to have fewer bugs.
MT – I can’t do vsites as a “blank slate” with nothing to compare to.
SB – Vsite assignment will make two things: coordinates and parameters. Coordinates can be verified using pen and paper. There are recharge tests that do something similar to this. For parameters, there’s exclusions, charge, and vdw params. Exceptions will be trickier.
JW – I think this may be out of scope.
MT – Operationally, we have two choices:
Compare to current toolkit
Do new unit tests against “absolute truth”
SB – If these tests don’t exist, then I don’t think that the current implementation is sufficient. I’d say that we should either:
Not support vsites in the 0.11.0 release
Satisfactorilly pass deliberately-designed unit tests.
MT – I’d be OK with releasing interchange without vsite support.
MT, SB, JW will meet this week to assess Vsite testing+implementation feasibility in the 0.11.0 release. Then will meet next week to decide on project scope.
SB – I opened a few issues on the interchange regression repo. One on not using ignore_order, another on checking for correct usage of idivf.