Protein-ligand (+water) system vs. ParmEd | OpenEye is on OpenMM 7.5x line The protein HJ is using errors out with missing torsions using the toolkit and bonds using Interchange Several hundred or thousand of these failures, on the protein We think this is a problem with the ff14SB OFFXML file
HJ will share an OEB file of the protein and associated script JW – Seems to be a stereochemistry issue - the OEMol has formal charge and bond orders, but the OFFXML also expects defined graph stereochemistry. So the options would be: Perceive stereo from 3D BEFORE passing to OFF toolkit Having OFF Toolkit perceive stereo from 3D in from_openeye Updating the OFFXML file to not expect specific stereo (dangerous?)
HJ – We usually set stereo to calculate the partial charges for small molecules, so it’s possible for us to have it defined before passing a molecule to the OFF toolkit. HJ – I have a nonintegralchargesum error when I ran create_openmm_system (but not Interchange.from_smirnoff) - It goes out to a lot of decimal places 5.629856489598751 when 6 was expected
JW – How would this be possible? Librarycharges are only defined to 4 decimal places, then some of them have x.xxx99999999 from floating point error. So I’m not sure how they could sum up to have that total value. sum([c.m for c in interchange['Electrostatics'].get_charges().values()]) The issue is that the initial script was using charge_from_molecules = offprotein, and the partial charges on the oemol were nonzero (and summed to 5.6….)
HJ – Which tests have you done on proteins+interchange? MT – Limited validation of Interchange and protein FF comparison - Hard to say what goalposts are, since there are a ton of other settings in a simulation enegine, and it’s hard to get them JW – HJ – If I do (protein-from-X and ligand-from-Y combined using Z) versus (protein-from-X2 and ligand-from-Y2 combined using Z2) should I get the same energy? JW – Would recommend comparing JW+MT – The complicated part will be if they DISagree, there’s like a 2/3rd chance it’s an Interchange bug, but a 1/3rd chance it’s a ParmEd bug. MT – Probably. I’d caution against using OpenMM’s AMBER parameter assignment as the reference, since tleap/ambertools may assign different parameters than OpenMM, but tleap/ambertools are the reference implementation. My confidence ranking for accuracy is Abmertools > OpenMM > ParmEd. HJ – Suggestions for better benchmarks to do? (General) – There is no “standard” dataset for system combination unfortunately. It’s probably best if HJ does the tests described above and, if we’re lucky, we’ll get the same energies out. And if not, at our next meeting we can work on teasing apart the energy differences.
|