Member Site › Forums › Rosetta 3 › Rosetta 3 – General › core.scoring.rms_util: WARNING: CA_rmsd out of range…
- This topic has 4 replies, 2 voices, and was last updated 12 years, 6 months ago by
sokrypton.
-
AuthorPosts
-
-
February 26, 2012 at 12:14 am #1178
Hi, I have some question about how Rosetta3x read PDB files.
I was preparing my pdb files by the relax mode. The protein has 263 residues and another peptide ligand has 11 residues. From the log file, I found it recognized the 274 residues correctly, but somehow is expecting 275 residues for the rms_util and rotamers building. Below is part of the log file:…
core.import_pose.import_pose: original fold tree: FOLD_TREE EDGE 1 263 -1 EDGE 1 264 1 EDGE 264 274 -1
core.import_pose.import_pose:
core.import_pose.import_pose: new fold tree FOLD_TREE EDGE 1 263 -1 EDGE 1 264 1 EDGE 264 274 -1
core.import_pose.import_pose:
core.pack.task: Packer task: initialize from command line()
core.import_pose.import_pose: build_pose… Ok.
…IntraRes: 0 InterRes: 277 NonRes: 0
protocols.relax.FastRelax: Command: repeat
core.scoring.rms_util: WARNING: CA_rmsd out of range… range1 275 requested but only 274 CA atoms found in fill_rmsd_coordinates
core.scoring.rms_util: WARNING: CA_rmsd out of range… range1 275 requested but only 274 CA atoms found in fill_rmsd_coordinates
protocols.relax.FastRelax: CMD: repeat 461.609 0 0 0.44
protocols.relax.FastRelax:
Scores Weight Raw Score Wghtd.Score
fa_atr 0.800 -1336.455 -1069.164
fa_rep 0.440 1835.746 807.728
fa_sol 0.650 815.507 530.080
fa_intra_rep 0.004 400.705 1.603
pro_close 1.000 22.510 22.510
fa_pair 0.490 -40.232 -19.714
hbond_sr_bb 0.585 -101.177 -59.188
hbond_lr_bb 1.170 -81.615 -95.490
hbond_bb_sc 1.170 -26.062 -30.493
hbond_sc 1.100 -4.864 -5.351
dslf_ss_dst 0.500 0.000 0.000
dslf_cs_ang 2.000 0.000 0.000
dslf_ss_dih 5.000 0.000 0.000
dslf_ca_dih 5.000 0.000 0.000
atom_pair_constraint 10.000 8.457 84.571
coordinate_constraint 10.000 0.000 0.000
angle_constraint 10.000 0.000 0.000
dihedral_constraint 10.000 0.000 0.000
rama 0.200 45.614 9.123
omega 0.500 120.383 60.191
fa_dun 0.560 513.917 287.794
p_aa_pp 0.320 -82.347 -26.351
ref 1.000 -36.240 -36.240
Total weighted score: 461.609
IntraRes: 0 InterRes: 277 NonRes: 0
protocols.relax.FastRelax: Command: ramp_repack_min
core.pack.interaction_graph.interaction_graph_factory: Instantiating DensePDInteractionGraph
core.pack.pack_rotamers: built 10946 rotamers at 275 positions.
core.pack.pack_rotamers: IG: 30936896 bytes
…The program still completed normally. When I check the generated pdb file, the 275th residue is labeled VRT. As I know, it is a virtual residue, right? So why does it appear in the scoring and rotamer building step. In this case, can I trust the generated decoy?
p.s. I also tried relaxing the protein without the ligand. It has the same warning, recognizing 263 residue but expecting 264 CA.
-
February 26, 2012 at 6:07 pm #6697
Anonymous
I don’t know why a virtual residue is showing up in your trajectory. I know they are used in the symmetry mode and the fit-to-density modes (which you aren’t using). There may be one involved in coordinate constraints (which you also don’t appear to be using). If the extra residue is last, then it probably won’t cause any problems in residue matching for RMSD, so you’re probably ok.
-
February 26, 2012 at 7:14 pm #6701
Thanks!
I did have some atompair constraints and used the option -constrain_relax_to_start_coords. Is that coordinate constraints? My concern is mainly with the rotamer building since I’m not sure what it means to build rotamers for the virtual residue. But so far the result seems ok just as you said. -
February 26, 2012 at 7:27 pm #6702
Anonymous
Coordinate constraints are a likely culprit. Do a test run without them and see if the warning shows up?
The virtual residue should have no impact on packing: Rosetta won’t bother building any rotamers for it, won’t try to pack it, and since it’s virtual, won’t bother scoring it either.
-
February 27, 2012 at 3:17 am #6703
Yes, you are right. The virtual residue disappeared after I removed the constraint_to_start_coords option. I think my problem is fully solved. Thanks a lot!
-
-
AuthorPosts
- You must be logged in to reply to this topic.