TIES: The ring nature changes: which affects all atoms in the ring.

[bieniekmateusz]

Hi @ridassaf and @shunzhou

As requested by Peter. This is an important task for automating TIES more fully.

Problem: When a part of a ring mutates, it can change the type of the bonds in the ring. When that is the case, the entire ring is different. Meaning these atoms will mutate into similar atoms that have different bonds. This could mean a carbon mutating into a carbon.

The correction to this will be similar to what we do with electrostatic charges. We first superimpose atoms, and then we remove the matched pairs in cases where the charges are different. Similarly here, the rings will be post-superimposition stage.

You need for this @shunzhou to help design example situations. I'll provide some sketches. I would suggest to do this. Sketch several examples (with @shunzhou ), add them as test cases. These will overlap the two molecules first properly. Then it will apply the "ring check filter" and see that the right rings have been removed.

You might want to start with "test_overlayer.py" which are the most basic functions. There is already some rings: test_mcl1_l12l35

After this task we'll proceed to mutations that divide the graphs.

Thanks

[bieniekmateusz]

For the sake of completeness, @shunzhou , would it be possible to provide/discuss the examples here? Thanks

[shunzhou]

Do we need to consider the differences in bond type? When bond type is different, the type(s) for the one or both of the atoms is/are different, and should be excluded as common.

We may need to consider if we want the entire ring to be changing part.

[bieniekmateusz]

We currently keep track of the bonds. And that is another case that I forgot about. So we might start from that.

Ie if a single bonded oxygen changes to a double bonded oxygen, then it should be mutated. Currently, this will be picked up because of charges: but for the test case, this will be different.

I'll create another issue and start from the bond type. This will be easier to start with.

[bieniekmateusz]

Moving the discussion here from slack.

_overlay is the basic unit. That superimposes the molecule having one point on each graph.

_overlay is called by another "hidden" function: _superimpose_topologies. This one is a bit messy, but it tries to call all possible starting points. And then it tries to reduce their number to the minimum (ideally 1 overlap, ie 1 suptop). However, if there are different components in the graphs, it should return the different components overlapped.

_superimpose_topologies is called by another master function. That's superimpose_topologies which is meant to be for the user. It manages the entire process. It checks the charges after the superimpositions and removes the atom pairs matched that have different charges.

This is the stage where we want to add another filter. We already have networkx cycle look up. So for this, we can use that. Right after "if useCharges" we can do "checkCycles" and apply the filter.

[ridassaf]

Where are we calling the networkX cycle lookup/storing the cycles at that point in code?

And the way the filter would work, is by removing all matched pairs in those cycles if at least one of the atoms has a different type of bond. Correct?

[bieniekmateusz]

For the charges, there is a helper function ensure_charges_match.

We could use a similar helper function for cycles. In there, we can call the suptop method .getNxGraphs or more specifically, .getCircles, which will return the circles for the left and right topology.

The different bond nature we need to look into. And ideally, @shunzhou would contribute here.

If you look at the testing test_overlayer, we carete bonds: c3.bindTo(c1, 'bondType1'), so here, for the testing, ideally we would use the real names for bonds (as determined by Amber I think). Let me add here a file with example of these bonds.

[bieniekmateusz]

Here is an example for the mcl-l8-l18 study. In this case, two file topologies are merged together in a single .mol2 file. There are the bonds and one type is 'ar' another 1 etc.

morph.tar.gz

[bieniekmateusz]

GAFF is a special forcefield from Amber for small molecuels which we use: http://ambermd.org/antechamber/gaff.html

There, you can see in the tables the different atom types.

I think I might have made a mistake - we might need to use the correct atom type, which reflect on the bonds. This will require a bit of help from @shunzhou

Also, this could be useful: http://ambermd.org/doc12/Amber18.pdf

[shunzhou]

When atom type is different, its bond type is different. This is the reason I asked you if we really need to check the differences for bond types. If atom type check not sufficient?

[bieniekmateusz]

I see what you mean. The answer to this is more tricky. Anyway, since for now we rely on atom types from amber, our current approach would not overlap rings. We'll need some test cases to define the behaviour better.

So I think this might be solved by the nature it works now.

[bieniekmateusz]

I believe we should take another approach here. I think we could take different rings from here https://en.wikipedia.org/wiki/Cyclic_compound and try to overlap them to see what the algorithm does.