Individual updates | DN Just heard that AbbVie is renewing this year  DM asked me to prepare some text in response to Kaushik’s justification for BMS to switch to supporting OpenFE. I think I’m doing well on this - Writing on open science and how it depends on long-term support for sustainability, and innovation and how it relates to progress and benefits.
MT Made 0.4.0 release of Evaluator, the “works with new stuff” release ensure_quantity helper function added to openff-units >=0.1.8
Some iterations on openff-models with OpenFE Beginning to prep for Interchange workshop Started to work on fixing some corner cases in GROMACS export, got distracted partway through
CC Made progress on parameter fits in ForceBalance - Pretty happy with the input file setup. Working on translating PB’s slurm scripts into PBS scripts so I can run fits on UCSD cluster. If this is hard, I’ll just ask DM to get me set up on UCI cluster. JW – Do we fit FFs using FB directly, or using bespokefit? PB – We call FB directly, but could use BespokeFit to make the inputs. One big thing with bespokefit is that you can run staged optimizations (like, many steps of nonbonded opt, then many steps of valence opt), and also you can use bespokefit to invoke QCSubmit to prepare FB input. CC – Yeah, so we’re not using BespokeFit as the driver for the whole process, but we call BespokeFit a lot to prepare the input files. PB – We used to have separate scripts for downloading opt data and torsiondrive data and preparing FB inputs, but now we can call submodules of bespokefit to do that consistently.
Deadline for submitting abstract for BPS is Oct 1. I’m getting this ready, will ask JW and MT for review.
JW – Radicals discussion - MT has basically convinced me that we shouldn’t handle them, just some technical cleanups now. MT – The OFFTK behavior around radicals is borderline ambiguous. We don’t have code or tests that explicitly handle radicals. So we can later say that we support radicals, but only once we discuss whether we WANT to support radicals and whether our FFs are trained on radicals. PB – Last week I was doing some stuff with OpenBabel PDBs and reading it into RDKit, and I was seeing some mangling like this as well. JW – PDB reading is in a tough jurisdiction - If OpenFF tries to provide stable PDB reading functionality, we risk getting drowned in a swamp of support. But obviously there’s a huge demand for a PDB reader, since we’ve been taking about this for years. MT – OpenBabel’s PDB reading functionality keeps me up at night. PB – Even when I provide OpenBabel a SMILES it often gets mangled.
OFFTK #1401 - Seems to be a version issue Ries/Gowers PDB handling chat - We’re basically on the same page (we all want formal charges), plan is to make a standalone repo with a fork of OpenMM’s PDBReader. Announced followup workshops. Agonized over communication strategy, think this model should work for future years. Looking to do lots of Bespoke UX improvement - Install instructions WRT psi4, FAQ/common error handling PB – The QCA psi4 workers env file should have a stable env solution MT – Big issue is installing psi4 into an existing env with conda-forge at the highest priority - Even Lori says this is the hardest case of install. I recommended laying out explicit yamls for users and recommending installing from that. But users hate making multiple envs. So while a commandline command could be made equivalent to a yaml-based env creation, I’d prefer the tighter control of a yaml-based install. JW – I’d really prefer to keep it in a conda create command - yamls are opaque to users and would be inconsistent with our other package installs, and will require a different type of testing/maintenance. MT – Users can always open yamls to see what’s inside, and we’re already not “maintaining” install instructions for other packages - Our own CI is installing from yamls. Right now we effectively “ship” our install instructions in untested markdown files and we don’t know if they’re broken until someone like Arjun uses their time to find a problem and then write in. PB – I like the single-line commands that we offer for installation - This was really impressive when I first started. So either a single conda create or conda env create solution would be great here. CC – I like the idea of the yaml approach to support different environments with/without optional dependencies, since you can run diff on them JW – Could just bundle the yaml in the GH repo. If we used the same yaml as the CIs then it would be seamless to maintain, but users might get some extra test deps. MT – Shipping CI yamls to users would seem to make things a bit fragile - If we wanted to test something that we don’t ship to users, this would restrict our ability to do that. PB – We’re kinda advocating for xtb in bespokefit. BespokeFit uses QCEngine, and there’s a known bug where xtb doesn’t take n_cores form QCEngine. So we should follow up on that. | Github link macro |
|---|
| link | https://github.com/MolSSI/QCEngine/issues/355 |
|---|
|
JW – For some reason I’d thought that XTB scales very poorly with n_cores PB – I think it’s just that the python interface doesn’t expose the option for n_cores. I rediscovered this last week.
JW will write up a message for AMey about tomorrow’s F@H meeting.
PB Reviewing SPICE draft and adding minor edits. Spent a bit of time on an external code challenge. Meetings and follow ups. Started second round of revisions to Sage manuscript. Following discussion with BSwope, I’m going to look into adding new FB targets that explicitly aim to get conformer energy ranking correct. DN – During ff-release meeting, you seemed to have a lot of answers for BSwope’s questions/requests - Congratulaitons on being so up-to-date about our FF fitting and the deeper details.
|