Individual Updates | CC Met with DD and PB to talk about dipeptide torsiondrives on QCA. The progress was showing a lot of “bursting” behavior, as we error cycled, and lots of errors would pop up from certain hosts. The main host that did this was on PRP. There were also other jobs that failed due to bad geometry. This was probably due to a sage pre-optimization step, where a bogus geometry is created. Because we know which molecules in this dataset make bad geometries, we can set up a sort of unit test for a step that detects these bad geometries. JW – Sometimes we see bonds breaking in QM optimizaiton, or if there are technical issues in MM optimization then atom indexing can get scrambled and appear to be highly stretched bonds. CC – This mostly happens with AAs with large sidechains, when you’re driving backbone torsions, and they run into each other and cause tangles/steric clashes. JW – Maybe a useful breadcrumb for when we’ve done this before: | Github link macro |
|---|
| link | https://github.com/openforcefield/openff-benchmark/blob/65a3519f18cb587622471a6bda6d58d9e39cd1d2/openff/benchmark/geometry_optimizations/compute.py#L664-L685 |
|---|
|
Met with JW and DN to set up a formal process for decisionmaking for protein FF project. Borrowed structure form interchange and F@H project plans. Decided that we’ll only make binding decisions in biopolymer FF call. Planning for approvers to be myself, MG, and MS. Continuing to put together a plan for benchmarking the protein FF. I heard from JC that the benchmark that we want to do doesn’t require the new F@H interface, and can be handled by existing F@H machinery. So I’ll get in contact with Sukrit to begin verifying that this will work. I’ll talk about this course of action at this week’s protein FF call to gain agreement on pursuing it.
MT Largely spent the week getting deep into hard problems. SMIRNOFF-EP 00005 progressed. This will change the SMIRNOFFs spec, but it won’t change how you interact with fFs/software (basically the software behavior was non-spec before, we’re updating the spec to reflect what the software does). The core issue is when PME electrostatics are requeste by theFF, but the topology is not periodic. Added non-OpenEye runs for Interchange CI. Found new failures. The core of the issue is that a 0-step calculation in sander DOES update the coordinates because it satisfies distance constraints. Poked around in some runtime performance issues, some in toolkit, some in interchange. A few in the Toolkit, one thing to keep in mind is, in openmm units, if you say distance=4*nanometer, that’s a few microseconds, but in pint it’s a few milliseconds. This rears its head in something like fromn_openeye, when you load multi-conformer molecules. I’ve opened a PR to fix a performance regression in from_openeye, but I suspect that there are other places where this issue makes a significant performance problem. If you run into slow runtime in other areas this is a good place to look. Someone made a gromacs recipe on conda-forge. And it works well. So be aware that envs that need gromacs and search the bioconda and conda-forge channels will now pull gromacs from conda-forge. Be aware that there’s MPI and non-MPI builds, and if you get the former then the executable is called gmx_mpi, but otherwise it’s gmx. Weeks ago I reached a “done” state for regression testing single-molecule energies for the interchange adoption project. This was achieved using the candidate toolkit with use_interchange={true,false}, but when I actually test a candidate build against a completely separate environment with 0.10.X, I see differences in the AM1BCC charges. To get the entire dataset to pass I have to allow tolerance up to 1e-3.
DN DD PB JW – Vsite-palooza. Making geometry and energy test cases for a few molecules and vsite FFs. Visual inspection revealed/confirmed problems. Opened bug reports. Will send notebook to MT today. EP 00005b review - Seems acceptable, will update text today. “FFs on nodes” discussion with DD.
|