Following on from the interesting thread with @slochower in #2, I'd like to bring @jchodera in to the discussion on how best to make use of OpenForceField in ISOLDE and expand a little on my medium-term plans.
At the moment, what happens when you make a selection and click play in ISOLDE is the following:
The selection is expanded to provide a soft (mobile) buffer region, and again to give a hard (fixed in space) shell of residues around that.
This selection is parameterised from scratch using forcefield.py, bundled together with all ISOLDE's custom forces, and the simulation goes ahead.
While this "just-in-time" parameterisation approach certainly has some advantages (chief among them being that it's easy), it does come with a cost in terms of startup time (not a lot, but even a second starts to feel like a bit of a drag when you're starting your hundredth local simulation). What I've wanted to do for quite some time is store the parameters as properties of the ChimeraX model itself, so that (in the absence of changes to the model topology) they only have to be searched out once. Most of the necessary framework is actually already in place: ChimeraX has its super-fast C++ Atom and Bond implementations with all properties accessible from Python via NumPy, and ISOLDE's proper and chiral dihedrals and all its restraint classes are modelled off those. Only thing really missing right now is angles, but that's a pretty straightforward extension on the same theme (which I have to tackle at some point anyway, for validation purposes). Simulation preparation would then bypass most/all of forcefield.py entirely, generating the Topology for the fragment of interest directly from the stored parameters.
It seems to me that this approach should dovetail pretty neatly with OpenForceField's parameterisation philosophy, as well as opening the door to future improvements (such as further tuning parameters based on local nonbonded interactions in important regions). It would also have some potential advantages specific to model building: in particular, it would make it easy to support truncated residues (avoided like the plague - and for good reason - in standard MD, but often a necessary evil in experimental model building - it's very common for only part of a ligand to be resolved, and placing atoms where there's no density tends to be frowned upon).
Following on from the interesting thread with @slochower in #2, I'd like to bring @jchodera in to the discussion on how best to make use of OpenForceField in ISOLDE and expand a little on my medium-term plans.
At the moment, what happens when you make a selection and click play in ISOLDE is the following:
forcefield.py, bundled together with all ISOLDE's custom forces, and the simulation goes ahead.While this "just-in-time" parameterisation approach certainly has some advantages (chief among them being that it's easy), it does come with a cost in terms of startup time (not a lot, but even a second starts to feel like a bit of a drag when you're starting your hundredth local simulation). What I've wanted to do for quite some time is store the parameters as properties of the ChimeraX model itself, so that (in the absence of changes to the model topology) they only have to be searched out once. Most of the necessary framework is actually already in place: ChimeraX has its super-fast C++ Atom and Bond implementations with all properties accessible from Python via NumPy, and ISOLDE's proper and chiral dihedrals and all its restraint classes are modelled off those. Only thing really missing right now is angles, but that's a pretty straightforward extension on the same theme (which I have to tackle at some point anyway, for validation purposes). Simulation preparation would then bypass most/all of
forcefield.pyentirely, generating theTopologyfor the fragment of interest directly from the stored parameters.It seems to me that this approach should dovetail pretty neatly with OpenForceField's parameterisation philosophy, as well as opening the door to future improvements (such as further tuning parameters based on local nonbonded interactions in important regions). It would also have some potential advantages specific to model building: in particular, it would make it easy to support truncated residues (avoided like the plague - and for good reason - in standard MD, but often a necessary evil in experimental model building - it's very common for only part of a ligand to be resolved, and placing atoms where there's no density tends to be frowned upon).