You are here

How to do the testing job for Rosetta 3.4 ?

8 posts / 0 new
Last post
How to do the testing job for Rosetta 3.4 ?
#1

Hi everyone,

I am trying to install Rosetta 3.4 on CentOS release 5.5. I built the Rosetta executables with the command "scons bin mode=release" according to the user guide . However, i lost my head for how to do the testing jobs. I searched through the forum and it seems that i should do the unit test firstly and then try the integration test. So my first questions is whether this testing routing make sense.

I preceded to the unit test and got the following output after executing the "scons cat=test mode=release" and "test/run.py -d /rosetta3.4/rosetta_database --mode=release" commands
=======================================================================================================================================================
All tests passed!
-------- Unit test summary --------
Total number of tests: 928
number tests passed: 924
number tests failed: 4
failed tests:
protocols.test: test_HitNeighborFinder_find_connected_components_1
protocols.test: test_HitNeighborFinder_find_connected_components_2
protocols.test: test_HitNeighborFinder_find_connected_components_3
protocols.test: test_HitNeighborFinder_find_connected_components_4
Success rate: 99%
---------- End of Unit test summary
Done!

=================================================

It seems that four jobs were failed in the testing, but how to check the results and fix these failures ? Could it be safe enough to precede to the integration test? Any suggestions will be highly appreciated!

P.S. After executing the command "scons bin mode=release", everything went well except the frequent complaints, such as:
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz
/usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc

And these complaints also appeared when executing "scons cat=test mode=release" command. I don't know whether these complaints were related to the failing jobs.

Post Situation: 
Sun, 2012-06-24 19:43
Jacob-kong

The "skipping incompatable" messages are completely normal - it just means that you have multiple versions of the same library (e.g. debug and release, 32 bit and 64 bit, etc.), and the loader is able to identify which one is correct and which is incorrect - just as it should do. As long as you get a completed successfully message from scons, you should be okay.

To run a single unit test, you can use the -1 flag (run "test/run.py -h" for help on parameters)

Something like

test/run.py -d /rosetta3.4/rosetta_database --mode=release -1 test_HitNeighborFinder_find_connected_components_1

should work in your case.

Mon, 2012-06-25 11:32
rmoretti

Thanks for your prompt reply. Rosetta output the following information after executing the following command "test/run.py -d ~/software/rosetta3.4/rosetta_database --mode=release -1 test_HitNeighborFinder_find_connected_components_1"
==========================================================================================
Identifying platform...

Platform found: release/linux/2.6/64/x86/gcc/4.1/
Done!
============================================================================================
The output were duplicated when run the testing for test_HitNeighborFinder_find_connected_components_2 to test_HitNeighborFinder_find_connected_components_4.
I didn't find some information about the failure. Does it imply i have passed the testing ?

Mon, 2012-06-25 18:53
Jacob-kong

Officially, the unit tests are supposed to be run in debug mode, not release mode. I'll see if I can duplicate that test failure for 3.4 release mode...

Mon, 2012-06-25 18:36
smlewis

I doubled checked in both debug and release mode for 3.4 and found no failures. What hardware/OS combo are you using? Try the tests in debug mode; they're much slower but they will offer more information about failures that way.

Mon, 2012-06-25 19:08
smlewis

Thanks for your kindly reply. Hardware: intel x64 and OS: centOS 5.6.

To do the testing in debug mode, should i re-compile the executables in debug mode,such as "scons bin" and "scons cat=test" and then run the unit testing ? Could i just run the unit testing for test_HitNeighborFinder_find_connected_components_1 or all of the testing?

Mon, 2012-06-25 19:34
Jacob-kong

Yes to the recompiling.

You could reasonably try testing just the one test in debug mode. (Unfortunately you can't compile just one).

Tue, 2012-06-26 06:13
smlewis

Have you tried re-running the full unit tests in release mode? Very rarely you might get some blip in the running which will result in failed tests. On subsequent runs you might not get the same conditions, and the test will be fine. If it was just a single run which gave the error, and the subsequent individual run didn't, it's a possibility to consider.

Tue, 2012-06-26 08:24
rmoretti