Experiences with vsites | SB – These are quite painful to deal with, even if I’m working with a ParameterHandler that doesn’t create vsites, sine it needs to be able to handle the presence of vsites if they’re around. VSite pain points Inclusion in molecule/mangling indexing scheme in Topology Inability to add to topology after molecule is in Difficulty of differentiating between atoms and vsites in a NonbondedForce Manipulating positions / when positions are needed → Input coordinates almost never have vsites, so what do I do when setting positions? OpenFF topology doesn’t add vsites to OpenMM topology in OFFTop.to_openmm A custom NonbondedForce will need to go after VirtualSiteHandler, and we don’t know whether there will be virtual sites there beforehand. ParameterHandler DEPENDENCIES rely on specific classes – This would make it hard to implement eg. a custombondhandler, since others won’t consider it a dependency, and sometimes it’s unwanted to subclass the basic BondHandler JW – What if we never let handlers have dependencies? SB – Sometimes this is necessary – partial charges need to be known before vsites are added. SB - Could let all handlers modify the topology first, then have them assign physics values. But this doesn’t solve the vsite ordering problem. JW – Agree – In addition to create_force and postprocess system, we could have an initial modify_topology step SB – That could be useful, but the general point is that having as much of the logic split out into overridable functions would be immensely useful JW – Nervous about a refactor that exposes a bunch more classes – This would make our interface with extensions more brittle. Internal refactors on our end could break other people’s code. SB – Fully copy-pasted code would also be dangerous, since it’ll miss out on bugfixes. Maybe a model like public/protected/private method hierarchy → Things where we don’t want to have as a public contract would have __, but developer-friendly methods could be protected with a single _. A general way to define input or output dependencies? Ie, what if there’s a dependency on a custom handler that I don’t know exists when I’m writing my handler One idea would be to never let handlers list dependendencies and just have them play with the state of the topology if communication is needed Another idea is to not have dependencies listed as explicit classes, but rather have each handler allowed to “mark” the topology with some sort of signature that other handlers could see (and the marks that a handler could make would be inspectable before it runs) If we made the statement “Handlers never need to know about each other during parameterization, they only need to know the state of the topology, and they’re all allowed to modify the topology”, does this funcitonally make anything different? IT seems like it’d lead toa situation where in reality two handlers do need to know about each other, but we force people to change their language and say “oh, well they’re not allowed to know about each other at parameterization-time, so this must, by defninition, be topology modificaiton, since they really do need to talk”, and topology modification will just become a queue of commands/parameter modifications that get stored and executed at parameterization-time.
In places where a handler loops over all particles and does the same thing, that code should be separated out to be more easily subclassable Could have an abstract base class for common things (like vdWHandler), where a base class might not expose stuff like cutoff or mixing rules, to make it easier for custom handler developers to have a starting point. Handler compatibility – What if my handler should be raise be incompatible with the presence of another handler during FF construction / be incompatible with a certain parameterization-time action of another handler / Overwrite another handler Logic is hidden away – Eg, looking at box vectors to decide whether system is periodic, cutoffs that other handlers should know about, etc Bugs – switch_width never used, vdW cutoff different from electrostatics cutoff
Molecule.add_X_virtual_site
JW – A huge amount of complexity comes from the fact that we can add vsites to a molecule, before it’s been parameterized. SB – This isn’t a necessary API point for me
Pre vs. post-parameterization topology? In an OFF System, should something like a partial bond order live entirely in the parameterization matrix (sparse matrix mapping parameters to slots)? Or should it live in the Topology, and the parameterization matrix just contains a reference to eg. topology.molecules[2].bonds[4].fractional_bond_order?
JW – I’ll be very happy when we change charge_from_molecules → ff.['LibraryCharges'].library_charge_from_molecule(mol)
|