Difference between revisions of "User talk:Inchoate"

From PyMOLWiki
Jump to navigation Jump to search
Line 25: Line 25:
 
Hey again,
 
Hey again,
 
I like the Covers section of the wiki!  Good addition!  You may want to black out the address labels on the magazine covers...<br>--[[User:Ojganesh|Ojganesh]] 08:46, 8 September 2008 (CDT)
 
I like the Covers section of the wiki!  Good addition!  You may want to black out the address labels on the magazine covers...<br>--[[User:Ojganesh|Ojganesh]] 08:46, 8 September 2008 (CDT)
 +
 +
----
 +
 +
Hi Jason,
 +
 +
Thanks for checking out ColorByRMSD. As for the problems, here is my take on some of the things:
 +
 +
1. You are right, there is no need to multiply the new b-factors (rmsd) by 10, as Pymol will them scale automatically.
 +
 +
2. The properties of the "aln" object as returned by "super" are not the same as returned by "align" !!! Go figure!
 +
 +
3. Reverting to "align" for generating the 'aln" object results in way faster execution time. Not surprising, as the lengths of the "stored.alnAres" and "stored.alnBres" arrays is MUCH bigger if stuffed by contents from "super"'s "aln"... :-)) But this leaves us to deal with the brain-dead "align" command, as I commented in my original script.
 +
 +
4. I think all the points you make regarding keeping user's original objects untouched etc. are valid and are essential to making this a generic script... I barely grok python (you can tell!) and can certainly use all the help I can get from the gurus! Thanks!!
 +
 +
5. Please do re-run the updated script (still based off my original code) to see the points I talk about above.
 +
 +
6. One more thing that you have noticed indirectly: What about the b-factors of residues that are not a part of the "aln" object? They will corrupt the coloring by b-factor... right? Oh, and in the final command, in the original script, I must color the final object by selecting "objectname and polymer" for b-factor coloring or else the b-factors of solvents/non-protein atoms corrupt the coloring. I updated the code to reflect this.
 +
 +
--[[User:Shiven|shiven]] 03:49, 15 July 2009 (UTC)

Revision as of 23:49, 14 July 2009

Jason, Conserning the Kabsch alogrithm.... Can you take two sets of vectors with different numbers in each set and have it loop over the larger set?

For instance, I have CA and CB positions for 4 residues (residues aren't sequential), could I find the optimal RMSD between the 4 residue CA_CB set and a another protein (well, it's own CA_CB set) ?

I haven't looked at the code, but I figured you are more familiar with it.

Thanks, Dan


Hello, I'm thinking of making changes to the GalleryImage template. I wanted to check with you about these changes before I made them:

  • I feel that the description column is unnecessary. Putting the description below the image is probably good enough. Also, for a table which stretches horizontally, in which horizontal screen space is very valuable, an extra column for this seems like a waste.
  • Does each row have to be centered? Maybe left aligning the rows is better.
  • A divider between each entry would be nice.
  • I understand why you make the GalleryImage template this way, but maybe an overhaul is necessary... Long 'What to Type' sections can easily make an entry cumbersome (just look at mine).
  • For visual pretty-ness, maybe having fixed widths for the sections? (Course this could lead to problems...)

BTW, thanks for making the GalleryImage template. I especially like the 'See Also' section, as I wouldn't have thought of adding it...
--Ojganesh 15:01, 25 August 2008 (CDT)


Hey again, I like the Covers section of the wiki! Good addition! You may want to black out the address labels on the magazine covers...
--Ojganesh 08:46, 8 September 2008 (CDT)


Hi Jason,

Thanks for checking out ColorByRMSD. As for the problems, here is my take on some of the things:

1. You are right, there is no need to multiply the new b-factors (rmsd) by 10, as Pymol will them scale automatically.

2. The properties of the "aln" object as returned by "super" are not the same as returned by "align" !!! Go figure!

3. Reverting to "align" for generating the 'aln" object results in way faster execution time. Not surprising, as the lengths of the "stored.alnAres" and "stored.alnBres" arrays is MUCH bigger if stuffed by contents from "super"'s "aln"... :-)) But this leaves us to deal with the brain-dead "align" command, as I commented in my original script.

4. I think all the points you make regarding keeping user's original objects untouched etc. are valid and are essential to making this a generic script... I barely grok python (you can tell!) and can certainly use all the help I can get from the gurus! Thanks!!

5. Please do re-run the updated script (still based off my original code) to see the points I talk about above.

6. One more thing that you have noticed indirectly: What about the b-factors of residues that are not a part of the "aln" object? They will corrupt the coloring by b-factor... right? Oh, and in the final command, in the original script, I must color the final object by selecting "objectname and polymer" for b-factor coloring or else the b-factors of solvents/non-protein atoms corrupt the coloring. I updated the code to reflect this.

--shiven 03:49, 15 July 2009 (UTC)