|
|---|
|
MB, IA : protein-ligand-benchmark update (protein-ligand-benchmark#52):
IA – Meeting with openFE board recently - Board is concerned that we’re moving away from historical benchmarks. They’re concerned that we’re losing the ability to compare to how things were before. I told them that many of the structures before were unuable. They said that some of the new structures didn’t have minimizations that would finish in either gromacs or openmm. JC – Some of the ligands were dropped (especially from the janssen sets) because they had large divergences in the common scaffold. IA – By “minimzation problems”, I’m referring to PLB issue #24. In that, there were clashes in the initial dataset, and the discussion indicated that they’re resolved by minimization. BNut now they’re concerned that the new sets won’t be …. JC – I’d point them to the FE best practices paper and indicate that we’re applying those recommendations. These are often cases where the crystallographic conditions conflict with the assay considtion, or where the ligand can’t be docked in a reasonably confident pose. MB – That’s an accurate and consistent view of the issues we’re having. I think this is a reasonable thing to drop from the systems, because htese issues aren’t related to the free energy method, they’re related tot eh preparation of the systems. The other things that are causing the ligands to drop are different definitions of the core.
DD – JC, are we talking about how the benchmarking paper defined ebnchmrking vs. validation? Or the setup paper? JC – The…. DD – It sounds like the board needs to distinguish between validationa nd benchmarking. JC – We may need to clarify this difference, and point out which sets are which and what goals we have. But I think the reponse to the board begins with the papers.
IA – That covers one part of it. The other part is that there seems to be a problem with the openmm minimizer. The board is also very concerned with reverse compatibility/comparability to the pmx-based benchmarks. JC – Could we run this on orion? MB – … JC – I think the board wants to see a few things run using the old systems. OpenEye has internally curated systems that they run. They may want to see… DD – I worked with David Hahn and Lorenzo ~one year ago to reproduce the pmx benchmarks, and I think it will be very difficult to reproduce it. I was unable to get it working. I think a lot of the stuff was manually handled and the code was on a fork of PMX. JC – Agree that we shouldn’t try to reproduce the old calcs. IA – I think we want to show that, if we’re trying to convince industry people who are using pmx to switch to something else, we should show that we get comparable results. So they want evidence to show that they can switch. DD – How are they using pmx at the moment? We’ve had a lot of trouble with it. IA – I don’t know. They want to be convinced that the results aren’t getting worse. DD – Would the orion path even satisfy them? IT’s not clear that it will. IA – I think it would satisfy them. It’s largely pmx with fixes. JC – Yeah, it’s basically an automated pmx with improvements and an openmm minimization. DD – IA, does this satisfy your needs? IA – I’d love to pursue the orion idea. JC will connect IA and MB with CBayly and GCalabro, and we can run some systems that we share using both types of preparation and both FE workflows (4 sets of calcs)
JW – OpenFF had previously talked about the risk of losing the “science” content of the set. So if there’s important “quality” lost then openFF will be with you in needing to prepare it again with more “science” content from the original. DD – What’s remaining for PLB #52? IA – I think we should squash-merge it immediately and continue work in a new PR DD – I may have found some new clashes. I can work with IA and optionally MB MB – Re: large files. Because I ahd to manually prepare systems with different conditions, the docking grid files are pretty large (~130 MB a piece). JC – Had we agreed that the docking grid generation input scripts are sufficient? We could still upload the grids, but keep them out of the git tree. MB – Will do. I’ll upload the grid gen scripts to the git tree, and will keep the docking grids separate and upload them as a zip. I have the commit to remove the docking grids staged so I’ll push that momentarily. DD – Great, and IA and I will take it from there.
|
|
|
|
IA – Some OMSF folks are meeting with Oracle in a few minutes. I’m going to ask for about 50k GPU hours on the OpenFE side. Is there anything else we need? JC – I’m also talking to google cloud. And AWS spot and AWS disaster recovery. DD – I think the fah-alchemy doesn’t need this - We’re mostly using fah, and the object stores are on the chodera lab AWS. DS – I think oracle’s motivation is to show that we’re running on their cloud. I’ll come to the meeting and represent our stance. JW – I don’t think OpenFF has big GPU compute needs. And I think oracle’s goals are to get more paying customers, and we’re not really paying. … JC – I think Oracle wants to show pharma saving money by replacing wet chemistry with compute. I also think that some cloud providers like google want to show useful work coming from TPUs, where they have an edge in availability. LN – I’ll also be on that call – we’ll be requesting nonspecific things for OpenFE and OpenFF, and also latest-hardware availability for CI.
|