Error in RMSD calculation when native sequence deviates

[Anonymous]

Hi guys,

I wanted to reproduce the results in Gray et al. (2003) and have therefore downloaded Chen et al.’s benchmark set of 54 protein complexes. When I’m trying to run the docking_protocol in Rosetta3.1 on the unbound enzyme complex of 1BRS using the bound complex as a native structure, I get the following error message:

ERROR: Conformation: fold_tree nres should match conformation nres. conformation nres: 195 fold_tree nres: 197
ERROR:: Exit from: src/core/conformation/Conformation.cc line: 215

I run the docking_protocol with following paramters:
$ docking_protocol.linuxgccrelease -database rosetta_database -out:overwrite -out:file:fullatom -docking:dock_pert 3 8 -score:weights docking -in:file:s ../1BRS.pdb -in:file:native ../1BRS_c.pdb -out:file:o scores

The error occurs at the very end of the program execution. I believe it occurs when Rosetta tries to calculate the RMSD between the unbound complex and the native complex. A sequence alignment between both complexes shows that AA 169 and 170 is missing in the native complex:

../1BRS_c.pdb 151 XEYPLVLEXRQEQSKQLT–GAESVLQVFREAKAEADITIILS 191
../1BRS.pdb 151 XEYPLVLEXRQEQSKQLTENGAESVLQVFREAKAEADITIILS 193

Is there an option within Rosetta to circumvent this error? For example, is it possible to ask Rosetta to base its RMSD calculation on only those residues that align in a sequence alignment? What is your approach in situations like this? If possible, I would like to avoid the editing of PDB files, or at least keep it to a minimum.

Big thanks for you help
Abdullah

[Anonymous]

I’m not sure I fully understand what’s going on – you have more residues in your input through -s than in your input through -native? Why? Which is the original PDB file and which (if either) has been changed?

The error is probably due to all the residues being “present” in the PDB, but with some residues malformed – typically either missing backbone atoms or having 0 occupancy for some backbone atoms.

I doubt there is a flag to magically fix this. We patch up the PDB reader when we can identify the causes of bugs like these, but by and large we just edit PDBs as necessary to get Rosetta to read them in correctly. The PDB standards are not well adhered to (or they’re just vague), so the PDB reader is not robust against all PDBs, even straight from the database.

If you can find the RMSD call in the code, you would be able to pass that function call an AtomIDMap which would let you tell it to ignore certain residues – it’s likely attempting to do this already and is just failing on this particular case.

[Author]

Posts