2023-01-10 Protein-ligand benchmarks meeting notes

Owned by David Dotson, created
Last updated: Jan 17, 2023
5 min read

Participants

  • @David Dotson

  • @Mike Henry

  • @Irfan Alibay

  • @Iván Pulido

  • Jenke Scheen

  • @John Chodera

  • @Richard Gowers

  • @David W.H. Swenson

  • @Joshua Horton

Goals

  • DD : fah-alchemy name change - seeking approval

    • not specifically tied to Folding@Home, more broadly deployable with HPC and cloud compute resources

    • broadening appeal can help promote sustained development

    • alchemscale? alchemiscale? Other ideas?

    • JC + JW – Probably not enough time here to come up wiht a high-quality name - Could we run a weeklong poll?

      • DD – Perfect, I’ll open a poll on the slack channel and we can vote next week.

  • DD : Hugo MacDermott-Opeskin onboarded; working on fah-alchemyhttps://github.com/openforcefield/fah-alchemy/issues/55

    • JC – HO is unable to join this call, right?

    • DD – Right, but he’ll join another group call on thursday that will be at 4 AM his time.

  • DD : new sprint start - deadline 1/24

    • architecture overview : https://drive.google.com/file/d/1Elw5vWYXuGKSuO-E3jNMxkYnSQaioVF8/view?usp=share_link

    • coordination board status : fah-alchemy : Phase 1 - MVP

      • gufe #110

        • MH – Combines 105 and 109, they’re a bit in-progress so we need to do a bit more there.

        • DS – Keep in mind that there is some discussion in those PRs that will be relevant, so do be sure to check back so those don’t get lost.

        • MH – DS and I will keep working on this

        • DD – I’ll review #110 when it’s ready

    • updates on In Progress cards

      • gufe #111

        • RG + DD – We’ll discuss this at our Thursday working session

        • RG – Though since this is a little time sensitive, maybe we chat sooner.

        • (RG+MH+DD will continue discussion offline)

      • DD – My next steps are error handling

      • fah-alchemy #25

        • MH – Close to getting this work. Just testing using an EC2 instance with letsencrypt. Testing locally and in cloud, making sure we can smoothly push things to production. Just need more time to do focused work. Using some personal domains, eventually we will want to figure out a stable domain to deploy this one.

        • DD – To recap - In discussion with MH over the break, we realized that the things in the green box in the architecture diagram should be on their own server (allows routing control, port control, cert management).

        • MH – We initially discussed colocating the green box with the work server, but realized that this would make work server overloading possibly affect the responsiveness of the green box processes. Also separating the servers will let us more easily handle letsencrypt.

      •  

    • seeking volunteers for unassigned cards in Available

    • JC – I think it’s important to have the examples set up and available.

      • DD – We have fah-alchemy PR #46 which has some in-progress examples for how to set up alchemical networks.

      • IA – How much overlap is there between these tutorials and the OpenFE tutorials?

      • DD – A lot. As we build out our docs we might just lean heavily on OpenFE materials.

      • IA – Yeah, I don’t want to duplicate maintenance costs.

      • DD – …

      • MH – This touches on an issue with deeply interconnected repos - Where do the authoritative docs/examples go?

      • RG – Git submodules for tutorials? This would allow them to be shared.

      • DD – Maybe a sphinx interlink in the docs?

      • JC – RTD or Github Actions?

      • DS – I think it’s easy to change between them.

      • JW – in discussion with Josh Mitchell, came to conclusion that a third repo approach works well for OpenFF given its floatilla of packages

        • openff-docs

        • that repo has to live somewhere, however; complicated here due to multi-org, but having to live under one org will clarify which org is primary for maintenance, then they have to delegate repo access to others and establish mainenance responsibility.

        • RG – That may work well.

      • RG – We’ll take over the content of fah-alchemy #46 and figure out where to put it (will probably migrate to gufe).

  • DD : fah-alchemy 0.1.0 milestone

  • MH : deployment - docker compose deployment on single host

  • IP : Nonequilibrium Cycling Protocol (perses#1066) update:

    • IP – I started the analysis notebook, now I understand how the analysis will work wiht bootstrapping. But I’d like to meet with DD about how to integrate this with the GUFE objects.

    • IP – Also I’m just waiting for the settings to stabilize.

      • DD – I think we started the PR so that you could move forward without it, are you able to use it?

      • IP – I think so, let me try it out.

    • DD and IP will meet immediately following this call

  • IA : protein-ligand-benchmark : blockers and priorities

    • IA – Still working on this,

  • PLB #87

    • IA – I also have most of the PDB fixing done, but am hitting CONECT record issues. Some other little issues. Like, do we care about CONECT records for caps?

    • JC – I’m surprised that PDBFixer isn’t generating the CONECT records.

    • IA – This isn’t PDBFixer - It went through maestro.

    • JC – Yeah, maestro doesn’t make valid PDBs. Next iteration we should use OE spruce. Does OMM read them OK?

    • IA – OMM reads them fine, it still assigns bonds.

    • RG – BTW, pdbx won’t have conect…

    • IP – I tried running some systems from the newly prepared systems, I’m seeing substantially worse performance than the original set.

    • IA – When MB reprepped some of the systems we ran them with OpenFE stack and saw slightly worse but it was within error bars. One big note is that the old networks had more closed cycles which allows for greater redundancy/accuracy. This was using the same network as before, but the new structures.

    • IP – (shows plots indicating worse performance with new structures, keeping the edges the same)

    • IA + IP will meet up on this

    • JW – Does this affect other areas of the plan? Are there developments that we should discontinue until this is debugged?

    • IP – …

    • IA – I think we should move forward to the 0.3 release regardless, and we can handle this on the way to 0.4

  • Gufe #111

    • DD – (Shows neo4j visualizaiton of tasks) DS does this line up with your work?

    • DS – I think so, will think/look more closely later.

  • fah-alchemy #34

    • DD – JC, if I’m running on Lilac and submit a job requesting one GPU, how does OpenMM know to use the GPU that I was assigned?

    • JC – When you get assigned a one-GPU job, that session will see CUDA device 0 as the one assigned GPU. (and if N GPUs are requested, the lowest N indexed CUDA devices are assigned to you)

  • PLB 78

    • DD – This works of refactoring the repo to split out python code. I’m going to pause this while the other PLB stuff is looked into.

  • DD : cards in play

  • DS – Re: storage and retrieval - DD - It’d be helpful if we duck typed things the same way. Like, when a storage object is asked for all the results of a transformation, the funciton call and API should be the same for my storage and your storage. We almost certainly have the same information, I just want to make sure it’s accessible through the API points with same name.

    • DD – The API I’m working on is in interface/client.py

    • DS – We separate the storage and compute aspects. You have compute in the same API while we dont. But we should synchronize on storage API.

    • DD – Agreed. We may not be able to get this identical but we can get it close.

    • (some substantial differences around things like scopedkey, but maybe difference can be overcome)

Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

 

 







Action items

Decisions