Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Odd topology with CDK2 l20-l21 #324

Open
adw62 opened this issue Jun 13, 2023 · 9 comments
Open

Odd topology with CDK2 l20-l21 #324

adw62 opened this issue Jun 13, 2023 · 9 comments

Comments

@adw62
Copy link
Collaborator

adw62 commented Jun 13, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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

@bieniekmateusz
Copy link
Contributor

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
Copy link
Contributor

bieniekmateusz commented Jul 2, 2023

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
Copy link
Collaborator Author

adw62 commented Jul 4, 2023

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
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants