Personal updates | IP – Working on the specific details of Topology API refactor. Lots of thinking/planning about the distinction between molecules, topologymolecules, and hierarchy elements (eg residues). We currently are working on one solution that should be possible, but are keeping in mind more general solutions Had meeting with Perses team to gather requirements. Lots of back-and-forth about need for hybrid topology/atom mappings. Working on tests, becoming more specific about desired behavior
MT – Worked entirely on nonbonded stuff. Started in Toolkit, made nonbonded handling documentation PR (SMIRNOFF settings → OpenMM NonbondedForce configuration mapping). It goes pretty far, but doesn’t cover switching function usage, dispersion correction, and what happens if vdW and ES cutoffs are different. Also identified problem where nonperiodic topologies always get NoCutoff nonbondedforce. Trying to split out vdW and ES into two CustomNonbondedForces. But this got really complex. So I’m keeping ES in NonbondedForce (since there’s more support for things like PME), but splitting vdW into its own force. Encountering more difficulty in 1-4 scaling
In System object, trying to get nonbonded stuff to match between engines. Basically expecting to port logic from my open toolkit PR to System later. Also working on OpenMM <--> GROMACS vdW energy equivalence. Currently getting it to agree to 1kcal/5 million atoms. Worked on better mdp file writing/generation.
JW – Got 3 month and 12 month openeye license. The 3 month one is now the openforcefield org GH secret Debugged GH release SHA change.
MT – Distributing on pip would fix this JW – Would our dependencies be available in a sane way from pip? MT – Yes, except OpenMM, so that would need to become a soft dependency LW – I’d be interested to know if we can pull down RDKit from pypi (Generally this seems tricky) IP – The package is listed as rdkit_pypi
Lots of planning about merging Molecule + TopologyMolecule / drawing a line between residues and chains and moleucles
PB – Working on QM theory benchmark and reviewing literature This week, will work with LPW and HJ to get synced with progress and directions Working on sulfonamide valence geometry issue JW – Do we have this fixed, and are figuring out root cause, or is this still not fixed? PB – A30 and A31 were supposed to be close to tetrahedral values (109.5), but from openff-1.0.0 to openff-1.3.0, it gradually decreased. So, we don’t know exactly why this happened, and I’m going to dig into this further so that it doesn’t happen again.
LW – Continuing to build to build polymers from monomers. Currently, working on “if we have monomers joining together with some overlap region, how different are they?”, deciding how to merge/separate parameters for these cases. Since bespokefit has been changing, I’ve been working on refactoring my own codebase while they’re in flux What’s the difference between qcfractal_interface, and qcportal? I’ve found minor API/behavior differences. TG – They’re basically the same, but interface wraps qcportal, so sometimes type checking changes, and sometimes pipes are handled differently.
TG – Vsite position PR is done – Ready for review. Required some bugfixes/new fixes in vdWHandler.create_force – If you go through the molecule API to make vsites, that’s bad, since VirtualSiteHandler should do that. So now, only VirtualSiteHandler makes particles for vsites. JW – This should be safe, since vsites are all indexed AFTER atoms, so the two handlers can operate independently. TG – This isn’t really working currently, so the PR is pretty much necessary MT – This sounds like a nice improvement JW – We’ll pin the 0.9.3 release to merging of TG’s PR, so that he’ll get access to it in a stable release ASAP
Making vsites using the molecule API is horrible and dangerous, and folks should only ever use OFFXML. Currently, vsites in molecules are initialized with vsites with sigma/epsilon/charge_increment values of None, which crash create_openmm_system if they’re not changed. So this PR sets them to 0 by default. TG – In the future, I may need to make vsites more first-class (right now they’re more like 1.5-class) TG – Should we be giving vsites parameters labels/ids? JW + MT – In the object model and the SMIRNOFF spec, they’re optional (General) – Should vsite IDs be enforced to be unique?
TG – We’re going to have trouble with “flattening” the vsites in the toolkit/a system, since many can share a single smirks and slot. MT – It’s much easier to flatten things on a handler-by-handler basis. TG – Currently I’m making a tuple for each with smirks/id/parameters MT – The currently system object has some interfaces for this, but we don’t really have users, so it’d be great to have feedback on this. TG – It’d be great if the toolkit could do this. The function could be something like to_pandas MT – TG and I will have a meeting on this at 11 AM to see if the System object covers/will cover this use case
0.9.3 milestones: Vsite PR merged Switch width PR merged partial charges rounded #917
|