2023-05-30 alchemiscale working group meeting notes

alchemiscale.org user group

• user questions / issues / feature requests

  • IP – Status of Alchemiscale 126, abut task completion? Currently calls take ~40 minutes to complete.

    • DD – Prioritized for release 0.1.3 - Assigned to HMO, I’ll try to bump this in priority.

  • User discussion forum: https://github.com/orgs/openforcefield/discussions/categories/alchemiscale-user-questions

  • IA – really want documentation on Scopes and ScopedKeys

    • DD – This is on my plate in a future sprint. I plan on doing a first edition of docs/a user guide.

  • JC – Iván and I have discussed wanting to implement a protein mutation protocol soon. Are there any issues anticipated with this?

    • DD – I spoke with Sukrit about this at the ASAP meeting. I don’t anticipate issues but I’m not sure if there are things that would be needed in GUFE.

    • IA – We’d probably need to rethink mappings, so we can map the parts that changed, but avoid having all-to-all mappings with proteins.

• compute resources status

  • DD – Alchemiscale.org is using Lilac and PRP. No jobs submitted as there is nothing in queue. So feel free to submit.

  • DD – I’ll also work on optimizing usage on Lilac.

  • DD – I’ll also see about getting a lab-wide allocation on lilac.

  • IA – Does it make sense, if I want to donate my user to run these jobs…

    • DD – Let’s not pursue this until we have an answer from lilac admin.

• call for new users

  • IA – we might get someone new at OpenFE that will be needing it in the next month or so but will reach out when necessary

  • DD – The Toni Mey lab was interested in running. I’ll help them get set up on our server, but this won’t affect our compute. This is also fitting since they’re part of ASAP.

  • JC – I think the next step for many of us users is to develop the tools to set up and submit alchemiscale jobs and analyze them. I'm wondering how much infrastructure could be shared with OpenFE on that aspect. Like, building docked poses, ligand confs, etc. Could be good for OPenFE to coordinate with ASAP (not sure if this happened at boston meeting)

    • RG – If JS has a wishlist, we can give yeses and nos, and whether things are planned.

    • JC – I’ll work with JS to come up with this list and we can talk at next week’s meeting

    • DD – Maybe it would be good to put these items on the discussion forum linked above?

    • https://github.com/orgs/openforcefield/discussions/categories/alchemiscale-user-questions

    • DS – it’d be great if JS could tag us in posts since I’m not watching this.

      • MH – https://github.com/orgs/community/discussions/3550 Looks like you can set it up to watch

    • IA – If JS wants to book an hour to bounce ideas, I’m happy to chat with him.

User stories review - gap analysis

• DD – Planning to do this in the next couple weeks. Planning to review user stories from the beginning of the project. Will be going over these in next weeks and will update their statuses and ask followup questions about whether the needs are met.

JC : extends support in RelativeHybridTopologyProtocol and NonEquilibriumCyclingProtocol

• JC – We’re going to extend NECP to extend sims. This will be important for preemptible jobs, and for adaptive sampling. I’m happy to work with you folks on repex, to ensure that results object contains enough info to start the next sim/let you take advantage of odd compute resources.

• IA – This is extending simulations? I think this may notbe possible within alchemiscale?

• DD – If you run a task and you know it’ll run in 4hours, but it gets killed before 4 hours, then those will need to start from scratch. But what we’re interested in is defining small chunks in a chain of smaller calculations that are more likely to be completed. But this isn’t the same as restarts, this is extension

• IA – For repex, we need trajectory/timeseries. So dH calcs for entire traj, and final coords and vels…

• JC – IA I think it’s pretty straightforward to do this with current repex and we can talk later.

• IA will schedule a meeting with JC

• DD – Current “extend” relationsships don’t use information form the previous result, they’re restarts.

IA : benchmarking results for OpenFF 2.1 vs. 2.0

• p38 discrepancy; conclusions?

  • IA: reported to OpenFF as per DM’s suggestion - not expecting a response?

• JW – Thanks, I think this was what we needed.

