2023-04-14 OpenMM/OpenFF Check-in meeting notes

JW – checking in on python version range - We’re dropping support for 3.8, adding support for 3.11

• PE – We just do what conda forge recommends

JW – telling PE about our annual meeting in case he wants to attend remotely - https://forms.gle/3NE9fndfzPLhg1QJ8 - All OpenFF talks will be recorded and uploaded to youtube, though discussion will only be available live.

• PE – I was invited, can’t attend.

JW – telling PE about our upcoming FF plans – Releasing an update of Sage openff-2.1.0, release candidate out now. Still only for small molecules - Improvements in sulfonamides, somewhat aromatic planarish nitrogens (should be handled better by improper terms refit), other small functional group fixes.

JW – telling PE about OpenFE’s PDB reader https://github.com/OpenFreeEnergy/pdbinf - We’re currently making an element+conect → OFFMol reader, which doesn’t look at residue/atom name, just chemistry.

• PE – Note that nonstandard atoms in PDBs will be a disaster - No guarantee of true element or CONECT. Also pdbx/mmcif will carry in many of the sins of PDB, since folks will have just converted those directly from problematic PDB. Also even pdbx labels/columns are sometimes duplicative/inconsistent, even when taken from authoritative sources.

• JW – Thanks for the warning - We have an “error fast” philosophy - Hopefully we can just error out ASAP when things seem funny.

• PE – Even this will be tricky. I appreciate what the PDBx/mmCIF team is trying to do and it fixed a lot of the problems in PDB files, but introduced a lot of new ones.

JW – We’d love a cude-less OMM conda package but I know that comes with a big maintenance burden and conda packaging is not something you deal with

• PE – Thinking about a pypi version that will avoid need for cuda. Also conda-forge people talked about splitting cudatoolkits into smaller libraries, which could take the size of required download to a small fraction of the current size. vNVidia already provides it in the split up form, it’s just not on conda-forge.

• JW – Hopefully they’re feeling the pain from large egress costs and this is becoming a priority for them.

• PE – IT’s not clear that the same people are paying this as can influence what the engineers work on.

• MT – If it hasn’t bothered them until now, then it may not ever.

• PE – And they still don’t have cuda12.

• JW – Could be interesting to make a push to contract quansight to do this. Though it may require lawyer-time instead of engineer time.

• MT – They may have the resources to do this.

• PE – AMD hired people to move implementations from opencl to HIP, which goes way faster. But conda-forge doesn’t have interest in this unless someone else does most of the work. AMD HIP packages are on pypi and apt, just not conda-forge. C-F’s walled garden approach makes this higher friction that other packaging ecosystems.

• MT – It’s also hard to delineate between system level packages and python packages. People who use venvs and stuff often have to do some finagling.

• PE – Yeah, it’s too bad that we can’t put one line in our build script to pull in a single non-cf package.