General updates | JW โ I spoke with LW about long-term development tasks to support science team. We brainstormed a bit but didnโt settle on a single direction. She may reach out to you. Any particular interests in benchmarking direction? MT โ Interested in the benchmarking direction in general. The two big liabilities would be 1) getting everyone to agree on specific project scope (very political/interpersonal) and 2) being in an infrastructure role but needing to defend benchmarks against scientific criticism. JW โ Thanks. Iโll bring this back to LW. Iโd try to have the science team set as much of the scope as possible. MT โ Iโd also be interested in working on a chemistry checker if it were specced.
ย JW โ MH mentioned a typing package - not sure what was meant. MH explained it as โwe could all use OpenFF units but serialize quantities to json differentlyโ MT โ The default behavior for Pint quantity serialization is that you can directly stringify and listify. But it is inherently an object, not a string/float/int/built in type. So this doesnโt settle the choice of [val = (magnitude,unit), val=โmagnitude unitโ, val_unit=โmagnitudeโ). MT โ Right now (somewhat opinionated) serialization code is in Interchange (using some decisions driven by the intersection of pint, numpy, and pydantic). MH suggested breaking this into a standalone package. MT โ I DONโT think itโs appropriate to put this in openff-units, since I donโt want that to be a dumping ground. Kinda same with openff-utilities. So we were thinking about something like openff-pydantic (MH may have called this openff-typing) JW โ Can any pydantic object become a json? Is it just pydantic โ dict โ json? MT โ Yes - Thatโs a fundamental guarantee of pydantic. But the path to json doesnโt always go through the dict representation. MT โ Ultimately we will have a function that eats openff.units.Quantity and returns something made of build-in types that can go to json. The question is where this will live. In an openff-pydantic package, this would be set as โthe way to turn an openff-units object into jsonโ. JW โ It sounds like youโve thought a lot about this and Iโm happy this is moving forward, so use your judgement on whether to make/re-scope repos to help this move forward, and just loop me in if you want feedback. If youโre up to talk more Iโm interested to consider adding this to openff-units. MT โ Iโd like to see how this goes - If it works well then we could consider moving it, but I donโt want it to be able to break our stuff in production. Stages would be: (current) - Serialziation code in interchange 1) Move serialization code out of interchange into an early openff-pydantic package (then we need to support this in production) 2) Consider merging into openff-units (MT doesnโt see much value in merging these)
JW โ Thanks for supporting MH on SMIRNOFF spec updates. Ideas for how to improve the process? Like, โhereโs a list of what requires an EP versus what doesnโtโ? The potential fields are unstandardized because I lost steam midway through and we never had a process for formalizing changes. MT โ I understand why things are kinda messy, mostly interested in making things better in the future. I see that there are some things that are obvious typos which clearly donโt require the whole committee. But there are other things that are more complex - the tricky thing is that there are cases in between that are exceptionally hard. Supporting MH on this is requiring clarification of some points. JW โ I agree with this classification, and that the middle cases are expensive/confusing. So if possible Iโd like to make a system to clarify when a version/spec change needs SMIRNOFF committee review versus when things are clearly cleanups. MT โ It could quite possibly be more work to make this classification system than it would ever save. Iโm OK with having judgement calls to identify which change proposals should become EPs.
JW โ I responded to Stan Wlodeck that weโll need a few weeks to debug before we can send vsite cases. Updates on vsite stability? LD question:
[not urgent] Hi Jeff, I see you're in focused work days, so pls feel free to respond when you're free, no rush. At JNS we'd like to include openff in a CL pipeline, specifically using OpenFF with Gromacs (also other softwares in the future).ย For the moment, we'd like to use both ways (Interchange, Parmed) to see which one fits better in the workflow, is more stable...So I see there are nice notebook example here:ย openff-toolkit/examples/using_smirnoff_in_amber_or_gromacs at main ยท openforcefield/openff-toolkit ย for both "convert with parmed" and "export with interchange"My question here is whether we're on the best examples or there's anything more updated / better that we can follow
|