UCL-CCS / TIES

Topology Superimposition based on joint graph traversal
MIT License
5 stars 1 forks source link

Odd topology with CDK2 l20-l21 #324

Open adw62 opened 1 year ago

adw62 commented 1 year ago

Hiya,

I'm rebuilding the topologies from the TIES paper but I'm having trouble with l20-l21 for CDK2. I end up with a weird ring in the final topology. I've started from the Wang 2015 input ligands, so maybe a atom name issue? This topology causes many simulations to NaN.

This is my input: input.zip

This is my output: ties-20-21.zip

And this is a visualisation of the weird bond:

topo

any ideas?

Cheers, Alex

bieniekmateusz commented 1 year ago

Thanks @adw62,

Because of the symmetry, the default algorithm is twisting the head. We used to have a function somewhere to respect the coordinates more, I'll see tomorrow if I can find it. A quick fix would be to use the right pair of atoms in that corner as the starting pair. Please leave open, this is a good case to work on.

bieniekmateusz commented 1 year ago

I changed the atoms times to GAFF type:

antechamber -i 20.mol2 -fi mol2 -o 20at.mol2 -fo mol2

And I get a slightly different image, which be default does not respect the different rotamers. So I forced it by decreased the search space and starting from the right pair on the ring, removing the issues with the symmetry:

ties -l 20at_uniq.mol2 21at_uniq.mol2 -supseed C18-C37

To get the optimal solution: different_starting_ties.zip

There is somewhere a quick solution coded for this kind of issues, where it would prioritise the coordinates. Ie it aligned the "so far superimposed" parts, and then recognise the rotamer issue. I'll come back to it and make it into a full feature.

AlexW12344 commented 1 year ago

Okay great thanks for the fix :) I will have a search for this coordinate prioritising function also.

bieniekmateusz commented 1 year ago

Sadly the function was taking into account the RMSD only when the two overlaps were of the same size. The issue is that we were not allowing returning of contradicting solutions (ie larger overlap vs smaller overlap with better RMSD). So I started a new branch where I am simplifying the superimposition and allowing to define the weights for RMSD and overlap. It's working for this case at the moment.

bieniekmateusz commented 1 year ago

A quick update here (#325). The weights have been added but they might be too general for this specific case related to the benchmark dataset.

However, I added the ability to use a cue from the coordinates so that if the coordinates are the same, the "twisting" rotamer issue will not occur. There will be an option to disable that part. It's working fine but I have to clean up the code around it!

adw62 commented 1 year ago

Nice thanks a lot! I think such an option will be helpful to rebuild the rest of data set as they all have the same coords for the common atoms.

P.S. do you have still have the TIES20 outputs (pdb and prmtop) for these Wang transformations?

bieniekmateusz commented 1 year ago

I agree, that feature will be useful for all the future tests with the benchmarking dataset. I'll finish it this weekend (there are some small changes in how the output is verified).

I do have the TIES20 output. It's stored on one of the storage systems. The only issue is that since then we added a new way of tackling the charges (ie we try a couple of combinations to find one that removes the least atoms while meeting the qnet requirement). I think that change will affect quite a few superimpositions, but I am happy to dig them out for you.

AlexW12344 commented 1 year ago

Yes I think this would even be quite interesting to consider the differences in atom selection and how this changes the result. Maybe for this do you have the individual ddG by transformation as well?

bieniekmateusz commented 1 year ago

To be frank, I was hoping to add "single topology" features in the next iteration, for which the testing would be useful, and that way avoid any of the problems with the charges that we are having.