Update topology against parts of other objects

[mattwthompson]

Stemming from a discussion @rmatsum836 and I just had -

The current convert/ module is designed to make a new object from another one, i.e. making a new topology from a mb.Compound that already exists. What if instead of making a completely new object, we allowed part of one to be stored into the other? Like update_coordinates in mbuild but between two objects instead of from disk.

• I have a topology with the metadata/hierarchy/forcefield/etc I want but I had to initialize everything at the origin, I want to use mb.fill_box to get a reasonable starting configuration.
• I have a Compound that has the hierarchy I want, but for some reason all the other information of my system is contained in a topology.
• I have a pmd.Structure that includes everything I want, but the non-LJ potential I am forced to use is only supported by topology.

In each case, making a completely new object either would lose some important information, and instead we'd just want to take a part of one and put it into the other. Seem doable piece-by-piece, or crazy?

[ahy3nz]

It's an interesting idea, but I have doubts about how "modular/generalizable" this sort of thing could be. An update coordinate function could be nice, but doing something as niche as "specifically copying the Mie potential parameters for indices [0, 100)" might be hard to make general. Here's a jumble of thoughts

• I think update coordinates could be nice feature, but maybe not super high on the priority list compared to expanding functionality in the topology data structure - if a user wanted to, he/she could easily put together their own code in the meantime to stitch together the different data structures
• Maybe something about updating bonds/angles/dihedrals/nonbonded interactions based on particular atom/site indices? I guess this assumes a direct 1-1 corespondence
• Would someone want to go from topology to a structure? If a topology contains everything a pmd.Structure has, and we have our own writers, then a pmd.Structure is almost an unnecessary intermediate
• Also, it seems like the "common" workflow is to go from mb.Compound -> topology. Furthermore, a particular point of topology was to avoid all this unnecessary hopping between openmm.Topology, parmed.Structure, openmm.System etc. I can imagine there might be some circumstances people WILL want to hop between these different datastructures, but it's important to keep the goal in mind

[mattwthompson]

have doubts about how "modular/generalizable" this sort of thing could be.

It's probably a fool's errand to try to handle this generally, but I think it may be useful in some specific cases as they arise.

• Agreed

• Maybe? I don't really understand what you're after in this one.

• In the long term, there should be no reason to. But as it stands, ParmEd has some writers we don't have, and some (CHARMM?) that we have no immediate plans to support.

• Agreed, this idea is more about edge cases than core functionality.

[mattwthompson]

One way this could take place is with some arguments that specify parts we do and don't want to be updated, i.e.

# if you wanted to use positions from something else, like mb.fill_box
top = from_parmed(parameterization=True, positions=False, connectivity=True) 
# if you wanted to grab parameters from something else
top = from_mbuild(parameterization=False, positions=True, connectivity=True) 
# if you wanted to grab only the connection graph to be passed to foyer's atomtyping routines
top = from_parmed(parameterization=False, positions=False, connectivity=True)