You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the repack function uses the SpinLabel.sample() method to sample new label conformations. This method always samples from the underlying rotamer library and not the current state of RotamerEnsemble. Because SpinLabels/RotamerEnsembles are mutable, a user may manipulate a SpinLabel/RotamerEnsemble and then repack with it expecting it to sample from the ensemble state and not the underlying rotamer library.
To avoid this confusion I was thinking of modifying how the repack function works to sample from the current state and not the underlying rotamer library when using a RotamerEnsemble/SpinLabel that has been created using AV or ORS methods.
This does bring up the issue that the ensemble state is often constructed based on fixed conformations of neighboring sidechains, when repacking alters these neighbors, the ensemble state no longer accurately reflects the energetic landscape of that label in that environment.
The text was updated successfully, but these errors were encountered:
Unclear how to think about this. Repack assumes the label rigid(ish) and wobbles around the environment, and labeling itself assumes the neighborhood fixed and wobbles the label. I a way, it would make sense to add a repack option to labeling if repacking is done based on the underlying rotamer library/AV sampling. For the separate repack function, maybe add an option to specify what to use, or make it depend on what is supplied (rotamer library vs ensemble object)?
Currently, the repack function uses the SpinLabel.sample() method to sample new label conformations. This method always samples from the underlying rotamer library and not the current state of RotamerEnsemble. Because SpinLabels/RotamerEnsembles are mutable, a user may manipulate a SpinLabel/RotamerEnsemble and then repack with it expecting it to sample from the ensemble state and not the underlying rotamer library.
To avoid this confusion I was thinking of modifying how the repack function works to sample from the current state and not the underlying rotamer library when using a RotamerEnsemble/SpinLabel that has been created using AV or ORS methods.
This does bring up the issue that the ensemble state is often constructed based on fixed conformations of neighboring sidechains, when repacking alters these neighbors, the ensemble state no longer accurately reflects the energetic landscape of that label in that environment.
The text was updated successfully, but these errors were encountered: