User talk:Inchoate: Difference between revisions
No edit summary |
Hongbo zhu (talk | contribs) mNo edit summary |
||
| (7 intermediate revisions by 5 users not shown) | |||
| Line 14: | Line 14: | ||
Hello, I'm thinking of making changes to the GalleryImage template. I wanted to check with you about these changes before I made them: | Hello, I'm thinking of making changes to the GalleryImage template. I wanted to check with you about these changes before I made them: | ||
<ul> | <ul> | ||
<li> I feel that the description column is unnecessary. | <li> 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.</li> | ||
<li> Does each row have to be centered? Maybe left aligning the rows is better.</li> | <li> Does each row have to be centered? Maybe left aligning the rows is better.</li> | ||
<li> A divider between each entry would be nice.</li> | <li> A divider between each entry would be nice.</li> | ||
<li> 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).</li></ul> | <li> 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).</li> | ||
<li> For visual pretty-ness, maybe having fixed widths for the sections? (Course this could lead to problems...)</li></ul> | |||
BTW, thanks for making the GalleryImage template. I especially like the 'See Also' section, as I wouldn't have thought of adding it...<br>--[[User:Ojganesh|Ojganesh]] 15:01, 25 August 2008 (CDT) | BTW, thanks for making the GalleryImage template. I especially like the 'See Also' section, as I wouldn't have thought of adding it...<br>--[[User:Ojganesh|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...<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) | |||
== Section "file is not of required architecture" == | |||
Hi Jason, | |||
I think you added the section "file is not of required architecture" to the [[cealign]] page. I think this would be better placed back where the Mac installation is discussed because it alerts of a different symptom of the same problem. | |||
Also, I think a better work-around that doesn't mess with the system files would be this. | |||
<source lang="bash"> | |||
cd [pathname]/cealign-0.9 | |||
ln -s /usr/bin/gcc-4.0 ./gcc | |||
ln -s /usr/bin/g++-4.0 ./g++ | |||
set oldpath= $path | |||
set path=( . $path ) | |||
sudo /sw/bin/python setup.py install | |||
set path=oldpath | |||
</source> | |||
If this is reasonable, I can make the changes. | |||
<br>Regards, Mark ([[user:saper]]) 3/10/2010 | |||
---- | |||
Hi Jason, | |||
the example figures in "Ray" "not ray traced " and "ray traced" seem to be the same, both are ray traced. Maybe you still have the right version of the figure? | |||
Regards, --[[User:Karo|Karo]] 09:21, 4 August 2010 (UTC) | |||
---- | |||
Hi, Jason, | |||
I use the findseq script often. But I stumbled over some PDBs with uncommon residue names. Does it make sense to update one_letter dictionary in the script to the one similar to [http://bugzilla.open-bio.org/show_bug.cgi?id=3169 this]? | |||
Regards,Hongbo | |||
Latest revision as of 11:21, 19 April 2012
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)
Section "file is not of required architecture"
Hi Jason,
I think you added the section "file is not of required architecture" to the cealign page. I think this would be better placed back where the Mac installation is discussed because it alerts of a different symptom of the same problem.
Also, I think a better work-around that doesn't mess with the system files would be this.
cd [pathname]/cealign-0.9
ln -s /usr/bin/gcc-4.0 ./gcc
ln -s /usr/bin/g++-4.0 ./g++
set oldpath= $path
set path=( . $path )
sudo /sw/bin/python setup.py install
set path=oldpath
If this is reasonable, I can make the changes.
Regards, Mark (user:saper) 3/10/2010
Hi Jason,
the example figures in "Ray" "not ray traced " and "ray traced" seem to be the same, both are ray traced. Maybe you still have the right version of the figure?
Regards, --Karo 09:21, 4 August 2010 (UTC)
Hi, Jason, I use the findseq script often. But I stumbled over some PDBs with uncommon residue names. Does it make sense to update one_letter dictionary in the script to the one similar to this? Regards,Hongbo