Using Patches in Rosetta

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

Viewing 6 reply threads
  • Author
    Posts
    • #503
      Anonymous

        Hello,

        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!

        JS

      • #4401
        Anonymous

          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:

          PPGLC[CYZ]PRC[CYZ]KKGYH[HIS_D]WKSEC[CYZ]KSKFDKDGNPLPPZ[ZN]

          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
          Anonymous

            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!

            JS

          • #4403
            Anonymous

              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:

              ~~~~~~~~~~~~~~~~~~~begin~~~~~~~~~~~~~~~~~~~~~~`

              NAME sulfated
              TYPES SULFATION

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

              BEGIN_SELECTOR
              PROPERTY PROTEIN
              AA TYR
              NOT VARIANT_TYPE PHOSPHORYLATION ## Just in case
              NOT VARIANT_TYPE SULFATION
              NOT VARIANT_TYPE PROTONATED
              NOT VARIANT_TYPE DEPROTONATED
              END_SELECTOR

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

              ADD_PROPERTY CHARGED ## For the sulfate group

              END_CASE

              ~~~~~~~~~~~~~~~~~~~~~~~end~~~~~~~~~~~~~~~~~~~~“`

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

            • #4404
              Anonymous

                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
                core.io.database: Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_SS_distance_score
                core.io.database: Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CaCbS_angle_score
                core.io.database: 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
                core.io.database: Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_SS_distance_score
                core.io.database: Database file opened: /Applications/Rosetta/rosetta_database/scoring/score_functions/disulfides/fa_CaCbS_angle_score
                core.io.database: 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:
                protocols.relax.ClassicRelax:
                protocols.relax.ClassicRelax:

                ===================================================================
                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
                Anonymous

                  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
                  Anonymous

                    Hi,

                    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

                    JS

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