NAGL lazy model loading/fetching - I have no prior relevant experience/strong preference for implementation. First step could be “propose design” for my review. JE was somewhat concerned about cybersecurity. MT – Stakeholders? JW – I think just LW, JE, and I. MT – I can take ownership of this.
Interchange 1.0/paper planning WRT protein parameter release. Which decisions do we need to make here? MT – From a project planning perspective, we want to figure something out WRT upstream stability, comms with userbase, and testing in the wild. Those are tractable, but from a project planning perspective, I’m not sure what the pathway/timeline looks like toward a protein FF or graph charges. JW – Is the tension that we either tell users that Interchange 1.0 will come out… On some arbitrary date, which might not line up with Rosemary date When Rosemary comes out, which isn’t a date
MT – The crux of the issue may more be that we need to decide whether the rosemary/protein parameter set release is a hard blocker. If it IS a blocker, then the release is stalled indefinitely. If it ISN’T then we risk coordination issues/being unable to fix performance issues by making breaking changes to interchange to support proteins in practice. (All also applies to graph charges - no release plan/dates) JW – I think odds are low that graph charges require breaking changes to interchange. I think odds are higher than protein FF does. Downside to treating protein FF as blockingto 1.0 release seems largely to be in terms of userbase communication and morale. If we don’t treat protein parameters as a blocker, we can derisk performance issues by trying out protein parameter assignment using CC’s current FF candidates. But even if we DO treat Rosemary release as blocking, we’ll eventually need to make our stack performant for protein parameterization, and it’ll be a bad look organizationally if our own infra has performance issues for proteins, so it’d be better for us to try out protein param timing and make major fixes BEFORE the FF comes out. So amybe that sprint/task would be the blocking thing for Interchange 1.0 MT – Partially agree. However while we can test vanilla use cases for protein parameterization, people will find weird edge cases where we have bad performance that might require breaking changes. So above points are correct, but this is a downside whether or not interchange 1.0 is blocked by protein FF. JW – I think with our current resources there’s no way to avoid people finding weird cases where we have bad performance. So it’s kinda inevitable that we will need to male our software work for the use cases that we can concieve of and test in a finite amount of time, and handle things that we didn’t anticipate as they come up. So I’m kinda in favor of putting a roadmap item up on Zenhub to enumerate and test out performance on tehse cases, then we can make the fixes that we find (even if those require breaking changes, those can be bundled into interchange 1.0), and then once that roadmap item is done the Interchange 1.0 release will be unblocked. MT – I’d kinda come to the same conclusion - Need to proceed without a protein FF release, and make an effort to ensure that parameterization isn’t too slow for vanilla use cases. JW will make a zenhub epic for protein parameteriztion performance use case enumeration, testing, and performance improvement.
(FYI) Finlay Clark will want to run some torsiondrive benchmarks using YAMMBS using a non-QCA dataset that Josh Horton says he can help convert over. Finlay will probably contact you at some point looking for breadcrumbs about running YAMMBS on torsion drives.
|