| MT – If we pursue “interchange as a hub” idea - right now we primarily expect openff topology+forcefield, but if we pursue the hub model we could basically have a giant pytest.parameterize that tries all-to-all conversions, and validate reference energies. However it’s likely that this will hit blockers in the OFF Toolkit that will add friction to development. Also there’s questions about where the outside parameters will come from - Would we ever run tleap or anything like that? JW – I don’t think we should ever run tleap - We should take the outputs from tleap (prmtop and crd files) but never run those ourselves. Someone else will need to make the automation that, for example, runs tleap. MT – This may leave a bit of the work unclaimed. And we’ll need to coordinate with the people who do make it, if we want it to play well with interchange.
MT – I want other people to provide the input data for the all-to-all tests, since I’m not a biophysics person. For example, files from five different use cases/workflows - Things like nonstandard AAs, WBO interpolated parameters, nonaqueous solvents, polymers, weird functional forms, etc. JW – This is a good idea. Would we need examples of successful conversions (including the output files) or is it sufficient to get the reference energies? MT – Reference energies should be OK. I’d like the inputs to all be OpenFF stuff. JW – Do we want ways to generate systems using the toolkit+openMM, or MT – I’m looking for a way to, when I’m testing stuff and I want to see if 4 exporters agree, I have input data that exercises a variety of realistic use cases. If possible, I’d like to eventually do this in a way that doesn’t use the toolkit. Tier 1: Get perfect agreement (parameters and energies) between ff.to_openmm_system and ff.to_interchange.to_openmm Tier 2: Get exports to other engines to match energies from tier 1 Tier 3: Once tier 1 and 2 have proven that the internal state CAN hold all the OpenFF output, then try importers.
The range of things to put through the above converters includes a variety of interesting topological features and functional forms. These systems don’t need to match any published values/FFs. Could gather data from:
|