Debian Med: Sharing Rosetta build experience with Debian and Ubuntu

[Anonymous]

To help the building from source on Debian and Ubuntu, which is not completely straight forward on the now current versions of gcc/g++ on these platforms, I have prepared all that would be required for a basic Debian/Ubuntu package. The Rosetta license does not allow the distribution of the packages through Debian, obviously. These packaging-instructions were rather aiming at the many local system administrators who may decide to run them themselves for a distribution of Rosetta in their lab or possibly just find it interesting to compare those build instructions and patches with what they do.

Instructions are placed next to regular packages on the Debian Med repository at http://svn.debian.org/wsvn/debian-med/trunk/packages/rosetta/trunk/debian/#_trunk_packages_rosetta_trunk_debian_. To build the package, one checks out the debian folder into the Rosetta source tree, makes sure to have the packages build-essential and scons installed and then starts it all off with “dpkg-buildpackage -rfakeroot -uc -us“. Comments for improvements just drop here, email me (moellerUdebian.org) or discuss on the Debian Med mailing list.

[Anonymous]

Which gcc and ubuntu/debian are the changes for? Reasonable changes I can just commit to trunk for 3.3. The code in core/conformation/symmetry/util.cc has already been overhauled somehow (so those ifdefs, which make no sense anyway, aren’t there.)

Does this scheme actually shift Rosetta to compiling with a different GCC?

Were you aware that the root cause of some of the GCC incompatibilities was found out to be the inlining limits (-finline-limit, I think)? I’m not sure if that’s relevant here. I can find the thread again.

[Anonymous]

Many thanks for your kind reply. Compilation would default to the very latest version of Debian/Ubuntu that is available and the instructions in the folder named “debian” should work without changes on other distributions like “ubuntu”. Compilation in this case was performed with a 64bit Debian “Squeeze” and gcc 4.5.3. Ubuntu Natty has -0.0.1 about the very same version. To compile with gcc-4.6 was not yet attempted. From what I have observed, Rosetta is very much self-contained, so the only difficulty should be for the typically more strict later versions of gcc, i.e. changes should be backward-compatible. But if they are not, there shall be branches of that debian folder for that particular release of the particular Linux distribution. The only trick for gcc I had to apply was to disguise the version down to the supported 4.4, so the build instructions became
scons cxx=gcc cxx_ver=4.4 bin

There was no change performed to the Rosetta sources except for the util.cc as described in this forum. And there should not be any surprises for you in the first place, everything should be communicated through this forum (or some other suiteable means). With util.cc already changed, for version 3.3 I would then create a new branch of that folder that does not contain that patch. Not used (since rather enormous) is BuildDocs.sh, below nonetheless a smallish fix to it because of the absent index.html.

The main benefit of this debian folder I see in the open invitation to compile Rosetta out of the box – it took me some 4-6 hours until it compiled and that initial setup time (and the intrinsic insecurity if everything was done right) should be dramatically reduced with that folder, i.e. at least once there are reports from Rosetta professionals that this package truly works. And I personally find updates far easier this way and the distribution of the software across a local computer lab or to bring it to one of the various Debian/Ubuntu cloud setups. Of particular value for the users of Rosetta may be the separation of the symbols in a separate package, which comes for free with the packaging:
rosetta_3.2.1-1_amd64.deb
rosetta-dbg_3.2.1-1_amd64.deb
There can be further packages to split various binaries and the libraries when there is demand.

We do not have any download statistics for the subversion folders of Debian Med. The number of installations may appear in the popularity-contest at some point, even though there is no official Rosetta package in the archive. No idea if this is useful to your community … I personally am just somewhat curious, so I must admit.

--- rosetta-3.2.1.orig/BuildDocs.sh     2011-05-07 21:37:47.000000000 +0200

+++ rosetta-3.2.1/BuildDocs.sh  2011-05-07 21:38:28.000000000 +0200

@@ -1,9 +1,15 @@

#!/bin/bash



+set -x

+set -e

+

echo 'Building documentation for each src/doxygen.*'



mkdir html

-cp doc/index.html html/

+

+if [ -r doc/index.html ]; then

+       cp doc/index.html html/

+fi



rm -rf html/core+protocols html/all_else

[Anonymous]

“Be impressed by the size the source code
du -sh rosetta_source
374M rosetta_source”

Ugh, tell me about it. I just put it on the agenda for the next developer’s meeting (RosettaCON is this week). Some of this is that we have data mixed in with code as part of the testing system; by my count a minimum of 109 of those 374 MB are inputs for automated testing. We may finally get around to extracting test inputs from code for 3.4…or maybe not.

[Anonymous]

For their size and their build time I would be glad to see the external libraries separated out into a second source package. The build system could then detect the system’s libraries. But one definitely wants all the tests, then Anyway, It was a very smooth build, many thanks.

[Anonymous]

With debian amd64 squeeze I have followed the directions given by smoe 08/02/2011 with failure. Although all required build dependencies are available, at repeated “quilt push” the result is always

francesco@gig64:~/rosetta/rosetta_source$ quilt push
No series file found

as if there were no patches. Nonetheless, I tried:

