Page Comparison

(General) – The instance of this meeting on May 2 has been cancelled.

JC – Could we use a future meeting to discuss network constructions, and network transformation/SOMD implementation

• IA – Meant to meet with emilio (?) on this, trying to rope in someone from their group. Both ATM and (something) are GPL, which is a problem. We could probably convince ATM to switch more easily.

• JC – We could convince both to switch. Have you talked with CWoods?

• IA – We mentioned it last year, JM said they’d look into it but we haven’t heard back.

• JC – Steven Farr with OpenMM may be able to help chase this to completion.

• RG – Last time I talked with JMichel and CWoods they didn’t seem to think that the licensing was a problem.

• JC – Let’s discuss at the FE meeting in boston.

• IA – I could also use a push/introduction to Emilio

• JC – Will do

• DD – For next meeting, let’s do it after the Boston meetings (after May 18), earliest May 23.

• JC – Sounds good.

DD : alchemicale v0.1.0 released!!! 🎆

• deployed to https://api.alchemiscale.org

• first user credentials issued to:

  • Meghan Osato : openff

  • Jenke Scheen : asap

  • Irfan Alibay : openfe

  • DD – Anyone else want credentials?

    • JC – I’d like credentials under asap

      • DD – Will do.

    • IP – Do I have access?

      • DD – Whoops, I didn’t add you back, will do that as well.

• compute services ready for Lilac GPU hosts servicing all scopes

  • question on OE license restrictions - We have 3 orgs that will be using this system. On the compute side it’d be convenient to be able to use the same env, which means the same OE license. You’d mentioned on Thurs that the ASAP license is approved for generation of IP, but can we do open data?

    • JC – Absolutely, as long as the data generated is open/non proprietary.

    • DD – Would that be a problem for anyone?

      • JW – Nope, everything we generate will be open.

      • IA – Same, we’ll only be doing PLB stuff on Lilac.

• JC – Install instructions are available?

  • DD – Yes https://openforcefield.atlassian.net/wiki/spaces/IN/pages/2566586394/Protein-Ligand+Binding+Free+Energy+Benchmarks+via+alchemiscale?atlOrigin=eyJpIjoiMTQ2NTZmMGUzOWE0NGI4Nzk2OTkyZTJhZTZjZTAyYWEiLCJwIjoiY29uZmx1ZW5jZS1jaGF0cy1pbnQifQ

  • DD – Note that our max runtime on lilac in a decently prioritized queue is 1 day, so if your job takes longer than that we’ll have trouble.

  • JC – The 1-day queue is in the sweet spot.

  • IP – I’ll add my suggested settings to the docs for perses NEQ protocol

  • IP – Tried running not using alchemiscale but instead the gufe objects themselves to run on lilac - had trouble because everyhting got deleted form shared and scratch. How can we prevent this?

    • DD – We can’t - Alchemiscale doesn’t assume file permanence, they get uploaded to the object store. Though we need to figure out what the user mechanism looks like for retireval.

    • (thanks)

    • JC – Head to head compare for a small number of transformations (say tyk2 or host-guest system) for comparing and validating the different protocols (openfe and neq perses). No need to run ALL the dataset.

    • (General) – Should be feasible using some specific pathways - (see recording around 31 minutes)

    • IP – Yeah, I wanted to try tackling that this week.

    • DD – IP,do you want to do it, or IA, or both? IT’d be good to meet and make sure this is inth same scope.

    • JC – Yeah, maybe a small set of 3 ligands with the same binding free energy, and every time we add a protocol we could test.

    • DD – Who can coordinate?

    • IA – Could handle coordination at next week’s meeting.

    • IP – I can work on the noneq cycling validation, IA can work on benchmarking openff-2.1

    • IP - Does it make sense to compare perses to the OpenFE protocol? The repex from perses to the openfe protocol, and the … cycling between the two?

    • IA – The only snag we might hit is that we can’t use the same mappings currently, unless you’re able to ingest the mappings directly.

    • IP – Ah, right, that’ll be a problem. MAybe we can just compare the protocols.

    • RG – Is this because we can’t do the element change? I recall we had some trouble piping things around.

    • …

    • RG – So, we should be able to do this.

    • IP – Ok, I get it, that sounds good.

    • DD – I think this is lower priority than doing apples-to-apples comparisons of protocols that are both implemented.

  • JC – What’s the final location for these docs?

    • DD – Alchemiscale 28 and 30 – User guide and deployment docs - to put these docs on RTD. I just didn’t want to get hung up on PR cycles to get the initial docs out.

• JC – Conda package is available?

  • DD – Not yet, MH, could you start a feedstock? Would there be a problem doing this as 3 separate packages?

  • MH – Sure. Both should be fine. Is the repo laid out such that it can be split?

  • DD – Not yet. This may not be necessary since the source code is small, since the only change would be the deps.

  • MH – That’s true. Could just ship the client as a conda package for now.

  • DD – One issue will be that perses needs to be installed from a branch. Is this a problem with conda-forge?

  • MH – Yes

  • JW – Could make it a two-step install initially? - conda install, then pip install from branch?

  • MH – Sure, but in the long run (and maybe even short run) that will be problematic with c-f. One thing we have going for us is that the alchemiscale client is more of an application than a library. In the latter case we’d really want everything via conda but for the former it shouldn’t be too bad to do a mix of conda and pip.

DD – I’ll cut alchemiscale 0.1.2 which uses the latest deps and uses the recommended env files.

RG : openfe release status with latest RelativeHybridTopologyProtocol

• RG – This is done. There was a file issue, where we had some logic that depended on the existence of a file…. This is all out, you should be able to use it now.

DD : current sprint - ends 4/24

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

• alchemiscale 0.2.0 milestone:

  • Github link macro
    link https://github.com/openforcefield/alchemiscale/milestone/4

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

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

… (notes below are bad, see recording at 40 minutes onward)

Perses 1177

• IP – Maybe we don’t need the meeting tomorrow yet.

• DD – Could be a user experience working session.

Perses 1128

• IP – Working on this

• JW – Happy to screenshare and see if we can speed this up.

DD – add mapping behavior update to perses#1066

DD – gufe 143 – edge properties, maybe aimed at 2.0. Want to put it in a powerhour?

• RG – No, we won’t resolve this in the next month so let’s punt it.

DD – User guide and deployment operation docs – MH and I are working on this

• MH – No update, just need to write them.

• DD – Thanks, I’m also happy to contribute to this once you have a PR up.