Eric wrote:
I could well be missing something(s), but I think a simple
straightforward
solution to the handling of altLoc's should be possible.
I am eager to hear suggestions :-)
The PRIMARY objectives as I see it are:
1. Enable users to select altLocs with complete flexibility. A user should
be able to select and display concurrently e.g. altLoc A at residue 50,
altLoc B at residue 100, altLoc C at residue 150, and altLoc A at residue
200; or any arbitrary permutation.
2. It should also be easy to select all altLoc A's as a group; or all
altLoc B's as a group, etc.
3. Inappropriate covalent bonds must be avoided (no spaghetti, basket
weave, or birds nests).
These are all desirable goals.
#3 says to avoid 'spagetti' bonding.
You did not say anything about whether all the bonds must be in place.
That is, if we swap run A for run B, do we expect the bonding from the
common ' ' atoms to the altLoc runs to stay in place.
Clearly that is desirable, but it quickly pushes us back to calculating
all possible combinations ... particularly if there can be connectivity
between different runs.
[Chime can do none of 1, 2, or 3. It shows all altLocs as spaghetti.]
Jmol does not read the altLoc atoms.
These objectives seem to me to contribute to simplification of
IMPLEMENTATION as follows:
4. It is fine to handle, internally within Jmol, all altLoc A's as one
"model" (but using different selection/display syntax than for NMR
MODEL/ENDMDL models), all altLoc B's as a different "model", etc.
Permutations can be handled by selection/display commands. There is no
need
to have all possible permutations listed internally somehow.
OK
(I believe
that a long time ago I may have objected to this concept. If so, I have
changed my mind.)
Good.
5. Handling A's as a distinct model from B's, distinct from C's, and
prohibiting bonds between altLoc-models takes care of spaghetti.
Correct.
But, I strongly suspect that it will also lead to 'missing connectivity'
unless one is looking at all of the 'A's or all of the 'B's.
RECOMMENDATIONS:
6. It will often be sufficient to display all altLoc A's, then hide A's
and
display B's, then return to A's, so as to toggle back and forth. Item #2
above enables this mode of "toggling" display. Of course, if the user
wants
to toggle arbitrary permutations, they can do so using the
residue-specific
altLoc selection as in #1 above.
Correct.
It seems to me that the syntax for doing this might be complicated. As I
understand it, you are generally going to be working with runs of
sequential altLocs, not individual atoms. We may need to add some query
commands that expand a given altLoc atom to its neighbors in the same run.
7. I am in favor having all altLocs displayed concurrently in the initial
default view of Jmol.
Jmol does not show multiple models by default, so I would tend to say that
it should now show multiple altLocs by default ... but we'll see how it
turns out. I suspect that this is a relatively minor point relative to the
rest of the work.
This avoids having people be unaware of the altLocs.
On Jmol's menu could be a new AltLoc's section. The default would be "All
altLocs", with other options being A, or B, or C (listing only those that
actually exist in the loaded model). (Display of permutations would need
to
be handled with custom scripting.) Another menu item could be "animate
altLocs" which would show each "model" (A, B, C) in turn for half a second
or so. These menu options would handle 95% of people's needs, I suspect.
Let's keep talking.
Miguel
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
