Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Participants

Goals

Discussion topics

Discussion topics

Notes

Discussion topics

Item

Presenter

Notes

  • (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?

    • 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.

  • RG : openfe release status with latest RelativeHybridTopologyProtocol

Action items

  •  

Decisions