- This topic has 4 replies, 2 voices, and was last updated 13 years, 3 months ago by Anonymous.
August 19, 2010 at 7:30 am #654Anonymous
I’ve got Rosetta 3.1 installed and running on my computer, and knowing (by experience,) that 2.3.x can’t install, how might I go about testing this build?
Running the benchmark python script gives no errors, and the Rosetta_demo downloads don’t have sample output files to compare my outputs with.
August 19, 2010 at 2:02 pm #4576Anonymous
Your timing benchmarks are reasonable.
You can run the unit tests, and they should all pass. Compile them with “scons cat=test mode=release” and run them with “test/run.py -database (path)” from the main rosetta directory.
The integration tests do not ship with results because the actual results change from machine to machine – Rosetta is not deeply numerically stable against 32/64 bits and processor architectures. If you want, I can send you a copy of what they look like on my machine, but basically you can do this: compile with “scons bin mode=release” then cd test/integration and run “integration.py -d (database path)” to run the tests. You can then poke around in the ref directory created and look at the results; if they seem “complete” then you’re good. The integration tests are timed to run in less than a minute so they rarely give a “real” trajectory, but they should give complete trajectories which at least try out all parts of a protocol and print some result.
There are also scientific tests in test/scientific. I don’t know how to run them but they have instructions built in; post again if you need help with them and I’ll ask around.
August 20, 2010 at 5:40 am #4579Anonymous
Some extra information:
– The final compile command is as follows, as the python interpreter cannot identify the openSuse distribution of gcc (installed with Yast, so its version identifier is different)
– scons bin mode=release -cxx=gcc -cxx_ver=4.3
– I did run the unit tests, all 526 of 526 passes (although I did note that there was a lot of warnings in the tests about not being able to find atoms from whatever).
“core.io.pdb.file_data: [ WARNING ] can’t find atom for res 188 atom CG1 (trying to set temp)”
– those messages also appear in the integration, but otherwise most appears to have run and have spit out results.
“core.io.pdb.file_data: [ WARNING ] can’t find atom for res 71 atom 2HD2 (trying to set temp)”
Running scientific tests now…
August 20, 2010 at 1:32 pm #4580Anonymous
Those warnings can be safely ignored. It’s a symptom of imperfectly prepared PDBs, not a flaw in your compilation.
August 23, 2010 at 4:32 am #4582Anonymous
Oh good. Scientific tests have also passed – don’t expect any more problems with the comparison run. So, it would seem that previous problems of 2.3.x with Suse was an unknown compiler/OS specific bug.
For future information:
– run log on Rosetta3.1/OpenSuse11.1 build using GCC (SUSE Linux) 4.3.2 and Python 2.6.
– Scons version: v1.1.0.d20081104.r3765
– Two results are for single thread and -j2:
the identity for all positions is: 32.9% / 33.4%
hydrophobic non-polar amino acids (VAL,ILE,LEU,MET,PHE,GLY,ALA,PRO,TRP,TYR): 45.4% / 46.3%
polar uncharged amino acid except CYS (SER,THR,ASN,GLN): 20.4% / 18.9%
negative charged amino acid(ASP,GLU): 19.8% / 20.4%
positive charged amino acid(ARG,LYS,HIS): 14.7% / 16.1%
FARNA, 25th percentile rms (50 decoys): 2.39 / 2.40 [should be less than 3.00]
Hi-res refine, 25th percentile rms (50 decoys): 2.34 / 2.22 [should be less than 2.75]
no base pairs, seq. recovery: 0.41 / 0.39 [should be more than 0.30]
Watson/Crick bp, seq. recovery: 0.44 / 0.43 [should be more than 0.35]
non-Watson/Crick bp, seq. recovery: 0.78 / 0.74 [should be more than 0.70]
all RNA, seq. recovery: 0.53 / 0.51 [should be more than 0.45]
All tests passed.
- You must be logged in to reply to this topic.