Technology Linux
•

Rosetta 3.2 with Ubuntu 11.04

Rosetta is a very useful program for the prediction of protein structure, folding and interactions be that docking with proteins or ligands.

However, the current version of Rosetta (3.2.1) uses SCons to compile itself on your system. This is usually fine except that these use gcc libraries 4.1 and before.

Ubunutu 11.04 considers anything before gcc v4.4 to be obsolete and you can’t install them (even with apt-get).

As a result, a small amount of hacking is required.

First get SCons. Open a new terminal window.

1

sudo apt-get install scons

Check that the file tree has been updated

1

sudo apt-get update

Now you can unzip your Rosetta download to wherever you like. I personally put new software into /opt

Change your terminal window to the correct path. So in my case

1

cd /opt/rosetta

Now in a perfect world, and according to the installation instructions you should be able to type:

1

scons bin mode=release

And Rosetta will install and compile itself. However, amongst a load of other errors you’ll see the root of the problem

1

KeyError: "Unknown version number 4.5 for compiler 'gcc'"

Now, the first thing I tried was to specify a fixed gcc version for SCons to run

1

scons bin mode=release cxx=gcc cxx_ver=4.4

But this doesn’t work as gcc v4.4 is still too new. And any version before 4.4 isnt supported by Ubuntu.

The solution

This isn’t a short or elegant solution, but it is a solution that got Rosetta to install for me. If you have any troubles yourself I recommend you head on over to the Rosetta forums.

Install zlib

Install zlib (developer version) to ensure all your necessary libraries are installed

1
2

sudo apt-get install zlib1g-dev
sudo apt-get update

basic.settings

In /rosetta_path/tools/build there is the file basic.settings

At line 203, I needed to add

1
2
3
4
5
6
7
8
9

"gcc, 4.5" : {
    "appends" : {
        "version"       : [ "4", "5" ],
        "flags" : {
            "compile"   : [ "-param inline-unit-growth=1000",
            "-param large-function-growth=50000" ],
            },
        },
    },

I didn’t change line 329 but you can for completeness if you so wish.

options.settings

In /rosetta_path/tools/build there is the file options.settings

Line 11 and 12 now read

1
2

    "cxx" : {
        "gcc"     : [ "3.3", "3.4", "4.0", "4.1", "4.2", "4.3","4.4","4.5", "*" ],

So as to include v4.4 and 4.5

util.cc

Finally and most importantly, in /rosetta_path/src/core/conformation/symmetry open util.cc. At line 357 there is an if statement. What we need to do is change the “else” argument so that the reference is correct (I’ve commented out the old line)

1
2
3
4
5
6

#ifdef WIN32
pose::PDBInfoOP pdb_info_src (new pose::PDBInfo( pose.pdb_info() ));
#else
/// pose::PDBInfoOP pdb_info_src = new pose::PDBInfo::PDBInfo( pose.pdb_info() );
pose::PDBInfoOP pdb_info_src = new pose::PDBInfo( pose.pdb_info() );
#endif

Apparently this is required as the new versions of gcc are fussier about their name references than older versions.

After which we can now go back to the terminal and type:

1

scons bin mode=release cxx=gcc cxx_ver=4.5

After some amount of processing time (~30mins on my dual core 2.8 GHz), you should be greeted with the final lines

1
2

Install file: "build/src/release/linux/2.6/64/x86/gcc/4.5/super_aln.linuxgccrelease" as "bin/super_aln.linuxgccrelease"
scons: done building targets.

Credit goes to those on the Rosetta forums for help.

Older post

Ubuntu 11.04 and MATLAB x64 C, C++ and Fortran libraries

Newer post

cwplot

Further reading for leaders

Explore the archive

Blog Technology Website Wordpress Hugo
•

Dumpster diving & retrieval of Wordpress content

Backing things up

Linux Pymol
•

PyMOL visualising e2 rotamers

This morning whilst writing some reports I wanted to show some rotamer populations of my spin label attached to the protein. Whilst MMM provides visualisation, and having had discussions with Jeschke I understand just how difficult it is to do, I do …

Technology Epr Bruker
•

Xepr license work around

Danger

Disclaimer: the author does not condone piracy but this may be used as a temporary measure

​As readers of my work-sided blog posts will be aware, I’ve had some recent problems with …

LEADERSHIP, SCALE, AND THE HUMAN ELEMENT

Principles & Perspectives

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.