| General announcements IP Worked on loading metadata in Molecule.from_pdb, worked with JW to do some API updates. Merged PR into topology feature branch. This week, I’ll focus on using Molecule.from_pdb in Perses, and will write tests and look for edge cases with PDB metadata loading.
CC With LW’s help, I was able to start getting librarycharges for disulfide linkages. The general method of this is to use a 5-mer where the central residue varies. When the center is CYX, I attach it to a VCV peptide to complete the valence/provide the atomic environment. This is going into the workflow and seems to be going well. Writing intro for LiveCOMS review. That will be my main focus this week.
MT Mostly worked on getting intercfhange working with new refactor. My medium-term goalpost is getting ParmEd out of toolkit examples. In general this works OK but we need to determine a bit more about how much we the user to have access to/what the API looks like (things like how to manage positions). I’m kinda concerned about stuff like loading a PDB with multiple molecules, some of which are proteins, others are small molecules. Right now the only option is to load each one separately and combine them. But in the future we’ll probably want to support reading in a bunch of components. IP – I’d encourage users to split components by themselves. It could get complex quickly. SB – Maybe the general idea of “loading a box that’s already been built” is something to pursue. A lot of workflows will dump this out, and it’d be good to support loading this. IP – In the Perses world, we load the protein as a pdb, and the other components as sdf. JW – SB – I wouldn’t focus on PDB specifically. So it’s ok to not support “here’s my world as PDB”, but we shoudl offer SOME pathway of loading “here’s my world as X format”. JW – Agree MT – Maybe Topology.from_json? SB – Could do that, but would need to come up with the spec for the json.
MT – What’s our plan for loading multiple FFs? Do we make a single mega-forcefield and apply it to every component? Or do we parameterize different compoennts separately and combine them after system creation? JW – My understanding is the former (mega-forcefield) approach SB – Right now, if someone tried to override Sage to use TIP4P, mayhem would ensue from clashing parameters. But the current state IS to have mega-forcefields that are fully self-consistent and can apply to every component in a topology.
SB – Re: Combining systems – Can the same component be added to an interchange multiple times? Like, for water? MT – Right now we try to have the toolkit handle that. I don’t think that’s a critical thing for interchange to handle. We will want to think about API points in other packages that add solvent+ions. JW – Can work on this this week – I think the OpenMM PDBFile class has nice tools for this, and ti sho0uld plug into our infrastructure wekk. SB – Mostly thinking about this in the context of duplicated water/ethanol/methanol parameters. MT – A lot of deduplication should be implicit in Interchange data structure. Some complexity with figuring out positions. SB – Interchange shouldn’t worry too much about positions – other tools can do that. I was just curious since I’ve been working with GROMACS last week, where the user experience is very different from OpenMM, and I was wondering where interchange is going to be on that spectrum. MT – Agree that positions shouldn’t be first-class in interchange. Most workflows should work just fine without coordinates. MT – Parameter deduplication should be coming as the topology JW – Just a note – New Topology won’t default to know which molecules are chemically identical. There will be a method to group them, but by default all mjolsecules are assumed to be be different.
Hitting some technical blockers, that’s nothing too new. Kept looking into psi4-on-conda-forge, nothing new to report Got “full stack” tests running → testing against both stable and dev versions of other packages. Had just gotten this running at the end of last week, will keep working on it.
PB Mostly wbo, and some general fits, and benchmarking fits. JW – Still having the same problems as before, or hitting new parameters? PB – Still doing simple biaryl fits for central torsion. Things look good as long as there aren’t ortho substituents. Not sure about use in mainline FFs because of computational cost w/ AmberTools JW – Since we’ll almost always need to do partial charge assignment, maybe we could make that always generate wiberg bond orders in the same operation SB – The WBO influence of a lot of torsions doesn’t seem super large. It’s not clear that it’ll be worth the computational cost/infrastructure headaches to get in. JW – Excited to see how this works with pyrimidal N stereo – This is a chemical preception problema t the moment.
JW – Merged Molecule.from_pdb → Lots of monkey patching at the end, will contact RCSB. Loads 11/13 of DHahn’s protein ligand benchmarks set (though it should fail on my of them due to having multiple chains). Fixed performance regression in topology branch Looking into chemical representation issue wrt espaloma Polished bespoke blog post Should I make a conda package for the topology branch?
SB – YANK/OpenMMTools/OpenMM issue → When you use Yank+OpenMMTools+OMM7.6 with CUDA, you get totally borked energies. This doesn’t crash, it returns totally wrong energies. This is something really subtle and I don’t know what the root issue.
|