building rosetta 3.5 week49 on mac 10.9; hung up on testing

[Anonymous]

I am trying to build, install, and test rosetta weekly build 49
on a MacBook Pro running Mac OSX 10.9. I had upgraded from
10.6.8 and thought I had worked out all of the issues. My default
python is the Apple version.

Python 2.7.5 (default, Aug 25 2013, 00:04:04)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin

I reinstalled git but I still get a FATAL ERROR message about some issue
with git or the Conscript file.

Running versioning script … fatal: ambiguous argument ‘HEAD’: unknown revision or path not in the working tree.
Use ‘–‘ to separate paths from revisions, like this:
‘git […] — […]’
fatal: ambiguous argument ‘HEAD’: unknown revision or path not in the working tree.
Use ‘–‘ to separate paths from revisions, like this:
‘git […] — […]’

Nonetheless, the two commands below seem to finish (there are macbuild files in ./bin) but the
third command fails.

bash-3.2$ sudo scons -j3 bin mode=release
Seemed to finish normally

bash-3.2$scons cat=test j=3 mode=release
Finishes with “scons: done building targets.”

python test/run.py –mode=release -j3 -d ../database

Identifying platform…

Platform found: release/macos/10.9/64/x86/gcc/4.2/default
/bin/sh: line 0: cd: build/test/release/macos/10.9/64/x86/gcc/4.2/default: No such file or directory
Traceback (most recent call last):
File “test/run.py”, line 502, in
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 495, in main
T.runUnitTests()
File “test/run.py”, line 290, in runUnitTests
else: self.runOneSuite(lib, suite)
File “test/run.py”, line 206, in runOneSuite
f = open(log_file, ‘w’); f.write(output); f.close()
IOError: [Errno 2] No such file or directory: ‘build/test/release/macos/10.9/64/x86/gcc/4.2/default/protocols.test.directory.log’
/bin/sh: line 0: cd: build/test/release/macos/10.9/64/x86/gcc/4.2/default: No such file or directory
Traceback (most recent call last):
File “test/run.py”, line 502, in
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 495, in main
T.runUnitTests()
File “test/run.py”, line 290, in runUnitTests
else: self.runOneSuite(lib, suite)
File “test/run.py”, line 206, in runOneSuite
f = open(log_file, ‘w’); f.write(output); f.close()
IOError: [Errno 2] No such file or directory: ‘build/test/release/macos/10.9/64/x86/gcc/4.2/default/protocols.test.file.log’
/bin/sh: line 0: cd: build/test/release/macos/10.9/64/x86/gcc/4.2/default: No such file or directory
Traceback (most recent call last):
File “test/run.py”, line 502, in
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 495, in main
T.runUnitTests()
File “test/run.py”, line 290, in runUnitTests
else: self.runOneSuite(lib, suite)
File “test/run.py”, line 206, in runOneSuite
f = open(log_file, ‘w’); f.write(output); f.close()
IOError: [Errno 2] No such file or directory: ‘build/test/release/macos/10.9/64/x86/gcc/4.2/default/protocols.test.such.log’
Traceback (most recent call last):
File “test/run.py”, line 502, in
if __name__ == “__main__”: main(sys.argv)
File “test/run.py”, line 495, in main
T.runUnitTests()
File “test/run.py”, line 287, in runUnitTests
pid = self.mfork()
File “test/run.py”, line 59, in mfork
for p in self.jobs: os.waitpid(p, 0)
OSError: [Errno 10] No child processes

[Anonymous]

You shouldn’t need git to build and run the Rosetta weekly release – there’s a stage that tries to use git to figure out which version number you’re compiling, but that’s only cosmetic. The compilation will work perfectly fine without it.

The errors you are seeing are the result of the unit testing framework build signature autodiscovery not matching the build signature that actually exists. It’s trying to find the Rosetta/main/source/build/test/release/macos/10.9/64/x86/gcc/4.2/default directory, because that’s what it thinks the build directory corresponds to in your system. What subdirectory tree do you actually have under the Rosetta/main/source/build/ directory? (Both under the src/ and test/ subdirectories.)

If you’re getting executables in the Rosetta/main/source/bin directory, your build should be successful. You don’t really need to run the unit tests, unless you have the suspicion that there might be something that there’s something not quite right with your compiler setup.

[Anonymous]

Thank you very much for the reply!!

I assumed that it does it matter that I named the Rosetta directory “rosetta49”.

My eventual goal is to build PyRosetta hence my worries about everything being set up correctly.

“It’s trying to find the Rosetta/main/source/build/test/release/macos/10.9/64/x86/gcc/4.2/default”

I see that the there is a difference in compiler names: clang vs. gcc

./build/test/release/macos/10.9/64/x86/clang/5.0/default

./build/src/release/macos/10.9/64/x86/clang/5.0/default

[Anonymous]

Thank you for the advice on the unit tests. The 1375 tests took only about 20-30 minutes.

python test/run.py –mode=release -j3 -d ../database –compiler=clang

Total number of tests: 1375
number tests passed: 1373
number tests failed: 2
failed tests:
core.test: RotamerTrials:test_rotamer_trials
core.test: SymmetricRotamerTrials:test_symmetric_rotamer_trials
Success rate: 99%

---

End of Unit test summary
Done!

The problems with the rotamer trials seems serious. Should I be concerned?

[Anonymous]

Oh, yes. That’s because the most recent MacOS versions have switched from gcc to clang.

There’s nothing wrong with that (many of the Rosetta developers actually prefer clang). The one thing you’ll need to be aware of, though, is that the compilation ending will be different — i.e where examples may have an executable “relax.linuxgccrelease”, you’ll have something like “relax.macosclangrelease” instead.

If you do want to run the unit tests, you can force it to use the clang build as opposed to gcc by giving the run.py script the “–compiler=clang” option.

(BTW, it shouldn’t matter what you name the top level directory – Rosetta, rosetta49, super_secret_program_dont_touch – they all should work, as long as you give the appropriate path when you need to provide the path.)

[Anonymous]

No worries. This unit test fails often and should be fixed at some point soon if it’s not already in the dev version. The code is fine. It’s measuring angles and sees a difference from the set value its comparing (a minute difference) and freaks out:

old: residue = 18 chi = 4.43369718274366e-13
new: residue = 18 chi = 360
In RotamerTrials::test_rotamer_trials:
./test/UTracer.hh:100: Error: Test failed: “360!=4.4337e-13 [abs_tolerance=0.01, rel_tolerance=1e-200]”

-J

[Author]

Posts