| MT – Could use additional effort/eyes for PR review and beta testers LN – I’d be happy to do some beta testing and pitch in where I can MT – Also, it’s hard to get users to read the docs before they try stuff. Part of this is shortcomings in the docs, but part is that users could put in more effort. Lots of meetings that we have now consist of me reading docs to people. LN – Agree that’s frequently a problem in my experience as well. I’ve seen some people try to solve this with vary levels of success, but it’s generally hard. Some of it is automation on issue trackers to see keywords and direct them to certain docs. But it’s also important to have people be able to immediately find their answers in the docs. KCJ – These points seem like common issues that manifest outside of OpenFF as well. So if we come up with a process to solve some of these we should share it publicly. LN – Agree. I think comp chem companies also have trouble giving accurate feedback to the users, and they hide it well by having paid customer service to handle exceptional cases. Scientific software is a place where error handling/user feedback is especially complex. Compared to video games we don’t invest much in QA. KCJ – I’d like QA to be part of OMSF’s vision. I think we have a lot to learn from gaming industry.
JW – Could use help with interop support/system combination - We’ve got an issue where we want to support system combination but don’t parmed, openmmforcefields, and interchange aren’t totally ready to go. Could also use help on OpenFE toolkit development+interop/F@H project.
RG Could use help with OpenFE toolkits. We have GROMACS and AMBER experts but not an OpenMM. Interested to get your expertise involved. F@H interface project could be a good spot to get involved Could use more eyes on interchange and seeing how suitable it will be for FE calcs. LN – I’d be interested to hear more about the OpenFE goals - Like, what’s the scope of what you want to produce? RG – We want to have a unvisersal language to specify the FE network that you’re looking to solve, and not require you to worry about the details. So the method requested by the user will determine which engine will be called. LN – So you want to design a scientific problem engine, where you describe the science of your problem, and its deployment and execution is handled automatically. RG – Pretty much. But keeping in mind that the choice of method can dictate the choice of engine.
RG – I think one reason MMIC hit difficulty was because it was a nice framework, but that there weren’t enough implementations provided.
(Invited Levi to F@H interface meetings) RG – We’re about to have our MVP release and would love if you could help us test and give feedback. MT – I think you’d be really helpful on the interop front, but right now we don’t have a ton of user feedback to know what to improve, and we haven’t yet put this in a production release to start gathering user feedback. So once that happens we may have questions that you could hep us a lot with. JW – Agree, it may be helpful to have some really deep interchange testing to see its suitability for OpenFE, but it will be very complex RG – It will depend a lot on where we put the free energy info LN – Yeah, it will depend a lot on the details MT – I don’t have a ton of depth on free energy. So I’d need expert input to understand this. RG – Right now we’re primarily targeting OpenMM. I don’t know how interoperable our OMM-specific stuff will be, or ow much we’ll need to rewrite to support for other engines. LN – Agree that OpenMM is the best option at this moment, but it’s far from ideal, and it’s showing it’s age.
LN – This sounds great. I’ll begin attending the “F@H interface” meetings. Watch my inbox for contact from RG with more details about places I can pitch in Reach out to MT to coordinate requesting PR reviews or advice as-needed Review OpenFF toolkit biopolymer pre-alpha (JW will send LN the link on Slack)
|