• KT – Have you looked at the initial structures? There are some problems with them that seems to be causing these outliers.

• IA – We’ve looked at them, would be happy to hear about outliers/take another look.

DD : OMSF Symposium retrospective

• appears to be interest from industry players; how best to engage to maximize impact vs. effort?

• academic users interested in their own deployments?

• JW – From OpenFF’s persepective, this isn’t something we can afford to provide tech support for everyone.

• JC – in my ASAP role I’d like to support this tool’s use in industry. Academic users can be our testers

• RG – Right now we’d like to get people going from 0 to 10 FE calcs instead of 0 to 1000. Keeping the additional complexity of Alchemiscale away while we get our own tools standing seems to be important.

• DD – I’ve been talking with folks, I’d be interested in putting together a product-ized service offering for clients, and do managed services around that. I think I’m in a position to provide that service and I could build out a team to do that. I’m also interested in ensuring that this serves OMSF’s mission. So a lot of revenue from the service offering would go back into OMSF so we can continue working with OpenFE and OPenFF.

• JW – I think OpenFF has enough complexity already, but if this became an OMSF-level offering or a separate project, I’d be supportive.

• DD – I’d actually envision doing this separately from OMSF, as a for-profit endeavor, but with support going back to OMSF.

• JC – So this would be selling services around an open source offering, but with offers fur further features and customization?

• DD – Yes

• MH – This makes sense. Companies will appreciate the final mile support.

• JS – +1

• JC – This solves lots of issues we had in deploying free energy calculation infrastructure within industry as well

• IA – You’d mentioned talking to KCJ about this - There’s more depth to this on the OMSF level about how the nonprofit and for-profit arms interact but stay separate. Folks in industry really want to have us be able to see their data and help them debug.

• DD – The for-profit arm would allow us to see proprietary data, which the nonprofit can’t do. This could also help guide our internal work.

• RG – I’m interested to hear how this develops.

DD – Also planning to talk to toni mey, danny cole, julien michel. JM was interested in interop with biosimspace.

• IA – BioSimSpace is complex for us as it’s GPL, and we can’t do non-MIT work. And WRT to new academic users, I think it’ll be good to bring them on slow so you don’t get too swamped.

JW – need tot take care of an issue, could someonee else take notes for a minute?

IP : Protein-ligand benchmarks repo

• Ken updates/discussion on current state

  • Noticed issues in the plbenchmark want to share my thoughts about it

  • Slides https://drive.google.com/file/d/1xNxGDTehDADiBdvjvATihDO3SyUWSFxF/view?usp=drive_link

  • JC – This is great feedback from a friendly user with lots of pharma expertise. Maybe we should have a discussion with the PLbenchmarks team and capture all the issues that need to be addressed on the PLbenchmarks roadmap (pulling in Melissa too)?

• IP updates on new task force group

  • IP – We’re still trying to get leaders/PIs/industry group leaders working on this. I did want to know what we feel in this group before I amke offers to them.

  • JC – That sounds good in the long term, but in the short term we should have a postmortem with MB and IA and consider making a near-term release

• IA – If I could raise a red herring ehre - The perses edges weren’t production ready. They’re just star maps. Up until 2.1 the networks were all hand-generated, and I’m hoping that in the future other folkswill contribute networks that work well. Also we can have lomap and himap networks.

• KT – Are the initial structures the same…?

  • IA – Should be equivalent to what’s on main. I know MB had a lot of trouble with docking - if there’s a betterway to re-dock with core constraints that’s something we should be looking at.

• DD – Thanks Ken, are you planning to be part of working group? This analysis was great and could help guide future developments.

  • KT – Potentially.

alchemiscale development sprints: begins tomorrow, spans 5/31 - 6/12

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

• alchemiscale 0.1.3 milestone:

• alchemiscale 0.2.0 milestone:

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

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

• create/nominate new cards for inclusion in this sprint

IA – FYI, openFE release coming on Thursday.

• DD – Would you like that deployed to alchemiscale?

• IA – We’ll catch up about this later.