When I did snugdock, my native input structure and snug input structure share the same number of residues and residue indexes, but the error still shows up "sequence position requested was greater than the number of residues in the pose".
I attach both files and appreciate any suggestion. Thanks!
There is a bit more information that would be helpful in troubleshooting. Can you share the command line and the log file?
In the command line, I would check that chain order in the input files is the same as the chain order specified. It looks like HL_A is the correct specification.
In the log file, check that residues are discarded because of missing backbone atoms. In particular, I noticed that the geometry is off at the C-terminal carboxylate in the antigen of the native PDB. There may be other residues discarded, and this would result in the error you are seeing. (Rosetta requires that all backbone atoms are present in order to build the residue.)
I hope that helps.
Rosetta Design Group
Thank you for your kind reply! I really appreciate it.
Before your reply, I found some hydrogen name differences in Histidine between these two pdb files, then I corrected them, and reran it. However, the same error still shows up.
Now I attach corrected native file: corr_native_input.pdb, snug.log, and ROSETTA_CRASH.log
command is like:
$ mpirun -n 10 $ROSETTA3_MPI/snugdock.mpi.linuxgccrelease -s snug_input.pdb -native corrr_native_input.pdb -out:path:all snug_output -auto_generate_h3_kink_constraint -h3_loop_csts_hr -spin false -dock_pert 1 0 -ex1 -ex2aro -partners HL_A -nstruct 2 &
Thanks again for your help!
Were you able to fix this error? I'm getting the same error even though the no. of residues and numbering are same. If I remove the native file, snugdock protocol runs fine.
My hypothesis is that what is happening under the hood is that a virtual root is not being removed. (I'd guess this was added during the robustification done in 2020/2021.) This virtual residue then makes the sequence length different between the input and native poses, causing the assertion that the length must match (in order to calculate RMSD) to fail. I haven't looked through the code, but that's what it feels like to me.
Is there a particular feature you are looking for by using the native? My best advice would be to re-implement the RMSD calculation using biopython or pymol (or even PyRosetta) and run it subsequently to the decoy generation.
Rosetta Design Group
Hello David and stannowitz,
Thank you very much for both of your answers. Sorry for my late reply.
Yes, when I run snugdock without "-native" option, snugdock works well (it uses input.pdb as its own reference structure). However, my native structure shares the same residue number and same residue / atom names with input structure.
I tried to use pyrosetta to do rmsd calculation >>> pyrosetta.rosetta.protocols.stepwise.modeler.align.superimpose_with_stepwise_aligner(native_pose, input_pose)
Because this is for the whole system RMSD calculation, and antibody residue indexes are renumbered by chothia scheme, so I have to find interface RMSD function and change chothia scheme back to normal index numbers.
Actually I do not quite understand the " virtual root" or "virtual residue" mentioned by David. Is this "virtual root/residue" a necessary step in calculation? If this is a bug, is it possilbe that Rosetta Design Group could fix it?