I'm trying to model the binding of an antibody to a citrullinated peptide. I've created rotlibs and params files for the citrulline amino acid following the protocol in Renfrew, et al. "Incorporation of Noncanonical Amino Acids into Rosetta and Use in Computational Protein-Peptide Interface Design", doi:10.1371/journal.pone.0032637. Now I'm trying to use SnugDock to model the antibody:antigen binding, but I keep hitting the following error.
ERROR: Failed to apply a PatchOperation to CIT
ERROR:: Exit from: src/core/chemical/Patch.cc line: 339
I've attached relevant files below. Does anyone have any suggestions?
Much thanks in advance.
I'm uploading my flags file too just in case that turns out to be helpful.
Can you run with the flag -out:level 500 so we get more log-file output? (That's the 'loudest' it goes.)
The file is over the 512 kb limit so I'll link it here: https://s3.amazonaws.com/sarah-testbucket/using_ncaas_protein_peptide_interface_design/SnugDock/2_snugdock/outputs/logFile2_cit_lvl500. Let me know if that doesn't work.
Here's a snippet of the lines right before the error:
core.chemical.PatchOperations.hh: AddAtom::apply: VCT1 VIRT VIRT 0
core.chemical.PatchOperations.hh: AddAtom::apply: NT1 Nhis NR2 -0.31
core.chemical.PatchOperations.hh: AddAtom::apply failed: CIT already has an atom named ' NT2'.
I'm new to all this--only playing with Rosetta for <1 month. What is the purpose of this patch operation? Do I need to rename the atoms in the CIT params file?
Thanks for your help.
"Patches" essentially prepare the different chemical forms of a particular platonic ResidueType. The clearest example might be that e.g. the lysine ResidueType represents internal lysine, with two polymeric connections, but we need N-terminal and C-terminal forms too. In this case, there's atom naming overlap between some patch (in this case, 'triazolamerN') and your ResidueType. The easiest option is just to rename the atoms in your params file.
Perfect, it's running now. Thanks so much for your help and for the explanation.
I'm getting another error in the same program. It's running further than last time but still not getting all the way through.
Progress since last post:
1) Fixed patchoperations issue by renaming NT2 atoms in params file and input pdb file.
2) Ran Snugdock, got this error:
cannot find a residue type that matches the residue CIT at position 237
ERROR: core::util::switch_to_residue_type_set fails
Based on previous forum posts, I determined this was due to a lack of centroid params files for my residue. I created one (based heavily on the arginine centroid params file since the two residues are related) and added it to the database. I also added the path 'residue_types/l-caa/CIT.params' to the ~/rosetta/main/database/chemical/residue_type_sets/centroid/residue_types.txt file.
3) Ran Snugdock again, but this time I get:
core.scoring.vdwaals.VDW_Energy: calculating hydrogen_interaction_cutoff
core.scoring.vdwaals.VDW_Energy: Did not find any hydrogen atoms in atom type set centroid
core.conformation.Interface: Calculating protein-protein interface
Got some signal... It is:6
Process was aborted!
I ran a backtrace with gdb:
core.conformation.Interface: Calculating protein-protein interface
snugdock.linuxgccdebug: src/ObjexxFCL/FArray2D.hh:395: const T& ObjexxFCL::FArray2D< <template-parameter-1-1> >::operator()(int, int) const [with T = double]: Assertion `( I1_.contains( i1 ) ) && ( I2_.contains( i2 ) )' failed.
Program received signal SIGABRT, Aborted.
0x00007ffff34e20d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#0 0x00007ffff34e20d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff34e583b in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff34dad9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#3 0x00007ffff34dae42 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x00007ffff4f62d3a in ObjexxFCL::FArray2D<double>::operator() (this=0x3251b08, i1=5, i2=74) at src/ObjexxFCL/FArray2D.hh:395
#5 0x00007fffec919e1c in protocols::scoring::InterchainPotential::evaluate_pair_and_vdw_score (this=0x3251a30, pose=..., rsd1=..., rsd2=..., pair_contribution=@0x7fffffffbd70: 0, vdw_contribution=@0x7fffffffbd78: 0) at src/protocols/scoring/InterchainPotential.cc:249
#6 0x00007fffecaaae78 in protocols::scoring::methods::InterchainPairEnergy::residue_pair_energy (this=0x3b6fe80, rsd1=..., rsd2=..., pose=..., emap=...) at src/protocols/scoring/methods/InterchainPairEnergy.cc:108
#7 0x00007fffe7e4f919 in core::scoring::ScoreFunction::eval_ci_2b (this=0x3b73740, rsd1=..., rsd2=..., pose=..., emap=...) at src/core/scoring/ScoreFunction.cc:1490
#8 0x00007fffe7e4e51a in core::scoring::ScoreFunction::eval_twobody_neighbor_energies (this=0x3b73740, pose=...) at src/core/scoring/ScoreFunction.cc:1227
#9 0x00007fffe7e4b9be in core::scoring::ScoreFunction::operator() (this=0x3b73740, pose=...) at src/core/scoring/ScoreFunction.cc:741
#10 0x00007ffff078854a in protocols::docking::DockingSlideIntoContact::apply (this=0x7fffffffd050, pose=...) at src/protocols/docking/DockingInitialPerturbation.cc:563
#11 0x00007ffff0786259 in protocols::docking::DockingInitialPerturbation::apply_body (this=0x3222440, pose=..., jump_number=1) at src/protocols/docking/DockingInitialPerturbation.cc:395
#12 0x00007ffff07854f6 in protocols::docking::DockingInitialPerturbation::apply (this=0x3222440, pose=...) at src/protocols/docking/DockingInitialPerturbation.cc:290
#13 0x00007ffff079fcd8 in protocols::docking::DockingProtocol::apply (this=0x3259a30, pose=...) at src/protocols/docking/DockingProtocol.cc:948
#14 0x00007ffff6f34fea in protocols::antibody::snugdock::SnugDockProtocol::apply (this=0x317d640, pose=...) at src/protocols/antibody/snugdock/SnugDockProtocol.cc:181
#15 0x00007ffff5e2fcca in protocols::jd2::JobDistributor::run_one_job (this=0xfa06e0, mover=..., allstarttime=1483650695, last_inner_job_tag=..., last_output_tag=..., last_batch_id=@0x7fffffffde28: 0, retries_this_job=@0x7fffffffde30: 0, first_job=true) at src/protocols/jd2/JobDistributor.cc:687
#16 0x00007ffff5e2e0ae in protocols::jd2::JobDistributor::go_main (this=0xfa06e0, mover=...) at src/protocols/jd2/JobDistributor.cc:302
#17 0x00007ffff5e07934 in protocols::jd2::FileSystemJobDistributor::go (this=0xfa06e0, mover=...) at src/protocols/jd2/FileSystemJobDistributor.cc:229
#18 0x00000000004043c7 in main (argc=4, argv=0x7fffffffe028) at src/apps/public/antibody/snugdock.cc:77
I'm at a complete loss to interpret it. I'm wondering if I made the centroid params file incorrectly, or if the program isn't finding it, or if it's something else entirely. I'm attaching the centroid param file. The logfile is here: https://s3.amazonaws.com/sarah-testbucket/using_ncaas_protein_peptide_interface_design/SnugDock/2_snugdock/outputs/logFile2_cit_lvl500_NT2toNAparamspdb_centroid3
Thanks in advance.
Unfortunatly the centroid energy function is knowledge-based and its terms are parameterized based on the residue type. The centroid energy function does not have scoring parameters for citruline, only the 20 canonical amino acids. The code is failing in the function evaluate_pair_and_vdw_score in the InterchainPotential when rosetta tries to look up some parameters based on a residue type and over steps an array boundary. You could try changing the AA tag in your centroid params file from AA UNK to AA ARG; this would treat your residue as ARG in centroid mode. Alternativly you could try to do all modleing in full atom mode.
Much thanks for your response. It looks like changing from AA UNK to AA ARG doesn't work -- I get an "! found_aa_difference" error. If I also switch IO_STRING from CIT to ARG, it runs a little further but then crashes with "ERROR: ReturnSidechainMover used with poses of different sequence; aborting". I'm guessing maybe it runs low res in centroid mode with arginine, but then can't convert back to citrulline when adding back side chains?
Modelling in full atom mode did work! It accepted the new residue. Would be nice to have the low res docking working in centroid mode, but regardless I'm very happy to have NCAAs working in rosetta.