I run the score_jd2 program to calculate the total energy of the pdb structure.
score_jd2.linuxgccrelease -database rosetta_database/ -s 1xnz.1.A.2.A_0001.pdb
and get a file named score.sc
SCORE: -249.622 -1098.702 251.556 555.107 2.612 11.728 -24.622 -55.572 -81.320 -24.066 -15.083 0.000 0.000 0.000 0.000 -4.476 3.227 294.517 -24.189 -40.340 0.000 0.000 0.000 1xnz.1.A.2.A_0001_0001
The 1st value follows SCORE should the total score of this structure. But if I look at the structure, there is one line says that
label fa_atr fa_rep fa_sol fa_intra_rep pro_close fa_pair hbond_sr_bb hbond_lr_bb hbond_bb_sc hbond_sc dslf_ss_dst dslf_cs_ang dslf_ss_dih dslf_ca_dih rama omega fa_dun p_aa_pp ref total
weights 0.8 0.44 0.65 0.004 1 0.49 0.585 1.17 1.17 1.1 0.5 2 5 5 0.2 0.5 0.56 0.32 1 NA
pose -1098.7 251.634 555.107 2.61177 11.7281 -24.6223 -55.5761 -81.327 -24.0663 -15.0805 0 0 0 0 -4.4763 3.22748 294.517 -24.189 -40.34 -249.553
Does the last number is the total score of this structure? If so, why these two number is different? Thank you
You are correct that the final number in the score set within the PDB (-249.553) is the total score, as is the first column of the scorefile (-249.622).
It looks to me from the filenames that you've taken a Rosetta-output PDB 1xnz.1.A.2.A_0001.pdb, which contains a score -249.553, and re-scored it with score_jd2 and instead gotten a score of -249.622.
If that's what you did, it's fine: the scorefunction is much more sensitive than the PDB is precise. 3 decimal digits is not enough precision to place atoms for modeling purposes, but it's what the PDB uses. The score changes because there is enough error in PDB rounding to change the score. (It's surprising the score went down...)
I got the pdb structure by fixbb design. And then I use score_jd2 to score it.
It looks like the difference is coming mainly from fa_rep, so I'm guessing the result is due to rounding issues - specifically rounding issues of the coordinates.
Internally, the atom coordinates are stored as double precision floating point numbers, which gives somewhere around 15 decimal digits of precision. Those are the coordinates that the fixbb design protocol uses to calculate the score in the scorefile. However, a PDB has a fixed-point representation, with only a limited number (3 past the decimal point, typically 4-6 total) of decimal digits. When the PDB is output, the coordinates are rounded to the nearest 0.001 Angstroms. The score_jd2 application only sees the rounded coordinates, and therefore calculates the scores based on them. Depending on the structure, these small +/-0.0005 Ang differences could add up, giving slight changes in energy - most noticeable in fa_rep, as that's the term most sensitive to small distance changes.
Given that the difference is relatively small, I wouldn't worry too much about it. There's really no way around the rounding if you want the output in PDB format - it's a limitation of the file format. If, for some unusual reason, you absolutely need that extra distance precision, you can try other output formats. I believe that the binary silent file format stores the complete precision of the coordinates, so if you were to use a binary silent file output with fixbb design, it should rescore the same when used as the input to score_jd2.
Thanks so much!