Using Patches in Rosetta

Member Site Forums Rosetta 3 Rosetta 3 – General Using Patches in Rosetta

Viewing 6 reply threads
  • Author
    • #503


        I’d like to work with a sulfated tyrosin, and I have noticed that there is a patch for this special problem. Unfortunately I couldn’t figure out in which modes (Abinitio …) this patch can be applied and how to apply it.

        I’d appreciate any help regarding this topic!


      • #4401

          Generally speaking the patched residue types are automatically detected by the PDB reader. So, if you’ve already got a PDB, it ought to apply automatically for any structure that has one. This would work for most applications that take PDBs.

          Abinitio is not my area of expertise, but I believe there’s an “extended FASTA” format brewed up for Rosetta. Here’s an example from one of the metalloprotein abrelax benchmarks:


          I think if you put your SO3-Tyr in with the [syntax] it might work. I think the patched name is [TYR_p:sulfated]. If this is a terminus residue, or has anything else weird about it, that name needs to change to reflect it.

          Also, make sure the patch is on by default in patches.txt (which I assume you found…)

        • #4402

            Thank you for the fast reply, unfortunately I still couldn’t get it to work.

            When I try to use the patch in Abinitio with the altered FASTA-file, the patch is not recognized because only the patches for the centroid residue-type-set are loaded, but the patch applies only to the fa-standard set. Referencing the patch in the centroid patch.txt-file only results in another error. I haven’t found any option that results in the fa-standard residue-type-set being used when the fasta-file is checked instead of the centroid one even though the generated files are full-atom structures (-return_full_atom, or -in:file:fullatom didn’t change anything).
            Besides this does it matter that the sulfation is not included in the fragment libraries?

            I also tried inserting the sulfation with another program in a structure generated with Abinitio. After modifying the pdb-file to match the format of the pdb-files generated by rosetta the sulfation is recognized but the program terminates with a segmentation fault.
            So what does segmentation fault mean and is there any way to avoid it?

            I’d welcome any further suggestions!


          • #4403

              A couple of things:

              1) I failed to check that the formatting didn’t break – all the special residues are supposed to be surrounded by square brackets, which the formatting turned into underscores (perhaps you knew this?)

              2) I forgot about centroid for abinitio. The sulfur won’t make any difference in centroid mode (it’s not fine grained enough), but I see why it was giving you problems. You should try creating a centroid tyrosine sulfate patch. Then maybe it will do centroid with tyrosine, and then convert it to fullatom centroid when it switches into fullatom mode. I think it would look something like this:


              NAME sulfated
              TYPES SULFATION

              ## general requirements for this patch
              ## require protein, ignore anything that’s already nterm patched:

              PROPERTY PROTEIN
              AA TYR
              NOT VARIANT_TYPE PHOSPHORYLATION ## Just in case

              BEGIN_CASE ### THE GENERAL CASE ##########################################

              ADD_PROPERTY CHARGED ## For the sulfate group



              3) Just knowing that there’s a segfault is not enough for me to diagnose, sorry!

            • #4404

                First of all thanks for taking the time to bother with this problems!

                Using the suggested patch in Abinitio centroid mode only resulted in following segmentation fault after Abinitio:

                Finished Abinitio

                core.scoring.ScoreFunctionFactory: SCOREFUNCTION: standard
                core.scoring.ScoreFunctionFactory: SCOREFUNCTION PATCH: score12
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_SS_distance_score
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CaCbS_angle_score
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CbSSCb_dihedral_score
                core.scoring.dunbrack: Dunbrack library took 0.06947 seconds to load from binary
                Segmentation fault

                Using a modified pdb file in the relax Application, the error message comes after following lines:

                protocols.jd2.PDBJobInputter: filling pose from PDB FSH_S_a_000019073.pdb
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_SS_distance_score
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CaCbS_angle_score
       Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CbSSCb_dihedral_score
                core.scoring.dunbrack: Dunbrack library took 0.068129 seconds to load from binary
                core.pack.task: Packer task: initialize from command line()
                core.pack.task: Packer task: initialize from command line()

                protocols.relax.ClassicRelax: Stage 1
                protocols.relax.ClassicRelax: Ramping repulsives with 8 outer cycles and 1 inner cycles
                Segmentation fault

                I assume it has something to do with the format of the pdb-file but I’m not quite sure.
                Is there any other information that might be helpful!

              • #4406

                  seg-fault doesn’t mean enough to help.

                  You can try compiling in debug mode and re-running; that will usually give a more informative error. (Replace mode=release with mode=debug when you compile). This will take probably 10x longer to run.

                  I suspect the error is going to be a generic vector overrun error anyway, so I’m not sure that will be useful…

                • #4410


                    in debug mode there’s always following assertion failure:

                    Assertion failed: (static_cast< size_type >( i – l_ ) < super::size()), function operator[], file src/utility/vectorL.hh, line 341. Is there any chance the sulfation patch has been successfully applied and that it’s just me using it wrong?
                    If not is there another program for protein-protein docking that might be able to handle the modified tyrosine?

                    Thank’s in advance


                Viewing 6 reply threads
                • You must be logged in to reply to this topic.