Install rosetta_2014.30.57114_bundle on ubuntu-14.04.1-desktop-amd64

1) If you’ve downloaded and extracted the Rosetta source bundle appropriately, that command should work. (Although I would recommend adding “mode=release” after the “-j1” and before the “bin” to compile the release-mode version, which should run faster than the debug-mode version which will be compiled by default.)

I’m guessing the problem you’re running into is that you’re trying to run Rosetta from a Windows filesystem that you’ve mounted on your Ubuntu virtual system. The problem with that is that Windows drives don’t really understand symlinks all that well, and the magic that scons does relies on the symlink dereferencing in order to work properly. You may be able to get around that by running the script directly, as opposed to through a symlink. (So do “./external/scons-local/scons.py” instead of “./scons.py”).

Note that you may run into other issues related to symlinks, though. (For example, the bin directory is actually just symlinks into the build directory, so if symlinks don’t work, your bin/ directory may not be all that useful.) You may just want to extract and compile Rosetta on a Linux-format disk that’s “internal” to the VMware image, rather than doing so on a Windows-format disk that’s mounted from outside the image. (For example, by extracting and compiling in your Ubuntu home directory, rather than a directory under /mnt/) — That’s just for the Rosetta installation itself – you can still run a Rosetta executable stored in an Ubuntu directory on PDBs and input files that are on a mounted Windows directory.

2) An executable is a computer program that you run (See http://en.wikipedia.org/wiki/Executable) .

The “sh: 1: o: not found” means that the scons system is having difficulties finding your compiler. Did you install a compiler? The default Ubuntu install doesn’t come with one, you’d have to do something like “sudo apt-get install build-essential” to get one. You’ll also need the devel version of the zlib libraries, which I believe can be installed on Ubuntu with a “sudo apt-get install zlib1g-dev”.

Since you have two processors, doing a -j2 should make the compile go about twice as fast, as you’ll be using both of them, instead of just one. Note that your computer may become a bit more unresponsive while it’s compiling. If you’re just compiling, it should be fine, but if you’re trying to run anything else on the computer at the same time I might recommend against it.

I don’t know why you’re losing disk space on your virtual machine – I’ve never used a VMware image. You may need to ask on a VMware Player forum.

Compiling does take a bit. It depends a bit on how fast your processor is and what your disk access is like. (Much faster with SSDs, much slower on a drive accessed over a network.) For one processor, 24+ hours doesn’t sound out of the standard range. (Keep in mind that you’ll probably only have to compile once, though.)

As far as disk space, a release mode build should take somewhere around 1 GB, on top of the 2+ GB that the source files themselves take. (This will vary somewhat based on the compiler.) A debug mode build will take quite a bit more, somewhere around an extra 8 GB.

Compiling Rosetta does take a bit of computational power – I wouldn’t gauge the amount of power you need to run Rosetta based on the amount needed to compile it. Some things (scoring, basic packing, etc.) will work fine with just 2 cores. Others (like ab initio) need a lot more power, and for production runs really need a multi-node cluster for practical use. (Though you can do short test runs on your local machine to make sure you have everything set up before launching them on the cluster.) I’d say the ddg_monomer protocol falls on the easier end of the spectrum. I think you should be okay with a 2 core machine, although you may be limited in the number of mutants you can test in a given time frame.

Regarding Rosetta vs. PyRosetta, it depends heavily on what you want to do. Some of the established protocols have been set up for “regular” Rosetta, and don’t have an easy interface through PyRosetta. On the other hand, you’re limited by the options the protocol originator gave you, so PyRosetta can be useful if you want to go outside those limited options. Also, with the PyRosetta workshops (http://www.pyrosetta.org/tutorials) PyRosetta is better documented for basic, internal functionality of Rosetta, whereas the documentation for regular Rosetta is currently focused around using the canned protocols, with less concentration around the “internals” of Rosetta.

So it depends on what you want to do. If you just want to use already-developed protocols, the regular (commandline) Rosetta build is probably a better bet. If you’re more interested in building or altering protocols with the available components of the Rosetta libraries, PyRosetta would likely be a better place to start. (Not that you can’t do either or both with either or both, it’s just a little harder sometimes.)

A -j2 run wouldn’t help – in fact it would probably make things worse. That error means you don’t have enough memory on your system, so having two CPUs attempting to use memory simultaneously would only make it run out faster.

There’s several things you can try. The first is to attempt to shut down all non-essential items on your machine. If you have other programs running beside the compile, try closing them and see if that helps. There may also be an issue with the graphical system on your Ubuntu machine using up memory. Instead of logging in to the graphical desktop environment and then opening a terminal, see if you can log in to a command prompt directly. You may also be able to change the settings on your VMware Player to give your Ubuntu image more memory.

A final thing you can try is to set up or increase the swap space on your Ubuntu machine. There’s ways to add/increase the size of the Ubuntu swap file, which should increase the “virtual memory” size, although using the swap file instead of main memory will likely slow the machine down further.

“Rosetta/main/bin” is a typo – it should be “Rosetta/main/source/bin”

Rosetta doesn’t install in the system locations – it stays within the directory where you installed it. When you downloaded Rosetta, you went to the main/source/ directory in order to compile it. In that directory is a bin/ directory which houses the executables. (None of which are named rosetta, by the way.)

You can either use an explicit path to that directory to run the commands:

lanselibai@ubuntu:/home/lanselibai$ /home/lanselibai/rosetta2014.34/main/source/bin/relax.linuxgccrelease @options

Or you can put that directory in your PATH environment variable and be able to use the executable directly. Either way will work – I tend to use the explicit path, as I have multiple versions of Rosetta going at once, and that way I can control which one I use when.

This is a Unix issue, rather than anything Rosetta specific.

By default Unix look in the current directory for programs to run. If you just give a command by itself, it will only run programs that are in the system executable search path. If you want to run a program that’s not in the current search path, you need to to explicitly give the location where the Unix commandline should find it. This can either be an absolute path :

lanselibai@ubuntu:~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin$ ~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin/relax.linuxgccrelease

Or it can be a relative path (starting with the current directory represented by “.”)

lanselibai@ubuntu:~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin$ ./relax.linuxgccrelease
or
lanselibai@ubuntu:~/Cheng$ ./rosetta_2014.30.57114_bundle/main/source/bin/relax.linuxgccrelease

When running Rosetta, it’s best to make a new directory for each run, and launch your Rosetta run from within that directory. This means that supplying the absolute path when running the executable is usually the easiest way of doing things.