add removeAtom, removeResidue, removeChain, removeBond to app.Topology about openmm

[peastman]

I think Modeller.delete() is exactly what you're looking for.

[rmcgibbo]

I want to remove atoms from a topology that I have no positions for. I guess I could give fake positions to modeller, but that seems silly.

[peastman]

Modeller doesn't care what positions you give it. It edits the topology and positions at the same time, because often you do have positions you need to keep in sync. But if they're fake positions that you'll never look at, it doesn't care.

[jchodera]

I think I would use these methods. Sometimes we need to manipulate topologies without necessarily having coordinates.

Alternatively, we could propose that Modeller add a method to build coordinates from any existing coordinate data and idealized internal coordinates.

[jchodera]

Modeller doesn't care what positions you give it. It edits the topology and positions at the same time, because often you do have positions you need to keep in sync. But if they're fake positions that you'll never look at, it doesn't care.

If the positions are irrelevant in making these operations, why shouldn't Topology also support these kinds of manipulations?

[rmcgibbo]

It's definitely possible to access this functionality now via Modeller -- but IMO it would be nice to have the symmetry of the remove methods, since Topology has addAtom, addResidue, etc.

[tjlane]

I'll also use whatever comes out of this. Agree w/ @rmcgibbo that having more finely divided methods is a bit more intuitive. That said I think it's a small deal!

Good to know about Modeller.delete()

[peastman]

If the positions are irrelevant in making these operations, why shouldn't Topology also support these kinds of
manipulations?

We can't actually remove pieces from an existing Topology. That would break all sorts of things. For example, every atom, chain, or residue has an index field that would no longer be valid. That's why Modeller creates a new Topology for every editing call, leaving the old one unchanged.

[kyleabeauchamp]

But we could have member functions that return a new topology. They could
accept coordinates as an optional input as well...

[peastman]

Yes, but why would we want two completely independent but parallel topology editing facilities? That would just add complexity and create confusion. What problem is this supposed to solve?

Also, can you imagine the confusion that would ensue from having a removeAtom() method on a Topology object that actually leaves the object unchanged, returning a new object? That's certainly not what I would expect a method like that to do.

[rmcgibbo]

@peastman: It would be straightforward to maintain the invariants when removing an atom. You would have obviously have to reindex the remaining atoms. It is not impossible. But clearly returning a new topology is the wrong solution -- that's what modeller is for.