2023-06-06 alchemiscale Working Group meeting notes

alchemiscale.org user group

• user questions / issues / feature requests

  • DD – MO, how are your submissions coming along?

    • MO – Nearly ready to submit, but have finals right now.

    • DD – Feel free to shoot from the hip, submit things that fail.

  • JS – I hit a version mismatch error (openforcefield/discussions/27). Will we always expect users to have things up to date in the future?

    • DD – No, we shouldn’t have such tight coupling in the future (alchemiscale 126). Expect this in 0.1.3. In the meantime, consider building a new environment.

    • JS – And then I don’t need to resubmit, right? I just update the env and pull? Or is it not enough to update my env?

    • … (see recording ~7 min)

    • IA – DD, maybe you, DS, and I could take a power hour on forward/reverse compatibility.

      • DD – I’d be happy to do this.

      • JS – Great, I’ll slack you.

• compute resources status

  • DD – Lots of compute available. Anyone want to run anything?

  • IA – We have a working session on PLB on monday. So we may have networks to submit next weekish. Probably absolute free energy of hydration.

• call for new users

  • JW – Once MO susses out any landmines/pain points I’ll put out a recruiting call for people at OpenFF who are just doing parameter modification (not functional form modification). But not super urgent.

  • IA – We should be able to do alternate partial charges but custom parameters may be harder.

  • JW – I may be misunderstanding something fundamental here, let’s chat if there’s time at the end of the meeting.

• current stack versions:

  • alchemiscale: 0.1.2

  • gufe: 0.7.3

  • openfe: 0.7.4

  • perses: protocol-neqcyc

  • MH – We have newer versions of openfe and gufe that we could update?

    • DD – Key changes?

    • DS – Yes.

    • DD – Ok, we will want the improvements in alchemiscale 0.1.3 before we re-deploy with latest gufe + openfe; aiming to get this release out in next two weeks.

JC : follow-up on extends support in RelativeHybridTopologyProtocol and NonEquilibriumCyclingProtocol

• JC – We briefly talked to IA about this. But we need to schedule a time to talk about this with replica exchange…

• IA – This is on me, I’ll email you now to start coordinating.

• JC – Great, I think this should be straightforward.

JC + JS : tools needed for AlchemicalNetwork generation?

• JC – (screen share, ~19 min) Trying to capture pain points in setting up and running FE calcs

• https://asapdiscovery.notion.site/Computational-Chemistry-Core-alchemiscale-related-roadmap-9052f215437246f9be4a11abd10f6d71

• (Q+A)

• JS – I really like this and agree with the document as presented.

• RG – This is super interesting, I’d need to give it a second read before I commit to anything - IA’s to-do list is full.

  • not currently considering the pose problem; a bit too much on our plate at the moment

  • JC : would be useful to align on pre-requisites for moving into your pipeline

• RG – We treat the poses/maps as input-only. It would be outside our philosophy to change poses after submission.

• JC – might already be in area where poses don’t exactly overlap; could already be in a position to do hybrid / single topology

• IA – This is a good opportunity to follow this list of pain points to specific cases that we can run. That would help us identify our boundaries/expectations - Right now we don’t know our limitations so this would help us map out our capabilities.

• DD – And JS would be super well positioned to help identify these.

  • JS – Yes

• RG – I think we’ve soured a bit on MCS. Instead we want to look a bit at the rotatable bonds and see how good an overlap two mols can achieve.

  • JC – I think that’s a really good idea. Some way to look at conformation space would be good - orion is doing this - just running MD and looking for conformer overlap. The key is not requiring the atoms to be in the same place in 3D space.

• RG – The intermediate molecules thing is an interesting idea. I know Cresset does this. It might be treading on their toes to re-implement this, but it seems promising.

• JS – Mobley is doing a science project on this exact subject; I’ve seen Cresset’s backend code, fairly crude at the moment. Mobley is working on an approach that could be more robust

• IP – MMP could help here, RDKit can do that.

  • JC – Yeah, but that’s a slightly different topic.

