- This topic has 10 replies, 6 voices, and was last updated 9 years, 9 months ago by Anonymous.
September 10, 2012 at 11:06 pm #1404Anonymous
How can I send the output of PyRosetta to a PyMOLPyRosettaServer on another computer?
The PyMOL_Mover does not have a ‘link’ object to specify the ip address and port, as is suggested in the tutorial: http://www.pyrosetta.org/pymol_mover-tutorial
from rosetta import *
pose = pose_from_pdb("test_in.pdb")
pymover = PyMOL_Mover()
pymover.link.udp_ip = "127.0.0.1"
AttributeError: 'PyMOL_Mover' object has no attribute 'link'
pymover.link.udp_port = 65000
AttributeError: 'PyMOL_Mover' object has no attribute 'link'
I also haven’t had any luck with the PyMOL_Observer class, which also seems not to possess any way of specifying the ip and port of the remote computer.
September 11, 2012 at 2:08 pm #7778Anonymous
Which version of PyRosetta are you using? The PyMOL_Mover has been updated recently; the tutorial refers to the most current versions.
September 12, 2012 at 3:51 pm #7787Anonymous
Just double checked: the m = rosetta.PyMOL_Mover() should definitely work in latest releases. Which OS/PyRosetta version do you use?
September 12, 2012 at 3:54 pm #7788Anonymous
Also, please double check how exactly you construct your mover object, ie rosetta.PyMOLMover() (without underscore) is actually a different class)
February 3, 2014 at 8:26 pm #9748Anonymous
I can confirm that the above example does not work under PyRosetta Ubuntu 12.04 r56252 64-bit. Apparently the linux version does not have the link attribute, and the IP (127.0.0.1) and port (65000) seem to be hard-coded into the C++ code. This should be specified in the PyMOL_Mover Tutorial page. As I saw in the source code the link attribute only works in the Windows version.
February 4, 2014 at 10:27 am #9753Anonymous
Sorry, my bad, it works in the ubuntu pre-compiled version. What does not work is PyRosetta compiled from the Rosetta 3.4 suite. Which leaves me with another question, is it possible to build an equivalent of a certain PyRosetta release from the Rosetta sources?
February 17, 2014 at 6:35 pm #9817Anonymous
The reason for recompiling is that SymmetricFragmentMover and MaxSeqSepConstraintSet are not compiled by default due to a modification in the IncludeDict file (for the first the header is set to False, for the second the path is incorrect). This is also true for the most recent (2014wk05) version. I am not sure if it’s a bug or a feature.
I have the build environment deployed, and can build PyRosetta now without problems. For reasons of reproducibility it would be nice if I could actually build the binary versions, e.g. “r56252” but I think in order to pull code from the Rosetta github repo you need to become a developer (or maybe I was doing something wrong). I could also use 2014wk05 but then I would be more off-sync from the binary version.
“The binaries are the newest Rosetta releases, generally having more up-to-date code than the weekly releases.” – Does this mean that r56252 is more recent than 2014wk05? I had the impression that weekly releases are weekly, and binaries are less-than-weekly.
“There is effectively no difference in a PyRosetta compiled off of recent Rosetta weekly releases versus recent pre-compiled PyRosetta releases.” – Do you mean 2014wk05 is almost exactly the same as r56252?
I’m a little confused with the versioning, but then again, I’m not an insider of development.
EDIT: I see now that the most recent binary is r56327, it sure is changing fast. Actually I think it might be better to have a versioning scheme where one could go back to any arbitrary PyRosetta version. That way I could write “this script/protocol uses PyRosetta x.y” so anyone could install that version and reproduce my results.
Sorry for taking this thread to off-topic by the way.
February 4, 2014 at 3:41 pm #9754Anonymous
It is possible, but not recommended generally. The binaries are the newest Rosetta releases, generally having more up-to-date code than the weekly releases. But there are of course circumstances that it would be needed. See this page for how to do it: http://www.pyrosetta.org/documentation#TOC-Building-PyRosetta-from-source
February 4, 2014 at 3:43 pm #9755Anonymous
Yes, although it’s somewhat tricky and not generally recommended.
Is there a reason you want to compile your own, as opposed to using a recent pre-built PyRosetta weekly? (There is effectively no difference in a PyRosetta compiled off of recent Rosetta weekly releases versus recent pre-compiled PyRosetta releases.)
February 17, 2014 at 8:09 pm #9822Anonymous
Regarding the rXXXXX naming convention, the number increments once for each change that’s made to the “master” version of (Py)Rosetta. Generally this is about 3 per day or so, but sometimes we go a while without a change, and sometimes there’s a flurry all at once.
Note that “change” here doesn’t necessarily mean a significant change. For example, over this latest weekend there were a series of 7-or-so commits, all of which have absolutely no bearing on the functionality of (Py)Rosetta, being involved instead in the compiling and testing frameworks. Unless you’re attempting to track the bleeding edge of Rosetta protocols, or you have a bug that a developer *just* fixed for you, there usually isn’t all that much difference in Rosetta versions several weeks apart. (Occasionally someone will release a burst of new functionality, but often a regular (Py)Rosetta user isn’t going to take advantage of that yet anyway.)
Regarding your specific versions, r56252 dates from 2014-02-11, whereas r56252 dates from 2014-01-19 (“dates from” meaning what’s the date of the latest change to the master version that it involves, rather than when it was packaged or when it was released). In comparison 2014wk05 dates from 2014-01-31 and is more-or-less identical to a hypothetical PyRosetta r56289. Basically what happens is that periodically the “master” branch of Rosetta is taken and either edited to a regular Rosetta weekly release or compiled to a PyRosetta release. What you’d be doing by compiling PyRosetta off of 2014wk05 would be almost entirely identical to producing the hypothetical PyRosetta r56289. One’s not necessarily more recent than the other – it just depends on when they get pulled and deployed. You’re correct that you need to be a developer to pull from GitHub, so you’re “stuck” with the versions which are released.
Regarding modifications in the IncludeDict, if something is available in the Rosetta weeklies but is commented out in the PyRosetta releases, chances are that there’s a significant issue with producing a PyRosetta version. Sergey has worked rather hard to make almost all of Rosetta available through PyRosetta, so if functionality has been commented out, chances are it wouldn’t work even if you uncommented it and compiled from the weeklies. — Please let us know if that’s not the case, though.
February 18, 2014 at 2:01 pm #9825Anonymous
Thanks for the update! Yes, I’m familiar with the rXXXXX style versioning. The only (even if minor) inconsistency I see is that the binary versions are not built from the 2014wk05-style versions. Which means you cannot get exactly the same versions, even if there’s not much difference between them. I guess this is more a conceptual issue than practical.
There might have been problems in earlier versions about the SymmetricFragmentMover and MaxSeqSepConstraintSet, but I managed to build them from the official rosetta3.4 bundle by modifying IncludeDict and they seem to be working. I’m using them in a pyrosetta re-write of the membrane abinitio protocol (with constraints), and even though I have not done any thorough testing, I haven’t had any errors so far. Judging from the .cc and .hh files I don’t see much that could be broken. So if you have time you might give it a try to re-enable them in the source.
- You must be logged in to reply to this topic.