-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
I changed the atoms times to GAFF type:
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:
To get the optimal solution: 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. |
Okay great thanks for the fix :) I will have a search for this coordinate prioritising function also. |
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. |
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! |
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? |
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. |
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? |
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. |
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:
any ideas?
Cheers,
Alex
The text was updated successfully, but these errors were encountered: