2025-06-25 All-hands meeting

Project Updates

JE

• Both DM and JE will be on vacation in parts of July

• JE – DC or FC, any takeaways from yesterday’s meeting with european companies+centers?

  • DC – Nothing too big/urgent. Participants were as described in intiial post: https://openforcefieldgroup.slack.com/archives/GMX8VU345/p1750237121247309

  • Mostly partner companies, one other (P&G) that are working in an adjacent space. Some overlap with MMatta’s work. Astex are interested in macrocycles which overlaps with bespokefit-smee. I put the recordings on slack.

  • FC – Cresset also presented results on deficiencies with FFs (centered around aromaticity models).

  • DC – And DHahn presented on a wishlist for FFs as well.

  •  

  • .

Science Updates

June 2025 Science UpdatePreview

Infrastructure Updates

https://youtu.be/w27Erqpanpo

• DC – if we have a NAGL model that’s not an OpenFF NAGL Model, can we still use it in this spec?

  • JW – yes, that’s why we added the doi field. You could do this by uploading your NAGL model to zenodo and call it by doi

  • DC – I suppose each one would need to have a compatible LJ set, but that would be up to the user to sort out

• JW – the current NAGL model spec is intended as something of a band-aid. It leaves things unspecified because we can’t make sure that things will remain compatible in the distant future (i.e. compatibility-breaking changes to pytorch). We can make guarantees to support our force fields for some window of time, which might mean releasing new versions that have the same parameters but are compatible with newer versions of pytorch

• DC – S. Riniker has called attention to versioning issues in pytorch that can be resolved but at the expense of memory explosion

• JW – Right, we considered something like that, but it would add a huge amount of content to an OFFXML file. Might be worth looking back into.

• JM – I was expecting to see a hash property for NAGL Models. I think this would be pretty important. Is that no longer planned?

  • JW – I think the cases that would solve will be very rare, and the doi field should be a more relevant way to fix this

  • JE – are there any security implications that hashing would address? i.e. could someone distribute a malicious payload disguised as a nagl model?

  • JM – I still think the hash is important. If you don’t have the doi field it’s essential for peace of mind. And I don’t think we can rule out security concerns

  • LW – I did have security concerns when I first proposed this approach. I believe the method invoked is just a wrapper to unpickle, which is not secure. I could slack a .pt file to someone and tell them it was a nagl model but they wouldn’t know what it was.

  • JM – hashing a lightweight solution that adds a lot of value

  • JW – ok, I hear the value. Do you think it should be optional or required?

  • JM – we could make it optional and adopt the practice of including it in our models. We could also make it “required” (by the spec) but implement the case in the toolkit to load without one.

Shouts-outs

People from outside the Initiative using OpenFF to make easy-to-use workflows

• Ingrid Barbosa-Firias

• Valerij Talagayev

JW – Jen Clark has been relentless about getting our QCArchive records out into a stable, accessible platform. Docker images on Zenodo should make people’s lives WAY better in the future when they need to access this data.

JM – I had the pleasure of reviewing the bugfix on the Evaluator cubic box bug, and it was amazing. Everyone involved in the process deserves a shout-out.

LW – I didn’t do much, Matt deserves a lot of credit. And Jeremy (Leung?) at MDTraj.

Q&A

• JW – have we heard updates about any of our outstanding grant applications?

  • DM – The main outstanding application is the NIH BTOD, which is moving through the system at approximately the expected pace.

  • JW – What about Shirts lab funding? MuPT?

  • BM – MuPT is funded/not delayed.

  •