compile pyrosetta under redhat 5.9 with g++ 4.1.2 and python 2.7.4

[Anonymous]

Hi,

the compilation was successful but when I run the TestBindings.py it always shows the following error.

rosetta-3.5/rosetta_source/src/python/bindings/rosetta/core/scoring/methods/__methods_all_at_once_.so: undefined symbol: _ZN4core7scoring7methods15PBLifetimeCache7set_pbpERKSsN7utility7pointer10owning_ptrINS0_25PoissonBoltzmannPotentialEEE

g++ version: 4.1.2 or 4.4.7 the same error.
python version 2.7.4
boost_version: 1.46 or 1.5.6

I tried the compiled PyRosetta.ScientificLinux-r56316.64Bit with python 2.6, it can pass the test. I just wondering how can I compile the pyrosetta that can pass the test.

Thank you,
Ting

[Anonymous]

Is there a particular reason you need a PyRosetta that corresponds to Rosetta-3.5? PyRosetta r56316 is in the middle of the weekly releases (somewhere between 2014wk5 and 2014wk9). In general, the PyRosetta revisions don’t necessarily correlate with regular Rosetta releases, so sometimes there are issues with making PyRosetta which don’t affect the non-Python usage, so don’t stop a regular Rosetta release.

We likely could figure out a way to hack the source code to get PyRosetta to compile off of Rosetta-3.5, but it likely won’t be worth the effort unless you have a need to match Rosetta-3.5 exactly.

[Anonymous]

Any version of pyrosetta is fine. It just needs to run with Python2.7. Rosetta 3.5 was chosen since it is a “big” release, and should behave well in all aspects.
If I would like to recompile the PyRosetta, which source code should I use? The source code of r56316 seems not included in the download site. Thanks!

[Anonymous]

It’s a common misconception that the weeklies are “development snapshot” releases and the 3.X releases are “production” releases. They’re both the same really, the only practical difference being the frequency of release. The weeklies get the same testing regime that the 3.X releases did, and the process of releasing the 3.X releases was basically just taking a snapshot of the development version, but once or twice a year instead of every week.

(The big difference from the 3.X releases and the weeklies is the switch from score12 to talaris2013 as the default score function — but that it happened between the last 3.X release and the first weekly was a coincidence, and not directly connected.)

As I said before, there’s isn’t really a direct correlation between Rosetta releases and PyRosetta ones – at least for the r5XXXX series. For the rXX series, they try to match a little closer to release versions, but it’s still not exactly matching.

Looking at things a little closer, r56316 is sitting somewhere between 2014wk5 and 2014wk9, and it looks like the r20 version (which can build PyRosetta on Mac, at least) corresponds to 2014wk22 (or r56873). and r14 (which can build on Ubuntu) corresponds to 2014wk18 (or r56749).

I wouldn’t necessarily recommend the latest versions (2014wk32 or 2014wk34), as I believe that there are some issues with the PyRosetta build that they’re trying to work through.

Note to compile PyRosetta yourself, instead of using the pre-built versions, you’ll have to get a license/access for the regular Rosetta release, and download the Rosetta source distribution from the regular Rosetta download site.

[Author]

Posts