I am a newbie in working with Rosetta. I used a flexpeptdock protocol to dock a peptide into protein. I tried to use scoring protocol and extract information from a silent file (result from docking) with 100 poses. After running "score.linuxgccrelease" with the default commands, rosetta starts and freeze with:
protocols.jobdist.JobDistributors: (0) Master Node -- Waiting for job request; tag_ = 1
Before I started Rosetta I compiled it with the mpi option. Is it possible this to be the reason for freezing?
It's freezing because you're using the MPI build of Rosetta on only one processor. By default, the first processor designates itself the head node and allocates jobs to the other nodes. You've only got one node, so there are no other nodes to do any work.
If you're just extracting PDBs, use the non-MPI build of Rosetta (look for score_jd2.default.linuxgccrelease in the bin folder; you may need to recompile to get it). MPI will work with extraction, but it won't actually accelerate it any since it's a linear process, so you could just make sure it's a two-or-more processor job.
Note that the bin folder will contain many kinds of executables:
The one with no insertion in the middle is just whatever you've compiled most recently. The one with MPI is the MPI build, and the one with default is the non-mpi build. I suggest always using the one with an insertion so you know what you're getting.
Thanks a lot,
I used 'score_jd2.linuxgccrelease' and it worked OK for me.
I have few pdb files and I'm looking individual residue energies for each of them, not only total energy.
How can I get those energy value?
Off the top of my head, try score_jd2 with the -out:pdb flag. It will make duplicate copies of the input PDBs with the per-residue/per-term scores listed in a big table at the end of the PDB.
There is no easy way to get per-atom energies, by the way (Rosetta only stores energies on a per residue basis, so per-atom energies would have to be emitted at scoring time).
Also, you will note inconsistencies in the column/row totals of this table. The culprit is that hydrogen bond energies are not stored on a per-residue basis, but on a per-Pose basis (for speed reasons). I don't think there is a command line override for this...I looked just now and didn't see one; if hbonds are specifically what you need I'll dig again.
I am puzzled by your comment: "The culprit is that hydrogen bond energies are not stored on a per-residue basis, but on a per-Pose basis (for speed reasons). "
If this is the case, what are the values listed in columns "hbond_sr_bb hbond_lr_bb hbond_bb_sc hbond_sc" at the end of pdb output of program:
score_jd2.linuxgccrelease -s mypdbinput.pdb -out:pdb
They do not look like same floats averaged from some total energy value.
The whole-pose hydrogen bonding information is just for the backbone-backbone hydrogen bonding. Backbone-sidechain and sidechain-sidechain hydrogen bonds are broken down on a per-residue level by default.
So when I run that command, I get non-zero values in all hbond terms for the "pose" line, as well as non-zero values for some residues in the hbond_bb_sc and hbond_sc columns, but all the per-residue columns for the hbond_sr_bb and hbond_lr_bb columns are zero, despite there being a non-zero pose total for those terms.
That's right. Thanks for the explanation, rmoretti!