-
Notifications
You must be signed in to change notification settings - Fork 11
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 soft #98
Closed
Closed
Feature soft #98
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ll let you easily get energies for different lambda values, plus control lambda in a simulation. As part of this, I have also updated the minimisation interface to inherit from dynamics (so that you can minimise at different lambdas) I have also ported in the new updateProperty code, adding a convenience function to MolEditor so that the openmm interface can copy across coordinates while minimising allocation and deallocation of memory
…trajectory. This includes passing in lambda windows so that energies for different lambda values can also be saved. Also updated the code that extracts coordinates and velocies to use the faster updatePropertyFrom function.
…on arguments. Have these automatically convert to units from strings
…uring a dynamics simulation. This can be nicely output as a pandas dataframe for further processing
…l metadata, plus to have a null pointer if the Properties is empty. This should save some memory (given that metadata is almost never used) plus should speed things up a little as there is no need to allocate shared data for empty Properties objects.
…nks to properties so that they can be accessed via alternate names. This is mainly useful for merged molecules, e.g. ``` >>> mol = mols[0].edit().add_link("coordinates", "coordinates0").commit() >>> mol.view() ``` would let the `coordinates0` property be used as `coordinates` when viewing the molecule (or any other place that `coordinates` was needed)
…when it changes like this
…ctions. Added default LambdaSchedule if it is not set, plus added convenience functions that make it easier to create standard types of schedule. Fixed some bugs. Can now run free energy simulations for solvated ethane->methanol :-)
…n reality, I won't, instead relying on people minimising the system properly before running. I will update the constraints for perturbable molecules to be based on the actual coordinates of the atoms, rather than forcefield parameters
…mass of the perturbing atoms so that automatically applied constraints apply equally to both sides of the perturbation. This is important because internals that are constrained don't have their energy evaluated.
…jectories. An empty one is now created if you ask for one. Also fixed a bug in Dynamics that meant that the time in the EnergyTrajectory was the current simulation time, not the overall simulation time.
…bed internals. The code was accidentally pulling internals from the perturbed state multiple times. This fixes that bug, and adds a more complex merged molecule to the tests (zanamivir to oseltamivir) I've also updated the lever so that it can cope with missing forcefields. This will make debugging easier :-)
…ions to or from ghost atoms into custom ghost forcefields. The custom forcefield is currently just a copy of the LJ potential, but it will eventually become more complex once I've double-checked all the bookkeeping. I am currently missing a small forcefield to handle the 1-4 nonbonded interactions involving ghost atoms. Suspiciously though, the energies are correct... (which more likely signals a bug)
…aLever ;-) To make the bookkeeping easier, and avoid the expensive search over ALL exceptions in the CLJFF, I am now handling all of the exceptions for perturbable molecules manually, using the ExcludedPairs object. This lets me find the 1-4 terms involving ghost atoms more easily, and also identify and manipulate them using the lever. This is currently broken though, as I haven't excluded everything that needs excluding... Will try again another time ;-) WIP
…LJFF. This is to re-use the information that sire already has, and to also make it easier to put the full set of exceptions (with scale factors) into OpenMMMolecule. This will also make it easier to perturb these scale factors, which will be needed once we support bond breaking / making in a perturbation.
… involving ghost atoms. These now give the correct energy. The code is a little slow to now create the context (1-3 seconds) - I think because it is going over all intra-atomic pairs. I will need to explore some optimisations.
… speeds things up a bit, as we now don't need to build a large exceptions list and feed it serially to openmm. We only fully manage the exceptions ourselves for perturbable molecules.
…maps when updating coordinates / velocities. This is needed so that the results of one stage (e.g. minimisation) go back into the right property for the next stage for that perturbable molecule (e.g. the minimised coordinates go into `coordinates0` rather than `coordinates` for the perturbable molecules)
and control perturbations, e.g. ``` >>> import sire as sr >>> mols = sr.load_test_files("merged_ligand.s3") >>> mols.perturbation().view() ``` will view the perturbation as a movie in a jupyter notebook. There is an option to shrink ghost atoms. This will pull these atoms inside their connected atoms as they become ghosts. The animation looks cool, and really helps visualise what is happening across lambda. I just need to find a way to control the colors / sizes of the atoms in nglview, plus also specify the bonding myself rather than having nglview work it out automatically.
…morph` module. Broken out the functionality to shrink ghost atoms to a new `shrink_ghost_atoms` function. Initial testing suggests that 0.6 A is a reasonable default length (shrinks without leading to NaN errors) Added soft core LJ potential, using a per-atom shift_delta parameter that will be scaled with lambda :-) Added this to both the CLJ force and NB14 force.
…have full LJ and coulomb softening, which seems to work well. Added option to `SOMMContext` to return energies in sire units. This is switched on by default, as I have surprised myself too many times with units errors ;-)
…venience arguments, plus better API docs
Closing as this is superseded by PR #105 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR brings in a softening potential to the free energy code so that energy changes related to creating or deleting ghost atoms are smoothed. This also adds in the new
EnergyTrajectory
class that keeps track of the potentials energies at different lambda windows, and the newsire.morph
module that adds convenience functions for working with perturbable molecules.There is also the new
link
API that lets you add symlinks from one property to another.I've added in a new tutorial chapter that describes most of the new code. This tutorial needs work, and will be completed as we finish the free energy code (e.g. working out how we will create the merged molecules in BioSimSpace, how to add restraints etc).
Changes proposed in this pull request:
devel
into this branch before issuing this pull request (e.g. by runninggit pull origin devel
): [y]Suggested reviewers:
@mb2055, @lohedges
Any additional context of information?
I am going to move now onto
feature_restraint
which will branch from this PR. I've submitted this so that you can build on the new code, plus hopefully have more stable MD simulations ;-)