Page Comparison

Architecture of VSites

• JW – Are vsites assigned parameters, or part of a topology?

  • Assigned parameters

    • They’re created by the parameter assignment step

    • They can’t have their coordinates meaningfully set by users

  • Part of topology

    • Output formats expect them to be listed as particles

    • Users probably want to ASK them what their coordinates are

  • TG – Generally agree, but there are other variables stored by vsites, like weights and the properties that are used to calculate the coordinates – Are those part of the topology?

    • JW – I’d say those are assigned.

    • TG – In a recent PR, I made things like weights be properties of a particular INSTANCE of a vsite attached to a specific molecule.

    • TG – Generally I think it’s sketchy for the vsite to be separated from the moelcules – Things like orientation and the local frame are very particular to a specific instance of a molecule, and separating them can have undesired effects.

  • SB – More details on issues?

    • (General) – There are two kinds of info – Scalars in local frame (like angles, weights, and distance) must live on specific INSTANCE of vsite, but weights could be attached to a class or other higher-level object.

    • MT – Do we need a new class/type for every vsite, or can we get away with 4 classes (for the 4 vsite types)

      • TG – The orientations are also important – This records “handedness” of vsites. Like, if a parameter could equally well assign a vsite on either side of a plane, the orientation records the specific atom order to put it on the correct side of the plane.

    • SB - Does atom ordering encode handedness?

      • TG - Yes

    • SB - Parameters (“scalars”) encoded in force field/XML, atom ordering encodes handedness, other details specific to each type/class of virtual site can be stored in something akin to a class attribute

  • TG – If we never want to change a SINGLE instance of a vsite, but always propagate changes across ALL instances of that vsite, then does that work in this design?

  • JW’s vote: They’re assigned parameters

    • SB (Thumbs up)

• JW – Should vsites be allowed to be set pre-parameterization?

  • Pre-parameterization vsite creation is most closely analogous to charge_from_molecules – Is there a similar pattern that we can follow to LibraryChargeType.from_molecule to make vsite parameters from a molecule with vsites? Or something like that interface?

• More concrete proposal: https://docs.google.com/presentation/d/1vR-3pDBz-sG-vENcqm3iXGIBx-X-iRQjn_2s3qTuTN0/edit#slide=id.p

What constitutes the state that Interchange should track?

• SB - might be worth having a new VirtualSiteKey object that can be stored in the keys of the slot map

  • Might make the distinction between “internal state sufficient to generate stuff on the fly” and the export layer more clear

  • MT – This could be an alternative to the return_topology argument – Without this, anything that doesn’t go into an OpenMM Force is lost

  • MT – What should interchange.topology know that the original topology didn't?

  • SB – I’d argue that we don’t need a post-parameterization topology, because that’s what the interchange object already is. interchange.topology could just be a higher-information VIEW of the underlying Topology.

    • JW – Agree

  • SB – Regarding making changes in Topology (eg WBOs) – There’s a distinction between computer-assigned values and user-assigned values.

    • Re: charges from users, we’re looking at librarycharges, which may work.

    • For things like WBOs, …?

  • MT – This seems like a good point – The info that you would WANT in a post parameterization topology could be stored elsewhere. I don’t want WBOs to be inputs. If we can fix performance, switching things to a librarychargehandler is a great idea. But if users want to provide their OWN WBOs… I’d need to think more. Finally, pre-parameterization vsites seem to be tricky, and maybe we shouldn’t support that. On the other hand, I think it’d be valuable to have a post-parameterization topology because it could be a place to stick miscellaneous stuff like vsites. But that may not be necessary if the interchange contains all the additional info that an OpenMM system would need. So, I’ll need to think more, but this seems promising.

    • SB – Agree. This is worth trying to see if there are breaking cases.

    • JW – Agree

  • SB – My general design philosophy is to not give people what they haven’t asked for yet. So if people DO want to provide their own vsites pre-parameterization, wait for THEM to come to YOU, and then give them the best solution that will meet their use case.

    • TG – Agree with SB – my current work with recharge is helping me formulate feature requests/PR to the toolkit

Sites vs. Particles

 https://github.com/openforcefield/openff-interchange/issues/227

Which nonbonded handlers to go in?

• SB – In addition to having TopologyKey, maybe also have a VirtualSiteKey. If you have a construct that does that, then you can handle the nonbonded portions of the vsites in a special way. So the geometry rules would live in a vsitehandler, but the ESHandler would know the charges + charge increments, and the vdWHandler would know the sigma and epsilon.

  • MT – I could see how that would work. But the architecture/program order is a bit unclear. Would like to avoid need for intercommunication/out of orderness between handlers.

  • SB – As long as vsite assignment logic is deterministic, then each handler could do it by itself. So in the case of the vdWHandler, I’d allow store_potentials to take in a vsitehandler, and this would make a mix of TopologyKeys and VirtualSiteKeys. Internally these would use vsitehandler.find_matches, which would return the same matches in the same order each time.

  • JW – I think the SMIRNOFF spec needs to have things encapsulated (either VSites in Electrostatics and vdW or vice versa). Otherwise there’s no easy way to know if a vsite’s nonbonded components are appropriate/compatible with a given nonbonded handler

  • SB – I don’t think this is a showstopper. We can just raise errors in these cases. We’d have validation logic for “can this nonbondedhandler consume this vsitehandler?”

Differences between input and output topology

Timeline for refactor