[EMAIL PROTECTED] wrote:
> Hi,
>
>
>Since there is a second alpha carbon in the second residue of the
>chain, Jmol math can be used to construct a virtual second alpha
>carbon atom by mirroring the one from the second residue:
>
> ca2 = {1:A.CA}.xyz + {1:A.CA}.xyz - {2:A.CA}.xyz;
> draw boundary_1_A PLANE PERP 180 @ca2 (1:A.CA) translucent 0.2 red;
>
>But a problem arises now with multiple models/frames:
>If no model number is provided in the calculation (as shown above),
>Jmol does the calculation using the average of all first/second alpha
>carbon coordinates.
>
>
right
>And if the model number is provided
>
> ca2 = {1:A.CA/1}.xyz + {1:A.CA/1}.xyz - {2:A.CA/1}.xyz;
> draw boundary_1_A PLANE PERP 180 @ca2 (1:A.CA/1) translucent 0.2 red;
>
>the boundary would be drawn at the same position for all models.
>
>
just make sure you have given
model 1.1
prior to that draw command. Then it will be only for that model.
>And to complicate things even more, there is a third case where the
>boundary must be drawn inside a single residue. But this can also be
>done by modifying the plane using Jmol math:
>
> draw boundary_2_A PLANE PERP 100 (2:A.CA/1) (4:A.CA/1);
> offset1 = $boundary_2_A - {3:A.CA/1}.xyz;
> point1 = $boundary_2_A[1] - @offset1;
> point2 = $boundary_2_A[2] - @offset1;
> point3 = $boundary_2_A[3] - @offset1;
> point4 = $boundary_2_A[4] - @offset1;
> draw boundary_2_A PLANE 100 @point1 @point2 @point3 @point4
>translucent 0.2 yellow;
>
>
>
very cool. That's what I like to see!
>As a workaround I am currently using implicitly the default
>"MODELBASED" otion of the draw command, which attaches the draw object
>to the model/frame currently displayed.
>
>
right -- that is the way to do it.
>But it is not optimal and doesn't work for the label attached to the
>boundary by using the following command:
>
> draw boundary_1_A_l $boundary_1_A[1] translucent 1.0 yellow "-/1.1 :A";
>
>
>
that was a bug -- it's fixed.
>The problem is illustrated if you load
>"http://www.fli-leibniz.de/cgi-bin/3d_mapping-rh.pl?CODE=1a11&VIEW=exon";
>and then select a different model/frame by entering for example "frame
>2" in the script input field.
>
>Q: Would it be possible to do calculations model specific for each
>model (at once)?
>
>
>
The solution is to allow Jmol math to do parallel calculations on a
per-model basis, then pass that calculation to draw. But your mixing of
draw commands to create new points, then using them in math, then using
them again in draw commands suggests that the best solution in this case
is a FOR loop that cycles through the models, creating draw commands as
it goes. While you can't do {2:A.CA/n}, where n is defined as a
variable, you can do {2:A.CA and model=n}. So within a FOR loop, that
would accomplish what you want to do, I think.
I'm experimenting with this parallel model math anyway.
x1 = {atomno=1}.split()
x2 = {atomno=2}.split()
makes a list of these atoms on a per-model basis, then
x = x2.xyz
is a model-based list of the xyz coordinates of atom 2, so
pt = x[3]
is the xyz coordinate of atom 2 in the third model. Or just
pt = x2.xyz[3]
does the same directly. In addition, you can do things like:
pts = x2.xyz.add({1 0 0})
where now pts is an array of points that are offset from the atom 2
coordinates in each model by (1,0,0).
Here we draw a line parallel to the atom 1 and atom 2 bond but offset by
(1 0 0) in each model:
x1 = {atomno=1}.split()
x2 = {atomno=2}.split()
draw xxxx @{x1.xyz.add({1 0 0})} @{x2.xyz.add({1 0 0})}
uses a parallel calculation involving those lists to construct a
multimodel draw object. And this can be done all in one go, if you want to:
draw xxxx @{{atomno=1}.split().xyz.add({1 0 0})}
@{{atomno=2}.split().xyz.add({1 0 0})}
Or in still a different way, where now x1 and x2 are coordinate lists:
x1 = {atomno=1}.split().xyz
x2 = {atomno=2}.split().xyz
draw xxxx @{x1.add({1 0 0})} @{x2.add({1 0 0})}
This is all set up in 11.3.40 (unreleased)
>Q: Would it be possible to allow draw objects to be defined/adressed
>model-specifically with something like "draw boundary/2 off"?
>
>
>
I don't think that's possible. It's best to create draw objects that are
model specific, I think, and then turn them on and off individually. But
the label business was a bug, and draw objects should go on and off with
what models are currently "framed".
Bob
>Regards,
>Rolf
>
>----------------------------------------------------------------
>This message was sent using IMP, the Internet Messaging Program.
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Jmol-users mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
If nature does not answer first what we want,
it is better to take what answer we get.
-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jmol-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-users
