Member Site › Forums › Rosetta 3 › Rosetta 3 – General › Using Patches in Rosetta
- This topic has 6 replies, 2 voices, and was last updated 14 years, 5 months ago by
Anonymous.
-
AuthorPosts
-
-
March 10, 2010 at 9:32 pm #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
-
March 11, 2010 at 3:03 pm #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…)
-
March 11, 2010 at 10:22 pm #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
-
March 12, 2010 at 2:53 pm #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_SELECTORBEGIN_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!
-
March 12, 2010 at 9:17 pm #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 Abinitiocore.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 faultUsing 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 faultI 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! -
March 15, 2010 at 3:36 pm #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…
-
March 16, 2010 at 10:43 am #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
-
-
AuthorPosts
- You must be logged in to reply to this topic.