-
Notifications
You must be signed in to change notification settings - Fork 15
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
Feature Multiple Distance Restraints #178
Conversation
This includes specifying the format of the restraints dictionary and implementing the numerical correction.
Allow correct SOMD config and pert files to be written for multiple distance restraints. Accompanying tests have also been introduced. This involved introducing an additional perturbation type "release_restraint", used exclusively with multiple distance restraints to remove all distance restraints but the "permanent" distance restraint.
Ensure that "endmolecule" is written for all SOMD pert files, and make the tests on the SOMD pert files more detailed (added checks for start and end atom and molecule lines).
Increase the number of directional clusters until the restraint search succeeds or hits the maximum.
Thanks, @fjclark:
Since the same tests passed during the CI here, I can only assume that locally you are testing against outdated versions of Sire and BioSimSpace? The |
Yes, thanks - I had pulled the changes but forgotten to reinstall Sire (they now pass as expected). |
Thanks - we are about to release 2023.4.0 (likely end of this week or early next week - it will depend on when we squash these last bugs). Do you want this included in 2023.4.0? Or do you want more time to test it? I don't mind either way and am happy to review and merge this this week if you are happy for it to be included. |
I think @xiki-tempula might like to test this implementation soon, so I guess it might depend on whether he'd prefer that to be in 2023.4.0, or 2024.1.0.dev (or whatever it is). |
2023.4.0 would mean we could further test and then fix bugs as part of 2023.4.1+. Going for 2023.5.0.dev would mean that it will be stuck in the dev package until we release 2023.5.0 (end of December). The risk of going early is if this regresses or breaks existing functionality in any way. Do we have good regression tests for this code to demonstrate it will be safe to merge? |
Thanks for informing me. I'm fine either way but I noticed that the implementation for the new restraint is for SOMD only and our pipeline currently only supports Gromacs, so I might not be testing it in the near future. |
Thanks very much. I think slightly more time to test it would be best. I'll also look into implementing this in Gromacs. I'll let you know once I've done this. |
@fjclark Thanks |
I reviewed and merged in the sire part of this so that it would make 2023.4.0 (sorry for not seeing the above first). The changes looked orthogonal to existing functionality, so relatively safe to include. I agree to wait for the next release for the BioSimSpace part - this will give you more time to test the interface before making this feature more public. |
This is done by using restraint potentials (function type 10) for the flat-bottomed restraints which are affected by lambda- restraint, and a distance restraint for the permanent restraint which is not affected by any lambdas. See https://manual.gromacs.org/documentation/2019-rc1/reference-manual/topologies/topology-file-formats.html#id31 for details. Note that the distance restraint requires the force constant to be written to the mdp file.
Hi @lohedges, I've now finished implementing this for SOMD and for GROMACS and have validated both implementations by comparing with Boresch restraints. In both cases, I ran 5 independent replicates of the bound leg with each type of restraint and the errors are 95 % t-based confidence intervals: SOMDBoresch Multiple Distance Restraints However, I observed a couple of crashes during the release restraint stage. To investigate these further, I ran 90 release restraint windows (10 replicates of 9 windows), and observed 10 crashes: These crashes are sometimes observed when there are no restraints, and seem to occur much more frequently with open force fields compared to GAFF. As no crashes were observed with GROMACS, this seems to be a strange SOMD bug. More discussion is given here. For now, I've added a warning about potential instabilities whenever multiple distance restraints are used with SOMD. GROMACSBoresch Multiple Distance Restraints OverallThere is no evidence for a significant difference between Boresch restraints and multiple distance restraints for either engine. @lohedges and @xiki-tempula, once you're happy with this PR I'll add a section to the tutorials showing how to use these. It's slightly different to Boresch restraints for GROMACS as a) The user has to specify |
This requires the changes to BioSimSpace implemented here: OpenBioSim/biosimspace#178.
That’s great work ! There seems to be a surprising difference in precision between the two engines, something to think about. |
Thanks @fjclark. Given the tests pass and this only touches sandpit functionality, I'd be happy to merge. Perhaps @xiki-tempula would like to check that it doesn't cause any issues with the internal Exs test suite before merging? |
I have skim through the PR and I think it looks ok. |
Is this pull request to fix a bug, or to introduce new functionality?
This PR introduces functionality for setting up and running ABFE calculations with multiple distance restraints. This requires the functionality in this Sire PR.
If this introduces new functionality...
Changes proposed in this pull request:
devel
into this branch before issuing this pull request (e.g. by runninggit pull origin devel
): yWhen testing locally, all tests that I've added or that are related to functionality that I've changed pass. However, the following tests fail:
Suggested reviewers:
@lohedges, @chryswoods
Any additional context of information?
As shown in the Sire PR, so far my tests show no evidence of a significant difference compared to Boresch restraints. My test input scripts are here.
Thanks very much.