Tina,
> 1. I want to superpose object1 and object2 on top of each other, and
have
> derived a rotation matrix to transform object2 by. How do I apply this
> matrix
> to all its atoms? Either I parse its PDB coordinates, multiply them by
the
> matrix, and load the object (which can be really slow), or, I specify
the
> (axis, angle) data via PyMOL's "rotate" command, which needs me to
solve
> for
> three angles from the matrix, and it's messy. Is there a better way to
> specify
> a matrix to be multiplied to the atom coordinates?
I recently posted some information on transform selection which should
help with this...
See "RE: [PyMOL] Applying a rotation matrix to coordinates"
> 2. I have a series of commands in a python script to highlight
secondary
> structures:
>
> cmd.do(" util.ss")
> cmd.do(" color red, ss h")
> cmd.do(" color yellow, ss s")
> cmd.do(" color blue, ss l+''")
>
> I found the "color" commands race ahead of util.ss and some odd color
> schemes
> show up. I tried "cmd.sync(timeout=5.0, poll=2)" with numerous
> combinations of
> timeout and poll after util.ss but it still happened. Now I'm using
> time.sleep(1.5), which does block the main thread till util.ss
finishes,
> but
> it isn't nice for the program to "freeze" for the 1.5 seconds. My
question
> is:
> why does the sync command not work as expected? This race condition
> doesn't
> occur if the commands are put in a PyMOL script or program (I guess
there
> is
> only one thread of execution in those cases?).
I'm having problems reproducing this problem with the development
version of PyMOL, so the problem may be fixed. However, problems with
synchronization of cmd.do have sometimes occur in multithreaded
environments. For this reason, I recommend calling API functions
directly (cmd.color, util.ss, etc.) instead of passing statements
through cmd.do.
Your code will run faster that way too, since you skip the complex PyMOL
parsing loop.
Cheers,
Warren
