Member Site › Forums › Rosetta 3 › Rosetta 3 – Build/Install › How to do the testing job for Rosetta 3.4 ?
- This topic has 7 replies, 3 voices, and was last updated 12 years, 2 months ago by
Anonymous.
-
AuthorPosts
-
-
June 25, 2012 at 2:43 am #1323
Anonymous
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 -lcAnd 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.
-
June 25, 2012 at 6:32 pm #7308
Anonymous
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.
-
June 26, 2012 at 1:36 am #7313
Anonymous
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…
-
June 26, 2012 at 3:24 pm #7329
Anonymous
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.
-
June 26, 2012 at 1:53 am #7314
Anonymous
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 ? -
June 26, 2012 at 2:08 am #7315
Anonymous
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.
-
June 26, 2012 at 2:34 am #7316
Anonymous
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?
-
June 26, 2012 at 1:13 pm #7318
Anonymous
Yes to the recompiling.
You could reasonably try testing just the one test in debug mode. (Unfortunately you can’t compile just one).
-
-
AuthorPosts
- You must be logged in to reply to this topic.