2024-10-14 Mitchell/Wagner Check-in meeting notes

General updates

• JM –

  • KCJ asked me if I’d like to spend time on POSE grant accomplishing some of our POSE goals.

    • JW – I see your workload in coming few months being two time sensitive things and one other - Workshops (time sensitive), besmarts docs (time sensitive), and evaluator docs improvements (less urgent). And it’s be good to keep you focused on becoming second for Interchange.

    • JM – Not sure who makes decision and I’m not sure which way I lean, just brought it up since it’s an option that KCJ mentioned next year.

    • JM – I’d also love to do a research cycle on whether there’s a better tool for automatic api documentation. Rust does this really well, in fact it’s part of the central package manager/repo.

    • JW – That’d be really cool. Would like to ensure we don’t end up owning more at the end though. Though I like the idea of you getting to learn stuff and someone else paying for it.

    • JM – Goal is to contribute upstream to sphinx or somewhere like that.

• JW –

  • Some interest in hearing about next year’s workshops at gov board meeting this morning (PTM workshops were seen as a great success). I’ll ask ad board for ideas in November, but it might be fun to popcorn stuff here.

    • JM – Maybe we build on PTMs? Broadly, those are a common problem without a solution. So we might think about other problems without good solutions and run workshops on those. Also, we might time these to come out with NAGL or Rosemary so we can use tehm to push those products.

    • JW – We should be showing nagl heavily in the workshops, so absolutely recommend using it for PTMs. Also, since Rosemary is so delayed, we’re making a go/no-go decision on whether to make a purpose-built PTM tool in early November. So committing to a workshop on this will help codify best practices for whatever we decide there. So I think we should definitely run a PTM workshop

    • JM – does that mean we’ll condone ff14SB valence+vdW with NAGL charges?

      • JW – Yes, I think we’re at the point where we have to do that. We can write it on the side of the black box.

      • JM – So a lot of the work will be the loading?

      • JW – Possibly, though hopefully we could delegate that to the MDanalysis loader. Then the big thing we’d offer is the force field blender+simplified charge assignment behind some new API point.

    • JM – The PTM one was just a vignette this last year. I think we should do more applications

    • JW – Maybe CSP? could build off of (or pare down from) THuefner’s crystal work

    • JM – And a bespokefit one, which could overlap with CSP.

    • JW – That would be handy, xTB-python stopped being maintianed so we’ll want to push people toward using AIMNET2/(or maybe ANI, I can’t remember the distinction)

    • Collecting ideas here

  • Reminder: I’m offline in two days, meeting cancelled

  • Could get you on NRP today so you can try kubernetes compute. Somewhat risky since they expect a moderate level of expertise, but if you start small-scale (keep it under 10ish cores) you’re probably OK.

  • https://github.com/openforcefield/qca-dataset-submission/tree/master/NRP#onboardinggetting-started

    • JM – I’m already on NRP

    • JM – It looks like there’s an option for persistent storage, I can use it for output of preparation. And I can host containers on their gitlab. I’m learning more about all these things.

    •  

•  

Trello

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