2024-03-20 Thompson/Wagner Check-in meeting notes

General updates

• JW –

  • Nice ad board meeting this morning, lots of questions about NAGL and folks wanting to try it. See post in tech support.

    • MT – Worth mentioning that this is on us - We’re being conservative with release cadence/endorsement.

  • Just spoke with Cresset, they want a way to bypass restrictions on monovalent and divalent lonepairs. Additioanlly they’ll need the new spec update. DM will ask gov board but I think this may be an insignificant'-ish amount of effort other than SMIRNOFF committee work. Agree?

    • MT – Two things I want to point out are 1) this is responsibility of smirnoff committee and 2) I don’t have a great understanding of what they’re trying to do, but I’m not sure that their draft is of sufficient quality for discussion. I would view the removal of restrictions as requiring somewhat substantial thought+testing, and to largely be in the Toolkit’s court.

  • MPitman is interested to start contributing. I told her to start playing around with Interchange.from_openmm and combine and to give us feedback.

  • Thanks for quick DSlochower turnaround+feedback

    • MT – Agree, happy with turnaround.

  • JM is back on moving Trello tickets for a week or two. I’ve assigned priority to keep him from getting paralyzed, and said anything in the requires review column is “high”.

    • MT – Great, I like working with JM and am looking forward to the back-and-forth

• MT -

  • Move benchmarking code to org namespace?

    • JW – Yes

    • MT – Specifically, any requirements from your perspective fulfilled before that happens?

    • JW – Code looks good, easily clears bar for our namespace. This clears the bar for conda-forge packaging and stuff. I’d just hold short of publicly recommending for external use until we have docs+examples+more polish.

    • MT – Great. I hadn’t even planned on packaging yet but may get to that in coming weeks.

  • SPEC0

    • MT – Important differences from NEP29 is dropping python support from 42 to 36 months (currently we support 3-4 versions at a time, whereas SPEC0 would have us supporting 2-3).

      • Other change is that it enumerates more than numpy version ranges (includes scipy, xarray, etc). This isn’t highly consequential for us.

    • JW – I’m in favor of the second point, but the first one is too tight. By our nature we will have academic/risky deps that become abandoned and having a stricter timeline will eat up our “fires/explosions” budget.

    • MT – The more I have to support old versions of things, the more work I have to do to make even the smallest changes. Combined with versions of openeye, pydantic, etc make the maintenance burden harder.

    • …

    • (general)

      • There are two types of user:

        • Scientists who can make stuff work outside of our version constraints

        • General users who should get safe build by default.

      • Industry users are often silent about failures - if they try to make an env with their favorite abandoned python tool + openff-toolkit, and env creation fails, they’ll likely walk away and not report the problem

      • MT – Internal users (or external) can always write in to ask for relaxed version constraints when they have a use case.

    • JW will post in OMSF slack that we will stick with NEP29 to get the wider python window.

  •  

Trello

https://trello.com/b/dzvFZnv4/infrastructure

Tutorial collection