I suggest it's far easier than that. I think this can be done with just
one model and appropriate select command functionality.
As I pointed out, the autobond business is not a problem. That's easy.
alternate conformations could in principle require different
calculations of structure, so that could be a minor complication. You
get a model with these different "parallel universes". You display what
you want to display -- all or one or a selected pair.
What's the real problem? Is it figuring out how the user can display all
the alternatives? If so, we just need to make it possible for the user
to select specific alternatives.
I'm still not clear whether "A" in one "run" corresponds to "A" in
another run. Apparently not? Chemically that makes little sense to me at
all, because you can't just go mixing and matching different parts of an
enzyme, I think. Or, maybe you can. In any case, we just need to be able
to provide a syntax that allows for whatever is appropriate, not a whole
slew of models.
Where's a data file that we can use as a test sample?
Bob
Eric Martz wrote:
On May 10, 2006, at 10:35 AM, Miguel wrote:
Some time ago I did some prototyping where I put all of the altLoc atoms
in the same model. One of the first things that I saw was that the
'autobond' code that builds connectivity just fell apart. Places where
there altLoc atoms just turned into a knot of spaghetti.
This is one of the things that made me think that it was necessary to
build separate models. But, the number of distinct models quickly
gets too
large.
I could well be missing something(s), but I think a simple
straightforward solution to the handling of altLoc's should be possible.
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.
just a select/display option, I think.
2. It should also be easy to select all altLoc A's as a group; or all
altLoc B's as a group, etc.
same deal.
3. Inappropriate covalent bonds must be avoided (no spaghetti, basket
weave, or birds nests).
no problem.
[Chime can do none of 1, 2, or 3. It shows all altLocs as spaghetti.]
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. (I
believe that a long time ago I may have objected to this concept. If
so, I have changed my mind.)
I think this is not necessary at all. Just one model.
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.
not necessary.
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.
just a select/display option syntax needed here
7. I am in favor having all altLocs displayed concurrently in the
initial default view of Jmol. 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.
the default sounds like a fine idea. the slideshow sounds very odd to me.
Bob
-Eric
-------------------------------------------------------
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=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
-------------------------------------------------------
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=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