francesco@gig64:~/rosetta/rosetta_source$ fakeroot ./debian/rules -j 4 binary
dh binary
dh_testdir
dh_auto_configure
debian/rules override_dh_auto_build
make[1]: Entering directory `/home/francesco/rosetta/rosetta_source’
#scons cxx=gcc mode=release cxx_ver=4.4 -j 12 bin
scons cxx=gcc bin
scons: Reading SConscript files …
Copy(“user.options”, “user.options.template”)
Copy(“user.settings”, “user.settings.template”)
Copy(“/home/francesco/rosetta/rosetta_source/src/pilot_apps.src.settings”, “/home/francesco/rosetta/rosetta_source/src/pilot_apps.src.settings.template”)
Traceback (most recent call last):
File “/home/francesco/rosetta/rosetta_source/SConstruct”, line 139, in main
build = SConscript(“tools/build/setup.py”)
File “/usr/lib/scons/SCons/Script/SConscript.py”, line 614, in __call__
return method(*args, **kw)
File “/usr/lib/scons/SCons/Script/SConscript.py”, line 551, in SConscript
return _SConscript(self.fs, *files, **subst_kw)
File “/usr/lib/scons/SCons/Script/SConscript.py”, line 260, in _SConscript
exec _file_ in call_stack[-1].globals
File “/home/francesco/rosetta/rosetta_source/tools/build/setup.py”, line 411, in
build = setup()
File “/home/francesco/rosetta/rosetta_source/tools/build/setup.py”, line 402, in setup
build.options_requested, build.options = setup_build_options()
File “/home/francesco/rosetta/rosetta_source/tools/build/setup.py”, line 108, in setup_build_options
supported, actual.cxx, requested.cxx_ver
File “/home/francesco/rosetta/rosetta_source/tools/build/setup_platforms.py”, line 83, in select_compiler_version
(actual, compiler)
KeyError: “Unknown version number 4.6 for compiler ‘gcc'”
scons: done reading SConscript files.
scons: Building targets …
scons: `bin’ is up to date.
scons: done building targets.
#./BuildDocs.sh
make[1]: Leaving directory `/home/francesco/rosetta/rosetta_source’
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
debian/rules override_dh_install
make[1]: Entering directory `/home/francesco/rosetta/rosetta_source’
# retrieving everything from symbolik link
cp -r -L bin/* /home/francesco/rosetta/rosetta_source/debian/rosetta/usr/lib/rosetta/bin/
cp: cannot stat `bin/*’: No such file or directory
make[1]: *** [override_dh_install] Error 1
make[1]: Leaving directory `/home/francesco/rosetta/rosetta_source’
make: *** [binary] Error 2
francesco@gig64:~/rosetta/rosetta_source$

In spite of folder /debian having been downloaded, containing /patches
were /patches comprises
/builddoc.patch
gcc4.6pach
pdbinfo.patch
series.

The latter file “series” reads
#pdbinfo.patch
#builddoc.patch
gcc4.6patch
*****************

Then I tried with “build”, again getting errors:

francesco@gig64:~/rosetta/rosetta_source$ dpkg-buildpackage -rfakeroot -uc -us
dpkg-buildpackage: source package rosetta
dpkg-buildpackage: source version 3.3-1
dpkg-buildpackage: source changed by Steffen Moeller
dpkg-buildpackage: host architecture amd64
dpkg-source –before-build rosetta_source
dpkg-source: warning: diff rosetta_source/debian/patches/gcc4.6patch removes a non-existing file rosetta_source/home/moeller/alioth/debian-med/packages/rosetta/rosetta-3.3/tools/build/setup_platforms.py (line 21)
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
debian/rules override_dh_clean
make[1]: Entering directory `/home/francesco/rosetta/rosetta_source’
dh_clean
rm -rf build
make[1]: Leaving directory `/home/francesco/rosetta/rosetta_source’
dpkg-source -b rosetta_source
dpkg-source: info: using source format `3.0 (quilt)’
dpkg-source: warning: diff rosetta_source/debian/patches/gcc4.6patch removes a non-existing file rosetta_source/home/moeller/alioth/debian-med/packages/rosetta/rosetta-3.3/tools/build/setup_platforms.py (line 21)
dpkg-source: info: building rosetta using existing ./rosetta_3.3.orig.tar.gz
patching file tools/build/basic.settings
The next patch would delete the file home/moeller/alioth/debian-med/packages/rosetta/rosetta-3.3/tools/build/setup_platforms.py,
which does not exist! Skipping patch.
1 out of 1 hunk ignored
patching file tools/build/options.settings
dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -E -b -B .pc/gcc4.6patch/ < rosetta_source.orig.xsRlQI/debian/patches/gcc4.6patch gave error exit status 1
dpkg-buildpackage: error: dpkg-source -b rosetta_source gave error exit status 2
francesco@gig64:~/rosetta/rosetta_source$

Thanks for advice
chiendarret

[Anonymous]

Thanks again. In running “Integration tests” I met what is surely a trivial problem of permissions, but one that has halted me.

francesco@gig64:/usr/local/rosetta_source/test/integration$ python integration.py -j6 -d /usr/local/rosetta_database
Traceback (most recent call last):
File “integration.py”, line 641, in
sys.exit(main(sys.argv[1:]))
File “integration.py”, line 163, in main
os.mkdir(outdir)
OSError: [Errno 13] Permission denied: ‘new’
francesco@gig64:/usr/local/rosetta_source/test/integration$

Permissions to both /usr/local/rosetta_source and /usr/local/rosetta_database

are

drwxr-xr-x 12 root francesco

and

drwxr-xr-x 17 root francesco

respectively, and were imposed chmod -R chown -R

Thanks for help
chiendarret

[Anonymous]

/rosetta_source/test/integration has permission “drwxr-xr-x”

It is confusing that “integration.py” needs command “python integration.py ..” or “./integration.py …”, while command “integration.py …” answers “bash: integration.py: command not found. The first line of “integration.py” is correct “#!/usr/bin/env python”.

All above as “$”. Using “#”, the test runs, although reporting errors of mode flag or path that I do not understand. At any event, the test should not need superuser;
francesco@gig64:/usr/local/rosetta_source/test/integration$ su
Password:
root@gig64:/usr/local/rosetta_source/test/integration# ./integration.py -j6 -d /usr/local/rosetta_database
Running fold_and_dock on localhost …
Running AnchoredPDBCreator on localhost …
Running pepspec_anchor_dock on localhost …
Running docking_full_protocol on localhost …
*** Test fold_and_dock did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.442694]
Running loop_modeling on localhost …
Running backrub on localhost …
Finished fold_and_dock in 0 seconds [~6 test (8%) started, 65 in queue]
*** Test backrub did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.447688]
*** Test AnchoredPDBCreator did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.447829]
Running score_only_silence on localhost …
*** Test docking_full_protocol did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.448110]
*** Test pepspec_anchor_dock did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.449529]
Finished backrub in 0 seconds [~7 test (9%) started, 64 in queue]
Finished AnchoredPDBCreator in 0 seconds [~7 test (9%) started, 64 in queue]
Finished docking_full_protocol in 0 seconds [~7 test (9%) started, 64 in queue]
Finished pepspec_anchor_dock in 0 seconds [~9 test (12%) started, 61 in queue]
Running hotspot_graft on localhost …
*** Test score_only_silence did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.452975]
Running rotamer_probability on localhost …
Running pepspec on localhost …*** Test loop_modeling did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.453272]

Running features on localhost …
Finished loop_modeling in 0 seconds [~11 test (15%) started, 60 in queue]
*** Test hotspot_graft did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.458929]
Finished score_only_silence in 0 seconds [~12 test (15%) started, 59 in queue]
Running combine_silent on localhost …
Finished hotspot_graft in 0 seconds [~13 test (18%) started, 58 in queue]
Running rosetta_scripts_setup on localhost …
*** Test rotamer_probability did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.461369]
*** Test pepspec did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.462785]
*** Test features did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.463864]
Finished pepspec in 0 seconds [~14 test (19%) started, 57 in queue]
Finished rotamer_probability in 0 seconds [~14 test (19%) started, 57 in queue]
Finished features in 0 seconds [~15 test (21%) started, 56 in queue]
*** Test rosetta_scripts_setup did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.464997]
*** Test combine_silent did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.465401]
Running membrane_relax on localhost …
Running UBQ_E2_thioester on localhost …
Finished combine_silent in 0 seconds [~17 test (23%) started, 54 in queue]Finished rosetta_scripts_setup in 0 seconds [~17 test (23%) started, 54 in queue]

Running ppk on localhost …
Running match on localhost …Running abinitio on localhost …
Running kinematic_looprelax on localhost …

*** Test UBQ_E2_thioester did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.472503]
*** Test membrane_relax did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.473567]
Finished UBQ_E2_thioester in 0 seconds [~19 test (26%) started, 52 in queue]
Running mpi_multistate_design on localhost …
Finished membrane_relax in 0 seconds [~20 test (28%) started, 51 in queue]
Running FloppyTail on localhost …
*** Test ppk did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.477936]
*** Test abinitio did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.478253]
*** Test match did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.478702]
Finished abinitio in 0 seconds [~21 test (29%) started, 50 in queue]
Finished match in 0 seconds [~22 test (30%) started, 49 in queue]
Running metalloprotein_abrelax on localhost …
*** Test kinematic_looprelax did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.480747]
Running docking_prepack on localhost …
Finished kinematic_looprelax in 0 seconds [~23 test (32%) started, 48 in queue]
Running fast_relax on localhost …
Finished ppk in 0 seconds [~24 test (33%) started, 47 in queue]
*** Test metalloprotein_abrelax did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.484159]
*** Test FloppyTail did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.484542]
*** Test mpi_multistate_design did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.484631]
Finished metalloprotein_abrelax in 0 seconds [~25 test (35%) started, 46 in queue]
Finished mpi_multistate_design in 0 seconds [~25 test (35%) started, 46 in queue]
Finished FloppyTail in 0 seconds [~25 test (35%) started, 46 in queue]Running geometric_solvation on localhost …

Running docking_ensemble_prepack on localhost …
Running score12_docking on localhost …Running membrane_abinitio on localhost …*** Test docking_prepack did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.489215]

*** Test fast_relax did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.489941]
Finished fast_relax in 0 seconds [~28 test (39%) started, 43 in queue]
*** Test docking_ensemble_prepack did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.492335]
*** Test geometric_solvation did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.492959]
Finished docking_prepack in 0 seconds [~29 test (40%) started, 42 in queue]
Finished geometric_solvation in 0 seconds [~30 test (42%) started, 41 in queue]
Finished docking_ensemble_prepack in 0 seconds [~30 test (42%) started, 41 in queue]
Running HOW_TO_MAKE_TESTS on localhost …
Running cluster on localhost …
*** Test membrane_abinitio did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.495973]
Finished membrane_abinitio in 0 seconds [~32 test (45%) started, 39 in queue]
*** Test score12_docking did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.496625]
Running place_simultaneously on localhost …
Running AnchoredDesign on localhost …
Finished score12_docking in 0 seconds [~33 test (46%) started, 38 in queue]
Finished HOW_TO_MAKE_TESTS in 0 seconds [~33 test (46%) started, 38 in queue]
Running sequence_recovery on localhost …
*** Test place_simultaneously did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.500611]
Finished place_simultaneously in 0 seconds [~35 test (49%) started, 36 in queue]
Running centroid_disulfide_scores on localhost …
Running fold_cst_new on localhost …
*** Test cluster did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.502623]
*** Test AnchoredDesign did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.502770]
*** Test sequence_recovery did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.502898]
Finished cluster in 0 seconds [~36 test (50%) started, 35 in queue]
Finished sequence_recovery in 0 seconds [~36 test (50%) started, 35 in queue]
Running AnchorFinder on localhost …
Finished AnchoredDesign in 0 seconds [~37 test (50%) started, 34 in queue]
*** Test fold_cst_new did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.505687]
*** Test centroid_disulfide_scores did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.506534]
Running docking_ensemble on localhost …
Finished fold_cst_new in 0 seconds [~39 test (54%) started, 32 in queue]
Running docking_local_refine_min on localhost …Running rna_design on localhost …

*** Test AnchorFinder did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.508701]
Finished centroid_disulfide_scores in 0 seconds [~40 test (56%) started, 31 in queue]
Finished AnchorFinder in 0 seconds [~40 test (56%) started, 31 in queue]
Running score_jd2 on localhost …
*** Test docking_ensemble did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.510951]
*** Test docking_local_refine_min did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.512488]
Running sequence_tolerance on localhost …
*** Test rna_design did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.514087]
Running classic_relax_1a19 on localhost …
Finished docking_ensemble in 0 seconds [~42 test (59%) started, 29 in queue]Finished docking_local_refine_min in 0 seconds [~42 test (59%) started, 29 in queue]

*** Test score_jd2 did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.514533]
Finished rna_design in 0 seconds [~43 test (59%) started, 27 in queue]Finished score_jd2 in 0 seconds [~44 test (60%) started, 27 in queue]

Running cstfile_to_theozyme_pdb on localhost …
*** Test sequence_tolerance did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.518050]
Running mr_protocols on localhost …
*** Test classic_relax_1a19 did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.518511]
Finished sequence_tolerance in 0 seconds [~46 test (64%) started, 25 in queue]Running extract_atomtree_diffs on localhost …

Running BuildPeptide on localhost …*** Test cstfile_to_theozyme_pdb did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.521898]

Finished classic_relax_1a19 in 0 seconds [~46 test (64%) started, 24 in queue]
*** Test mr_protocols did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.522658]
Finished cstfile_to_theozyme_pdb in 0 seconds [~48 test (67%) started, 23 in queue]
*** Test extract_atomtree_diffs did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.524002]
Running super_aln on localhost …
Running orbitals on localhost …Finished mr_protocols in 0 seconds [~49 test (69%) started, 22 in queue]

Finished extract_atomtree_diffs in 0 seconds [~50 test (70%) started, 21 in queue]
Running docking_site_constraints on localhost …
Running threading on localhost …
Running docking_local_refine on localhost …
*** Test orbitals did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.529930]
*** Test BuildPeptide did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.530236]
Finished orbitals in 0 seconds [~51 test (71%) started, 20 in queue]
Finished BuildPeptide in 0 seconds [~52 test (73%) started, 19 in queue]
*** Test super_aln did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.530932]
Running database_jd2_io on localhost …
*** Test docking_site_constraints did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.531616]
Running ligand_motif_design on localhost …
Finished super_aln in 0 seconds [~53 test (74%) started, 18 in queue]
Running score_aln on localhost …
*** Test threading did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.535506]
Finished threading in 0 seconds [~54 test (76%) started, 17 in queue]
*** Test database_jd2_io did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.536466]
Running gen_apo_grids on localhost …
Finished database_jd2_io in 0 seconds [~55 test (77%) started, 16 in queue]
Finished docking_site_constraints in 0 seconds [~55 test (77%) started, 16 in queue]
*** Test docking_local_refine did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.537745]
*** Test score_aln did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.538662]
Finished score_aln in 0 seconds [~57 test (80%) started, 14 in queue]
Running fixbb on localhost …
Finished docking_local_refine in 0 seconds [~57 test (80%) started, 14 in queue]Running flexpepdock on localhost …*** Test ligand_motif_design did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.540815]

Finished ligand_motif_design in 0 seconds [~59 test (83%) started, 12 in queue]
*** Test gen_apo_grids did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.543285]
Running ddG_of_mutation on localhost …
*** Test fixbb did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.543841]
Running features_parallel on localhost …
*** Test flexpepdock did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.546455]
Finished fixbb in 0 seconds [~60 test (84%) started, 11 in queue]
Finished gen_apo_grids in 0 seconds [~60 test (84%) started, 11 in queue]
Running antibody on localhost …
Finished flexpepdock in 0 seconds [~62 test (85%) started, 9 in queue]
Running rs_flexbbmoves on localhost …
Running symmetric_docking on localhost …
Finished features_parallel in 0 seconds [~63 test (88%) started, 8 in queue]
*** Test ddG_of_mutation did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.552090]
Running rna_denovo on localhost …
*** Test antibody did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.552778]
Finished ddG_of_mutation in 0 seconds [~64 test (90%) started, 7 in queue]
Finished antibody in 0 seconds [~65 test (91%) started, 6 in queue]
Running docking_low_res on localhost …
Running fragment_picker on localhost …
*** Test symmetric_docking did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.556258]
*** Test rs_flexbbmoves did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.557136]
Running ligand_dock_7cpa on localhost …
Finished rs_flexbbmoves in 0 seconds [~66 test (92%) started, 5 in queue]
Finished symmetric_docking in 0 seconds [~66 test (92%) started, 5 in queue]
*** Test rna_denovo did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.559816]
*** Test docking_low_res did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.560326]
*** Test fragment_picker did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.560702]
Finished rna_denovo in 0 seconds [~68 test (95%) started, 3 in queue]
Finished docking_low_res in 0 seconds [~69 test (97%) started, 2 in queue]
Running ligand_dock_grid on localhost …
Running extract_pdbs on localhost …Finished fragment_picker in 0 seconds [~70 test (98%) started, 1 in queue]
Running ligand_dock_script on localhost …

*** Test ligand_dock_7cpa did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.565280]
Running gen_lig_grids on localhost …
*** Test ligand_dock_grid did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.566777]
Finished ligand_dock_7cpa in 0 seconds [~71 test (100%) started, 0 in queue]
*** Test ligand_dock_script did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.569408]
Running InterfaceAnalyzer on localhost …
*** Test extract_pdbs did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.570982]
*** Test gen_lig_grids did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.571276]
Finished ligand_dock_grid in 0 seconds [~71 test (100%) started, 0 in queue]
Finished ligand_dock_script in 0 seconds [~71 test (100%) started, 0 in queue]
Finished extract_pdbs in 0 seconds [~71 test (100%) started, 0 in queue]
Finished gen_lig_grids in 0 seconds [~71 test (100%) started, 0 in queue]
*** Test InterfaceAnalyzer did not run! Check your –mode flag and paths. [2012-01-23 23:00:25.573685]
Finished InterfaceAnalyzer in 0 seconds [~71 test (100%) started, 0 in queue]

Just generated ‘ref’ results; run again after making changes.
root@gig64:/usr/local/rosetta_source/test/integration#

Thanks for advice. chiendarret

[Anonymous]

I’ll try to answer all the questions in your last couple of posts.

First, the integration test says “Just generated ‘ref’ results; run again after making changes.” because it doesn’t check against external reference results. You run them, you change the code (as part of development), and you run them again to see if they change as expected (or unexpectedly). You aren’t changing code so all you can do is see that they run at all, which they appear to do. (The code is too sensitive to processor architecture to store the results with the code, because different computers will get different structures.)

If you ran the unit tests as I described earlier, those do compare against fixed results, and it will say something like “all tests passed”. The scientific tests run sort of like the unit tests, and compare to some sort of benchmark, like “better than 30% sequence recovery” or somesuch. I’m not very familiar with them.

W/r/t where you should put Rosetta stuff: to compile Rosetta, the build directory and two files within the source code must be writable by the person doing the compiling. Once compiled nothing needs to be writable. To run Rosetta, one file in the database must be writable, at least the first time you run (the binary Dunbrack file). You’ve already run the fixbb integration test, which will create this file as a side effect, so you shouldn’t need writability to the database anyway. So I guess it no longer matters what your write permissions are.

Developers never “install” Rosetta in the sense that you want to install it (to /usr/local or whatever). We just compile it in a user directory and call it from there. It doesn’t really matter where you put it; Rosetta never needs root permissions to run (assuming you aren’t asking it to write to write-restricted directories, which is a distinct file permissions issue).

[Anonymous]

A new version is out, the one or other may profit from the following instructions for a compilation on recent Debian or Ubuntu machines.

Getting the source to a good place

Download tarball from your web browser

Render it detectable to Debian build system

ln -s rosetta3.3_source.tgz rosetta_3.3.orig.tar.gz

Unpack it

tar xzvf rosetta_3.3.orig.tar.gz

Be impressed by the size of the source code

du -sh rosetta_source

374M rosetta_source

Substract contribution external software from that impression

du -sh rosetta_source/external

make sure you have at least 4.5 GB of free disk space on that partition

df -h .

Adding Build instructions to the source code from Debian Med‘s subversion repository

change to source tree

cd rosetta_source

get debian directory

svn checkout svn://svn.debian.org/svn/debian-med/trunk/packages/rosetta/trunk/debian

quickly check that the debian directory is talking about the same version and is not somewhat ‘behind’

dpkg-parsechangelog

Source: rosetta

Version: 3.3-1

…

Handling patches to the source code to adapt from Rosetta’s source tree for Debian/Ubuntu

make sure all build dependencies are available

sudo apt-get install debhelper scons zlib1g-dev quilt build-essential

prepare patch-tool quilt to find the patches in the Debian subfolder

QUILT_PATCHES=debian/patches; export QUILT_PATCHES

check if all patches apply

quilt push -a

The very new releases won’t have any such patches. Complain here or by email to the package maintainer if something fails.

Reserve an hour for the build on a recent machine.

initiate build

fakeroot ./debian/rules -j 4 binary

the Debian package is not too big

ls -lh ../rosetta_3.3-1_amd64.deb

-rw-r–r– 1 moeller moeller 30M Aug 1 16:35 ../rosetta_3.3-1_amd64.deb

install the package

dpkg -i ../rosetta_3.3-1_amd64.deb

quick cross-check that the libraries are indeed found

ldd /usr/bin/FlexPepDocking

linux-vdso.so.1 => (0x00007fff24db8000)

libprotocols.so => /usr/lib/rosetta/lib/libprotocols.so (0x00007ffd5fd31000)

libcore.5.so => /usr/lib/rosetta/lib/libcore.5.so (0x00007ffd5f8a0000)

libcore.4.so => /usr/lib/rosetta/lib/libcore.4.so (0x00007ffd5ef22000)

libcore.3.so => /usr/lib/rosetta/lib/libcore.3.so (0x00007ffd5d7f6000)

libcore.2.so => /usr/lib/rosetta/lib/libcore.2.so (0x00007ffd5d118000)

libcore.1.so => /usr/lib/rosetta/lib/libcore.1.so (0x00007ffd5cedf000)

libbasic.so => /usr/lib/rosetta/lib/libbasic.so (0x00007ffd5c969000)

libnumeric.so => /usr/lib/rosetta/lib/libnumeric.so (0x00007ffd5c681000)

libutility.so => /usr/lib/rosetta/lib/libutility.so (0x00007ffd5c30e000)

libObjexxFCL.so => /usr/lib/rosetta/lib/libObjexxFCL.so (0x00007ffd5c0c1000)

libz.so.1 => /lib/libz.so.1 (0x00007ffd5be8c000)

libcppdb.so => /usr/lib/rosetta/lib/libcppdb.so (0x00007ffd5bc32000)

libsqlite3.so => /usr/lib/rosetta/lib/libsqlite3.so (0x00007ffd5b996000)

libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ffd5b68c000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffd5b409000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffd5b1f3000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffd5ae6f000)

/lib64/ld-linux-x86-64.so.2 (0x00007ffd6328d000)

[Anonymous]

I updated the Debian build instructions for Rosetta 3.4. The failure experienced by chiendarret was because the quilt tool did not find the patches, a mistake of mine, I edited the post to now set the QUILT_PATCHES environment variable. Sorry for not reading that any earlier, just email me (address in first post) when there is any other issue.

The build was very clean, not a single warning if I am not erroneous, and I want to thank you for that. Very impressive. My initial attempt was deleting the boost library shipping with the sources, but the code is incompatible with the 1.49 version shipping these days, otherwise this would be straight forward to substitute, as I found.

Would there be any interest in the binaries I built for a redistribution on rosettacommons.org? I could also come up with Debian packages for the data files if there is any interest.

[Anonymous]

I admit to be not overly keen to help out every week but I happily help with some automation on your side. If you have some Linux machine around, I much presume so, it is easy (there is the tool for it) to add so called “change root” (chroot) environments with various versions of Debian or Ubuntu to your local machine. The advantage over virtual machines or a remote login is the direct sharing of your source tree, e.g. by some mount -o bind magic. Once the Debian/Ubuntu packaging starts to mean more to you than an easier upgrade mechanism, you may decide for splitting the package up into various parts and/or add man pages or … it would be interesting to share any such issues across Linux distributions.

[Anonymous]

I’ve put this on the agenda to discuss as well, but I’m a lot less optimistic about it happening.

[Anonymous]

I’ve never used the package, hopefully smoe is listening and can weigh in.

To fix the 4.6 issue, all you should need to do is add 4.6 to the gcc list in the file tools/build/options.settings. It may help to compile with the flags “cxx=gcc cxx_ver=4.6” on your command line. There are many other threads about this floating around on the boards. (We haven’t fixed the options.settings file because none of the developers are using 4.6 yet so we can’t claim to officially support it).

[Anonymous]

Thanks. Away from deb packaging, I followed your indications. With debian amd64 squeeze, I added “4.6” to

/rosetta_source/tools/build/options/options.settings

Then,

$ sudo scons cxx=gcc cxx_ver=4.6

from within /rosetta_source ended successfully with

scons: done building target

At this point I must say that, by doing so, I had forgot my wish to have Rosetta parallelized on this shared memory machine (a six-core AMD PHmom II 1075T on Gigabyte 800FXA with 16 GB RAM and two Zotac GTX-580. The latter two used for MD with NAMD software).

To this end, should additional flags be used on the command line? And should a message passing support, such as openmpi, be installed before compiling Rosetta? As NAMD is parallelized per se, no parallelization support is yet installed on this machine. Could you please indicate where to find direction for use of parallelized portions of Rosetta? My plan is to use Flex_Pep to get a PDB file from a peptide FASTA, and then docking the peptide onto a protein.

Thanks a lot for advice

chiendarret

[Anonymous]

First: with few exceptions, Rosetta does _not_ get any faster in parallel compared to running single processor jobs; ‘parallel’ Rosetta just organizes independent Monte Carlo trajectories on each processor and makes sure they output as independently numbered results. You double the number of structures per unit time, but it won’t affect the wall clock time to generate a single structure. The upshot of this is that if you have trouble getting Rosetta to work in parallel, you lose little by giving it up.

Second: Rosetta’s parallelization works on a USEMPI directive, which is activated by adding “extras=mpi” to the _compile_ command line “scons.py bin mode=release extras=mpi -j##” You will need to install some sort of MPI first. I don’t know the package names. I’ve used mvapich and openmpi and both work fine. You do NOT need additional flags at runtime; Rosetta “knows” it was compiled in MPI and uses it automatically. If you are using a small number of processors, I strongly suggest the flag “mpi_work_partition_job_distributor”, which will tell Rosetta not to waste a processor as a head node and instead pre-distribute the jobs, and “mpi_tracer_to_file proc”, which will separate the logging output from each processor into separate files.

FlexPepDock is one of the executables that works with MPI. (Generally, if you open the executable’s cc file and find reference to “jd2” it probably is MPI compatible.)

[Anonymous]

Yes, it is a small machine from the CPU point of view (which is of Rosetta concern), while very powerful from the GPU point of view (parallelization with NAMD-CUDA MD). At any event, I hope that the kind of parallelization with Rosetta will be valuable also for peptide onto protein docking, as it similarly was with DOT software, which I used extensively.

Question: In order to try parallelized compilation of Rosetta 3.3, should the existing single-CPU compilation be first removed?

Thanks for advice
chiendarret

[Anonymous]

The build system stores the MPI and non-mpi builds separately. You do not have to remove the old non-MPI build first. There will be a folder that looks something like build/src/release/linux/x86/4.0/gcc/ containing the gcc non-mpi build, then a subfolder mpi within that folder containing the mpi build.

The symlinks to executables in the bin folder are NOT reliable if you have both a regular and an mpi build. If you look at the symlink path, it is correct, but it will link to whatever’s compiled most recently so you may not get the one you meant.

Rosetta is structurally unsuited to GPU, unfortunately. We are working on putting parts of it on GPU to see what we can get done, but unfortunately the way the scorefunction is designed it’s practically the opposite of the GPU paradigm.

[Anonymous]

Yes, the non-mpi was built under /build/…gcc/4.6 as you describe. Then, I installed open MPI 1.4.3 and commanded

scons mode=release cxx=gcc cxx_ver=4.6 extras=mpi -j6

getting, under /build/… /gcc/4.6 a new directory “mpi” and a new regular file “mpi_util.os”. The /mpi directory is structured, with same names, as for the non-mpi compilation under /build…/gcc/4.6.

Is it any test tool to carry out about the various executables, parallelized or not (I mean of the type of tests with AMBER software), or something to the same end?
Thanks a lot for your kind advice.
chiendarret

[Anonymous]

Our testing suite exists but isn’t very good. The two fast-running tests are the unit and integration tests.

For the unit tests:
1) compile in debug mode, “scons bin -j#”
2) compile tests in debug mode, “scons cat=test -j#”
3) run tests, “test/run.py -j# -d /path/to/database”

It should end with this:

“All tests passed!

---

Unit test summary

---

Total number of tests: 841
number tests passed: 841
number tests failed: 0
Success rate: 100%

---

End of Unit test summary
Done!
“

Integration tests (you already built the executables):
cd test/integration
integration.py -j# -d /path/to/database

It will run a bunch of integration tests. They’re supposed to be “difference” tests to compare revisions, but you have only the one revision, so all you can do is see that they completed without errors. Many of them are too short to produce scientifically valid output, so if you lookat structures don’t be disturbed if they’re garbage.

There are scientific benchmark tests that you can run the same as the integration tests, I think, at test/scientific or something similar.

[Anonymous]

It’s definitely a permissions issue. What is the chmod status of the folder rosetta_source/test/integration? (I believe you that you fixed it recursively, but it’s clearly a permissions issue so I don’t know how else to fix it…)

[Anonymous]

The “bash: integration.py not found” means that . (current directory) is not in your path. This is something you fix in your bash settings. I don’t know why you need superuser but it’s a permissions issue, not a Rosetta thing.

To figure out why they aren’t running, the first thing to check is what command it tried to issue. Look in the file ref/$WHICHEVER/command.sh. Halfway though the file (ignore the lines with #) is a line like this:

/home/smlewis/LOCAL/rosetta-3.3/rosetta_source/bin/AnchoredDesign.default.linuxgccrelease @options -database /home/smlewis/minirosetta_database -run:constant_seed -nodelay 2>&1
| egrep -vf ../../ignore_list
> log

See if the command will run on its own, and if not, why not. It usually means it’s pathing incorrectly (either the executable isn’t in the bin folder, or the bin folder points to an unusable executable (like MPI or something)).

[Anonymous]

Earlier, it was specified that the permissions on the rosetta directories were “drwxr-xr-x ?? root francesco” That is, the directories are only writable to the owner, and that owner is root. If rosetta_source/test/integration has permission “drwxr-xr-x” and also is owned by root, only root can create or alter files in the directory tree. As the integration tests write files within the rosetta directory tree, only root is going to be able to run the integration and unit tests without filesystem errors.

If you want to run the integration tests as a regular user, you’ll either need to change the ownership of rosetta_source/test/integration and all files and subdirectories therein, or change the permissions such that they’re world writable, or at least writable by a group to which the user running them belongs.

As Steven indicates, having to run either python integration.py or ./integration.py is a *feature* of the bash command line. If a executable program is not in your path, you have to provide the (relative) directory to it, not just the executable name. This is to prevent things like accidentally executing possibly malicious programs named things like “ls”, “cp”, etc. in the current directory. While you can put the current directory on your path, it’s not recommended. Again, all this is basic Unix things, and not related to Rosetta specifically.

[Anonymous]

How to run integration.py was a silly question from me.

That running tests has to write to disk, I later suspected. Thanks for confirming. However, it would be out of my habit to let writing on /usr/local/dirs by other than root. On the other hand, running tests as root might in general have unpleasant consequences. What about moving Rosetta’s “test” stuff to /home?

I also have Rosetta_database under /usr/local. Better moving it to /home?

In connection, I was wondering about how to access Rosetta when, as in my case, the executables (both non-mpi and mpi) are under /usr/local/rosetta_source/bin (I have compiled Rosetta again). Setting paths in my .bashrc or using a script with full paths? I know that there are guidelines on internet, though for v. 2.3 and often along different approaches.

Are now ( v 3.3) the various output directories created automatically? Is there a score reunifying the contents of the various directories (of the type in DOT)?

Where to best look for documentation for v 3.3?

thanks, chiendarret

[Anonymous]

Adding to myself and summarizing, I compiled again with “build” flag (adding “4.6” in place of “*” for gcc at /tools/build/options.settings, while having open MPI 1.4.3 installed and checked)

cd /usr/local/rosetta_source

# scons bin mode=release cxx=gcc cxx_ver=4.6

# scons bin mode=release cxx=gcc cxx_ver=4.6 extras=mpi -j6

Now, all executables – mpi included – are under /rosetta_source/bin.

While /rosetta_source, and all subdirectories and files, had been recursively set

rwxr-xr-x root francesco

I changed /test recursively to

rwxr-xr-x francesco francesco

Then, tests could be run as user:

francesco@gig64:/usr/local/rosetta_source/test/integration$ ./integration.py -j6 -d /usr/local/rosetta_database
Running fold_and_dock on localhost …
Running AnchoredPDBCreator on localhost …
Running pepspec_anchor_dock on localhost …Running loop_modeling on localhost …

Running docking_full_protocol on localhost …
Running backrub on localhost …
Finished pepspec_anchor_dock in 6 seconds [~6 test (8%) started, 65 in queue]
Running score_only_silence on localhost …
Finished fold_and_dock in 7 seconds [~7 test (9%) started, 64 in queue]
Running hotspot_graft on localhost …
Finished AnchoredPDBCreator in 11 seconds [~8 test (11%) started, 63 in queue]
Running rotamer_probability on localhost …
Finished score_only_silence in 7 seconds [~9 test (12%) started, 62 in queue]
Running pepspec on localhost …
Finished backrub in 16 seconds [~10 test (14%) started, 61 in queue]
Running features on localhost …
Finished loop_modeling in 17 seconds [~11 test (15%) started, 60 in queue]
Running combine_silent on localhost …
Finished combine_silent in 0 seconds [~12 test (16%) started, 59 in queue]
Running rosetta_scripts_setup on localhost …
Finished features in 2 seconds [~13 test (18%) started, 58 in queue]
Running membrane_relax on localhost …
Finished docking_full_protocol in 19 seconds [~14 test (19%) started, 57 in queue]
Running UBQ_E2_thioester on localhost …
Finished rosetta_scripts_setup in 4 seconds [~15 test (21%) started, 56 in queue]
Running ppk on localhost …
Finished ppk in 5 seconds [~16 test (22%) started, 55 in queue]
Running kinematic_looprelax on localhost …
Finished rotamer_probability in 22 seconds [~17 test (23%) started, 54 in queue]
Running abinitio on localhost …
Finished hotspot_graft in 31 seconds [~18 test (25%) started, 53 in queue]
Running match on localhost …
Finished UBQ_E2_thioester in 18 seconds [~19 test (26%) started, 52 in queue]
Running mpi_multistate_design on localhost …
Finished abinitio in 9 seconds [~20 test (28%) started, 51 in queue]
Running FloppyTail on localhost …
Finished mpi_multistate_design in 5 seconds [~21 test (29%) started, 50 in queue]
Running metalloprotein_abrelax on localhost …
Finished kinematic_looprelax in 20 seconds [~22 test (30%) started, 49 in queue]
Running docking_prepack on localhost …
Finished pepspec in 38 seconds [~23 test (32%) started, 48 in queue]
Running fast_relax on localhost …
Finished docking_prepack in 5 seconds [~24 test (33%) started, 47 in queue]
Running geometric_solvation on localhost …
Finished metalloprotein_abrelax in 13 seconds [~25 test (35%) started, 46 in queue]
Running docking_ensemble_prepack on localhost …
Finished FloppyTail in 18 seconds [~26 test (36%) started, 45 in queue]
Running score12_docking on localhost …
Finished geometric_solvation in 6 seconds [~27 test (38%) started, 44 in queue]
Running membrane_abinitio on localhost …
Finished docking_ensemble_prepack in 9 seconds [~28 test (39%) started, 43 in queue]
Running HOW_TO_MAKE_TESTS on localhost …
Finished HOW_TO_MAKE_TESTS in 0 seconds [~29 test (40%) started, 42 in queue]
Running cluster on localhost …
Finished cluster in 3 seconds [~30 test (42%) started, 41 in queue]
Running place_simultaneously on localhost …
Finished score12_docking in 15 seconds [~31 test (43%) started, 40 in queue]
Running AnchoredDesign on localhost …
Finished membrane_abinitio in 18 seconds [~32 test (45%) started, 39 in queue]
Running sequence_recovery on localhost …
Finished fast_relax in 35 seconds [~33 test (46%) started, 38 in queue]
Running centroid_disulfide_scores on localhost …
Finished centroid_disulfide_scores in 1 seconds [~34 test (47%) started, 37 in queue]
Running fold_cst_new on localhost …
Finished sequence_recovery in 9 seconds [~35 test (49%) started, 36 in queue]
Running AnchorFinder on localhost …
Finished fold_cst_new in 11 seconds [~36 test (50%) started, 35 in queue]
Running docking_ensemble on localhost …
Finished membrane_relax in 85 seconds [~37 test (52%) started, 34 in queue]
Running docking_local_refine_min on localhost …
Finished match in 68 seconds [~38 test (53%) started, 33 in queue]
Running rna_design on localhost …
Finished docking_local_refine_min in 4 seconds [~39 test (54%) started, 32 in queue]
Running score_jd2 on localhost …
Finished AnchoredDesign in 34 seconds [~40 test (56%) started, 31 in queue]
Running sequence_tolerance on localhost …
Finished score_jd2 in 3 seconds [~41 test (57%) started, 30 in queue]
Running classic_relax_1a19 on localhost …
Finished AnchorFinder in 22 seconds [~42 test (59%) started, 29 in queue]
Running cstfile_to_theozyme_pdb on localhost …
Finished cstfile_to_theozyme_pdb in 3 seconds [~43 test (60%) started, 28 in queue]
Running mr_protocols on localhost …
Finished sequence_tolerance in 5 seconds [~44 test (61%) started, 27 in queue]
Running extract_atomtree_diffs on localhost …
Finished extract_atomtree_diffs in 4 seconds [~45 test (63%) started, 26 in queue]
Running BuildPeptide on localhost …
Finished classic_relax_1a19 in 8 seconds [~46 test (64%) started, 25 in queue]
Running super_aln on localhost …
Finished BuildPeptide in 0 seconds [~47 test (66%) started, 24 in queue]
Running orbitals on localhost …
Finished super_aln in 2 seconds [~48 test (67%) started, 23 in queue]
Running docking_site_constraints on localhost …
Finished orbitals in 4 seconds [~49 test (69%) started, 22 in queue]
Running docking_local_refine on localhost …
Finished mr_protocols in 13 seconds [~50 test (70%) started, 21 in queue]
Running threading on localhost …
Finished rna_design in 28 seconds [~51 test (71%) started, 20 in queue]
Running database_jd2_io on localhost …
Please install the sqlite3 command line application to correctly run this test.
Finished database_jd2_io in 2 seconds [~52 test (73%) started, 19 in queue]
Running ligand_motif_design on localhost …
Finished docking_site_constraints in 25 seconds [~53 test (74%) started, 18 in queue]
Running score_aln on localhost …
Finished score_aln in 0 seconds [~54 test (76%) started, 17 in queue]
Running gen_apo_grids on localhost …
Finished docking_local_refine in 24 seconds [~55 test (77%) started, 16 in queue]
Running fixbb on localhost …
Finished ligand_motif_design in 18 seconds [~56 test (78%) started, 15 in queue]
Running flexpepdock on localhost …
Finished place_simultaneously in 86 seconds [~57 test (80%) started, 14 in queue]
Running ddG_of_mutation on localhost …
Finished gen_apo_grids in 10 seconds [~58 test (81%) started, 13 in queue]
Running features_parallel on localhost …
Finished features_parallel in 0 seconds [~59 test (83%) started, 12 in queue]
Running antibody on localhost …
Finished fixbb in 21 seconds [~60 test (84%) started, 11 in queue]
Running rs_flexbbmoves on localhost …
Finished threading in 55 seconds [~61 test (85%) started, 10 in queue]
Running symmetric_docking on localhost …
Finished rs_flexbbmoves in 18 seconds [~62 test (87%) started, 9 in queue]
Running rna_denovo on localhost …
Finished symmetric_docking in 7 seconds [~63 test (88%) started, 8 in queue]
Running docking_low_res on localhost …
Finished docking_low_res in 4 seconds [~64 test (90%) started, 7 in queue]
Running fragment_picker on localhost …
Finished fragment_picker in 4 seconds [~65 test (91%) started, 6 in queue]
Running ligand_dock_7cpa on localhost …
Finished antibody in 46 seconds [~66 test (92%) started, 5 in queue]
Running ligand_dock_grid on localhost …
Finished rna_denovo in 15 seconds [~67 test (94%) started, 4 in queue]
Running extract_pdbs on localhost …
Finished extract_pdbs in 0 seconds [~68 test (95%) started, 3 in queue]
Running ligand_dock_script on localhost …
Finished flexpepdock in 57 seconds [~69 test (97%) started, 2 in queue]
Running gen_lig_grids on localhost …
Finished gen_lig_grids in 4 seconds [~70 test (98%) started, 1 in queue]
Running InterfaceAnalyzer on localhost …
Finished ddG_of_mutation in 65 seconds [~71 test (100%) started, 0 in queue]
Finished ligand_dock_grid in 19 seconds [~71 test (100%) started, 0 in queue]
Finished ligand_dock_7cpa in 25 seconds [~71 test (100%) started, 0 in queue]
Finished InterfaceAnalyzer in 24 seconds [~71 test (100%) started, 0 in queue]
Finished docking_ensemble in 167 seconds [~71 test (100%) started, 0 in queue]
Finished ligand_dock_script in 75 seconds [~71 test (100%) started, 0 in queue]

Just generated ‘ref’ results; run again after making changes.
francesco@gig64:/usr/local/rosetta_source/test/integration$

I would be very grateful for indicating what to do now, i.e., what are the suggested changes, and where they should be done.

thanks a lot, chiendarret

[Anonymous]

To be more specific in my question about evaluating the test carried out, take “AnchoredPDBCreator”:

in /test/integration/ref/AnchoredPDBCreator folder, two new files were generated by the test:

sc_loop_insertBC_1_noFGdel_0001.pdb

and

score.sc

The PDB file ( which opens beautifully with a pdb viewer) ends with
# All scores below are weighted scores, not raw scores.
#BEGIN_POSE_ENERGIES_TABLE sc_loop_insertBC_1_noFGdel_0001.pdb
label total
weights NA
pose#END_POSE_ENERGIES_TABLE sc_loop_insertBC_1_noFGdel_0001.pdb
LoopAnalyzerMover: unweighted bonded terms and angles (in degrees)
position phi_angle psi_angle omega_angle peptide_bond_C-N_distance rama_score omega_score dunbrack_score peptide_bond_score chainbreak_score
pos phi_ang psi_ang omega_ang pbnd_dst rama omega_sc dbrack pbnd_sc cbreak
17 -106.8 175.8 178.2 1.322 0.998 0.0342 7.01 -2.68 0.0182
18 -96.83 109.6 -175.1 1.329 -0.833 0.238 6.57 -3.42 0.223
19 -148.4 161.9 179.5 1.329 0.146 0.00258 0 -3.43 0.0307
20 -65.25 157.4 -177 1.329 -1.18 0.0882 0.578 -3.43 0.0827
21 -54.29 -35.03 175.1 1.329 -0.753 0.239 0 -3.43 1.33
22 -70.22 159.9 -179.8 1.326 -0.941 0.000404 0.938 -3.45 0.0424
23 -72.63 130.1 179.4 1.325 -1.29 0.00372 0.24 -3.46 0.0281
24 -94.91 116.5 179.8 1.323 -1.21 0.00028 0.721 -3.45 0.0694
25 -65.42 150.7 179.4 1.335 -1.58 0.004 0 -3.32 1.38
26 -64.68 147.9 179.1 1.323 -1.45 0.0079 1.61 -3.32 0.211
27 -56.44 -66.21 180 1.329 1.26 2.02e-28 7.89 -3.43 2.37e-05
28 -123.3 -54.87 178.8 1.329 1.74 0.0135 0.504 -3.43 0.0127
29 -123.3 25.92 -175.2 1.204 0.234 0.226 2.34 20 2.36
30 81.01 -134.7 -177.2 1.329 20 0.0805 5.04 20 0.0846
31 -112.9 147.2 172.7 1.318 -0.744 0.538 0.534 -3.35 1.38
total_rama 14.3861
total_omega 1.47597
total_peptide_bond -3.7078
total_chainbreak 7.25145
total rama+omega+peptide bond+chainbreak 19.4057

LAM_total 19.4057
*********

The score.sc file reads:
SEQUENCE:
SCORE: total_score LAM_total description
SCORE: 0.000 19.406 sc_loop_insertBC_1_noFGdel_0001
************

How should I interpret the above in the context of the last line of the test output on the screen:
“Just generated ‘ref’ results; run again after making changes.”

thanks for advice, chiendarret

[Anonymous]

Around the time 3.4 was branched, we got the code clean to the point that it was warning-free with at least our test server’s compiler (which is an ancient GCC, I think). It’s nowhere near clean in clang…

Within the next few months, someone in the community (probably me) will be rearranging our release process so that we have “rolling releases” on an approximately weekly basis. Let me see if the developer community wants to release binaries or not – I suspect there would be. Generally it’s something we don’t do for lack of experience and manpower to test on different platforms.

[Author]

Posts