Versions Compared

Old Version 1

changes.mady.by.user David Dotson

Saved on

compared with

New Version Current

changes.mady.by.user Jeffrey Wagner

Saved on

Key

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

Participants

Goals

Discussion topics

...

Item

...

Presenter

...

Notes

  • DD : Free Energy Workshop for Drug Discovery - alchemiscale poster abstract review

  • DD – Deadline for feedback is about 12 hours from now

  • DD : current sprint - ends 3/20

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

    • alchemiscale 0.1.0 milestone

      • Github link macro
        linkhttps://github.com/openforcefield/alchemiscale/milestone/3

    • coordination board : alchemiscale : Phase 1 - MVP

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

      • DD – Alchemiscale 34 - SynchronousComputeService. Working with HMO, lots of little pieces that are hard to separate out, so they’re grouped under one task. Running live testing on the AWS test server.

        • DD – Seeing test errors related to RDKit API (SetIsotope)

          • RG – This is related to recent GUFE changes. Is this trying to load old data?

          • DD – Yes, I’ll remake the old data. How unstable should I expect the object model to be?

          • DS – We’re pushing to gufe 1.0, but until we get there, we may have more changes.

          • RG – Yeah, we should have stability once we reach 1.0

      • IP – Perses 1066 – Haven’t touched this. Need to change how we’re doing selection with mdtraj, there’s some issues related to ordering. Basically, when you take an openmm topology and create an mdtraj one, you’re not guaranteed to preserve the indices of the atoms. So if we want to use the selection algebra to slice out some atoms, the indices returned by MDT may not match with the OMM indices.

        • DD – In which cases may this affect me?

        • IP – It may affect you, I’m hoping to have this fixed by Thursday

        • IA – Is this change deeper than in Perses itself?

        • IP – No, this is just a consequence of how we’re handling topologies.

        • IA – But would this affect our hybridtopologyfactory?

        • IP – I don’t think so. My big issue was using private attributes.

        • IA – Is the old perses behavior susceptible to this bug?

        • IP – No, this is only in new code.

      • JW – can you say about how this indexing issue differs between OpenMM and mdtraj

        • IP – when we add ligand to a topology, we add it to the end in OpenMM; however, in mdtraj it appears to change where it appears, like it sometimes goes somewhere else

          • to avoid using mdtraj indices,

        • DD – This is strange to me.

        • IP – This is strange to me too, but JC is 100% sure this is happening. I have to use private attributes from the HybridTopologyFactory.

        • DD – This seems to be a reasonable use of private attributes.

        • IP – That said, we do want to add/improve tests on this to make sure we continue handling it correctly.

        • IA – Related: At some point, I asked MH for the trajectory specification used by openmmtools used for netcdf files.

          • RG – I think the code is the spec - If the target is cpptraj behavior then they’re not necessarily following the spec. Do they have a spec?

          • IA – Yes, there’s a public netcdf spec in ambertools. But does openmmtools adhere to that spec? https://ambermd.org/netcdf/nctraj.xhtml

            • IP – There’s something that runs in openmmtools, but I wouldn’t assume that it adheres to the spec.

          • IA – Would openmmtools be open to the possibility of realigning to that spec?

            • IP – Yes, we’d be interested. This had fallen off my plate.

            • IA – I’ll open an issue

      • DD – Any other stuff to watch out for?

        • IP – Default settings, mayne? Right now it’s two steps - 1) get defaults from GUFE, and 2) get defaults from noneq cycling. But I think we can make it one step now.

        • DD – Gotcha, yeah, it’d be good to consolidate that.

      • DD – Perses 1128 – JC is working on this, will try to finish today.

        • IP – I’m not sure this will really be finished today since JC is en route to OE CUP. If he hasn’t finished this I’ll contribute.

        • JW – IP, if you end up pushing on this and want a live API reference for OpenFF, let me know and I’ll screenshare.

        • IP – This isn’t a blocker for noneq cycling.

      • RG – OpenFE example notebooks 36 – A little blocked by noneq protocol, contacted IP.

        • IP – I’ll prioritize the needed changes in my branch.

        • RG – Would it help if I switched out noneq protocol?

          • DD – Th

      • .

Action items

  •  

Decisions