General updates | JW – Nothing you haven’t heard twice before I’m offline this fri, and next tues-thurs Are you taking Columbus day off? (fine if so, just need to update justworks)
MT – Interchange release planning - Rubber-duck-talking-through release plan. Some behavior changes. Many sitting in PRs in a state that I think is good. IA is pushing back on one behavior change PR, but changing design at this stage would push release back a lot. JM also gave feedback on some other PRs, mostly positive stuff but some changes requested. So there’s roughly 5 changes, each of which would be substantial to implement (even beyond coding - waiting for CI, documenting, PR completing, etc). But don’t want these PRs to drag out release for much longer, and I also don’t want to be dropping features/behavior changes in bugfix releases later. I’m concerned that pushing release back will start it sliding and will be hard to catch. Could also schedule feature inclusion in future releases. But I’m wondering about things like “if particle indexing change, can I just cut 0.5”? Kinda leaning toward “just get it out”. JW – My thinking is: Don’t bother adding new features at this time, just behavior changes. Features can come later. Happy to go over the major PRs to help you decide what goes in and what doesn’t 1051 - Particle bookkeeping 1. Positions vs. system with virtual sites Interchange.to_openmm_positions() → has a flag for VS, unclear what the default should be Interchange.topology.get_positions().to_openmm() → will never include virtual sites (without a sizable refactor for Interchange to not just use the toolkit’s Topology class) Interchange.to_openmm_system() → always includes virtual sites JW - I recommend doing nothing for this part - Users DO have a way to get positions with vsites. Can just link to other methods in docstrings MT - Agree MT - Should virtual sites be included in position getters? JW - (2/10) yes because failures will probably be a little louder if too MANY particle positions are provided MT – I initially set this to default to False, but on further thought I think it should be True (to_openmm_positions should mirror the dimensionality of what comes out of to_openmm_system). I can’t think of many use cases where people would want positions WITHOUT vsites. But I’d keep a way to turn it off. So this would be inconsistent with Topology.get_positions, but consistent with Interchange.to_openmm_system, which is good. JW – 100% agree
2. Collating virtual sites MT – Years ago, We/I decided that Interchange would put vparticles at the end of systems. There’s no community standard here. GROMACS collates by molecule (but could just as well collate by residue). OpenMM collates by residue, which I anticipate would be difficult to mirror (JW – Yes, we can’t easily mimic OpenMMs residue chunking). So my view of our options is either 1) keep putting vparticles at the end or 2) allow users to choose putting at the end of the system, or collate by molecules. Interchange.to_openmm_system always did 1), but Interchange.to_openmm_topology always did 2). JW – It seems like this is actually 2 things: 1) bugfix to to_openmm_topology to get its ordering matching with to_openmm_system, and 2) a new feature where we let people collate their system and topologyby molecule. I’d recommend pushing to get 1) into 0.4.0, but don’t worry about 2) unless we get it for free. So basically the only thing NOT to do is to allow to_openmm_system to collate by molecule in the 0.4.0 release. MT – System can’t collate and shouldn’t for this release, we’ll need to discuss that. The big use case would be like a TIP4P water box where otherwise zillions of vsites would be separated from their parent molecules.
1053 - Charge assignment logging 1064 - Topology charges are ignored 1068 - packmol density fix 1070 - edge cases with preset charges
There seem to be a lot of general improvements gated behind the release of 0.4.0, so that’s a driver for full release.
Matt’s decisions
MT – Re last time we looked at the list of things and assigned 1-5 priorities, that was really helpful. But I don’t have a new list ready, so nothing to prioritize today.
|