• JC – want us to think about what the API looks like; there will likely be many of these ideas for this; can we figure out “the shape of the thing?”

• RG – I could see this being pre- or post-simulation, either by spotting the differece between ligands ahead of time or by seeing the sim results and recognizing that the transformation didn’t work well.

• JC – Yeah, this could be promising.

• JS – If you’re introducing a synthesizable intermediate, that could be helpful for drug discovery too.

• JC – Yeah, this could be part of an optimization cycle. So we can offer a stub where people could plug in, and then they could experiment with it.

DD – In one sentence, could you say what you think the first steps should be?

• JC – We’re going to start with the short term plan - A hierarchical docking tool could be useful for OpenFE - Either OSS or OpenEye. Forexampleyou probably have a minimum spanning tree with redundancy mapping. So a conversation between IA and JS and I could get this.

• DD – Yeah, HMO and Alex are working a lot on the docking bit. Does this overlap?

• JC – Yes, if this is an engineering topic then it should go to them, but if it’s a science project then it may be best elsewhere.

• DD – Let’s merge that into this working group

  • JW + JC + RG – Approve

• .

IP : Protein-ligand benchmarks working group update

• IP – We met yesterday and have some action items. IA will be setting the automated network generation. KT will help us manually curate a few systems that he’s identified as problematic (either the structures or the networks). I already merged a PR that gave us a base structure for directories. After that, we probably want to release a version, and then start including lots of external people.

• DD – This is great. Thanks for spearheading this, IP. Do you want any help with coordination/tooling like places for notes?

• IP – Yeah, I was thinking about this, not sure which place would be best for this.

• JC – Maybe the PLB paper repo? Could use issues and discussions there.

• IP – This could work.

• JW – I’ll give you access to the livecoms repo unless Mobley tells me not to. Provenance will always be a mess and people will yell at us no matter how much work we put in, so just make a reasonable effort to keep things tracked/versioned and that should be fine.

• DD – Yeah, that’ll be handy,you can link meeting notes and keep records of decisions that were made there.

• .

alchemiscale development : sprint in progress through 5/31 - 6/12

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

• coordination board : alchemiscale : Phase 2 - User Feedback and Documentation

• alchemiscale 0.1.3 milestone:

• alchemiscale 0.2.0 milestone:

• updates on In Review, In Progress, and Available cards

  • MH – Alchemiscale 130 (backups) – No update, I’ll work on this a bit in the future. This is plan A moving forward.

  • DD – Alchemiscale 126 (UX improvement) – Will allow you to get status at the org level (n completed tasks, waiting, running, etc). Also will allow pulling status of whole network. Also the ability to get back the scoped keys for all transformations in a network.

    • IP – I think there are two levels here - One is asking for the status of tasks, and the other is getting the results. I think I’m also hitting a bottleneck when I try to get all the results from tasks. Will that be included here?

    • DD – This unfortunately won’t address that. What you could do as a workaround is using multiprocessing with your clients.

    • IP – That’s be a good workaround,but eventually we should put that into the core infrastructure. I’ll open an issue for this.

    • JS – Would it make sense to include IP in our working session then?

      • DD – Yeah

      • JS – I’ll loop him in.

  • IP – (“Test noneq protocol against repex protocol”, no link, see 56 mins in recording)

    • RG – Is this coming soon? We’re looking at how this 3d geometry mapping we’ve done would compare with LOMAP. This may overlap somewhat, we’re going to do this check in the next two weeks. So this may save you from running things that we know are bad mappings. We’ve seen some “spicy” cases in hif2a where our mapper is getting different results from lomap.

    • IP – Ideally we want to run these two protocols with everything on PLB. We can refer to that as a source of truth/reference.

    • IA – RG, after the call on Monday the plan was that we’d generate various mappings for various networks… So once we have updates we can check out different options.

    • IP – I’ll review whether this can be before/after 0.3.0.

  • DD – Some items are available… (see recording at 59 mins)

  • • .

custom FFs for Protocol execution