FAHViewer: in/dependence of "snapshot cycling" & "rotation"?
Posted: Thu Aug 13, 2020 6:36 pm
As a volunteer folder with only a general understanding of protein-folding and the GROMACS simulation software used by FAH, I wanted to ask the following (newbie?) question:
Is there any reason why, in the FAHViewer program, the "snapshot cycling" feature seems to not be fully independent of the "rotation" feature?
From what I understand, each of the 100 cycles simulated for a given WU represents a visual snapshot of the given protein's folding conformation (relative to itself) at that given timestamp. And thus, as FAHViewer cycles through the currently-completed snapshots cycles, one can generally see the various atoms, side-chains, and segments of the simulated molecule(s) move or at least wiggle with respect to the model's 3D volume bounding box.
However, the current (v7.6.13) version of FAHViewer seems to cycle through snapshot cycles only while its "rotation" functionality is currently enabled. Specifically, when the protein is rotating, one can press the "0" key to toggle-off the snapshot-cycling. (BTW: instead of just freezing the snapshot-cycling at its current cycle, it jumps to the currently-highest-numbered cycle and freezes the cycling there.) But the other way around, if one presses the spacebar to toggle-off the rotation, the snapshot-cycling also freezes, even though I see no reason why it shouldn't be able to continue "in place," without any rotation. And pressing the "+" key ("increase snapshot cycle rate") does not jump-start the snapshot-cycling, as I might have hoped. Likewise, if one unchecks the "Cycle Snapshots" checkbox in the FAHControl Preferences, then not only does the snapshot-cycling freeze, but also the rotation.
Is there any reason for snapshot-cycling to really be dependent on rotation? I would think not, and that any current dependence is simply an artifact of the current implementation. And the fact that one can drag the mouse to manually rotate any given snapshot-cycle to any desired 3D orientation, independent of the current angle of the automated rotation mechanism, only strengthens my feeling that these two visualization parameters are, in reality, inherently orthogonal.
Is there any reason why, in the FAHViewer program, the "snapshot cycling" feature seems to not be fully independent of the "rotation" feature?
From what I understand, each of the 100 cycles simulated for a given WU represents a visual snapshot of the given protein's folding conformation (relative to itself) at that given timestamp. And thus, as FAHViewer cycles through the currently-completed snapshots cycles, one can generally see the various atoms, side-chains, and segments of the simulated molecule(s) move or at least wiggle with respect to the model's 3D volume bounding box.
However, the current (v7.6.13) version of FAHViewer seems to cycle through snapshot cycles only while its "rotation" functionality is currently enabled. Specifically, when the protein is rotating, one can press the "0" key to toggle-off the snapshot-cycling. (BTW: instead of just freezing the snapshot-cycling at its current cycle, it jumps to the currently-highest-numbered cycle and freezes the cycling there.) But the other way around, if one presses the spacebar to toggle-off the rotation, the snapshot-cycling also freezes, even though I see no reason why it shouldn't be able to continue "in place," without any rotation. And pressing the "+" key ("increase snapshot cycle rate") does not jump-start the snapshot-cycling, as I might have hoped. Likewise, if one unchecks the "Cycle Snapshots" checkbox in the FAHControl Preferences, then not only does the snapshot-cycling freeze, but also the rotation.
Is there any reason for snapshot-cycling to really be dependent on rotation? I would think not, and that any current dependence is simply an artifact of the current implementation. And the fact that one can drag the mouse to manually rotate any given snapshot-cycle to any desired 3D orientation, independent of the current angle of the automated rotation mechanism, only strengthens my feeling that these two visualization parameters are, in reality, inherently orthogonal.