Member Site › Forums › Rosetta 3 › Rosetta 3 – Applications › Membrane homology modeling loop building gives very strange outputs
- This topic has 2 replies, 2 voices, and was last updated 9 years, 11 months ago by
Anonymous.
-
AuthorPosts
-
-
September 30, 2014 at 9:46 pm #2017
Anonymous
I’ve been working on a homology model of a spanning helical membrane protein. The options I’m using seem to work for a somewhat similar protein, so I can’t figure out what the problem is. Essentially, the problem with the decoys is two fold:
1. The helices do not bundle, nor do they consistently stay approximately normal to the membrane. I get very spread out structures with most helices lying ‘flat’ in the membrane.
2. The scoring seems to reward these bad structures. Even if I randomly get some better looking decoys, the flat and spread out structures consistently score better.I’ve also noticed something odd. One of these loops sometimes fails to close- when that happens, the energy skyrockets, but the decoys do not spread out. In fact, they don’t move much at all. So when the loops close successfully I get too much movement, but when they fail I get no movement.
Any help would be greatly appreciated. I have a lot of speculations on the cause of this problem, but none of the changes I’ve tried has had an appreciable impact. I’ll just paste my options here, it would be a lot easier to give all my inputs if I could upload a zipped directory. I’ve included my threaded structure and some sample outputs.
Oh, and I know the construct count is low. But since bad structures are scoring well anyway, I’ve been experimenting with changing inputs with small numbers of constructs.
-in:file:fullatom
-s hTRPM8_threaded.pdb
-loops:loop_file commons.loops ##loop file
-loops:extended true #force phi-psi angles to be set to 180 degrees independent of loop input file (recommended for production runs)
-loops:idealize_after_loop_close #give idealized phi and psi angles after loop has been closed
-loops:relax fastrelax #does a minimization of the structure in the torsion space
-loops:fast #decreases the monte carlo inner and outer cycles of loop rebuilding, greatly decreasing computation time
-out:file:fullatom #output file will be full-atom
-out:prefix ./output_files/20140924_demo_1_4_S3-S4res_
-use_input_sc
-ex1 #Include extra chi1 rotamers
-ex2
-nstruct 10 #number of models to build. 1000 recommended for production runs
-loops:frag_sizes 9 3 1
-loops:frag_files aat000_09_05.200_v1_3 aat000_03_05.200_v1_3 none #these fragmentfiles are concatenated from chain A repeats (3x) and chain E
-loops:remodel quick_ccd
-loops:refine refine_kic
#-loops:neighbor_dist 0.0
-in:file:psipred_ss2 t000_.psipred_ss2
-in:file:spanfile commons.span
-in:file:lipofile hTRP.lips4#membrane specific terms
#-fixed_membrane true
#-membrane_center -0.0236 72.00924 168.745
#-membrane_normal 0.0 0.0 -1.0
-score:weights /usr/local/apps/rosetta/rosetta-3.5/rosetta_database/scoring/weights/membrane_highres_Menv_smooth.wts-overwrite
-
October 6, 2014 at 10:48 pm #10393
Anonymous
My initial thought is that your spanfile is off – if you have shifted numbering, Rosetta won’t know which residues are supposed to be in the membrane, and so will place and score things inappropriately. Keep in mind that the numbers in the spanfile are *pose numbered* (sequentially starting from 1), rather than PDB numbered (the numbers in the PDB file). If your PDB doesn’t start from 1, these can be off. (Though for homology modeling, I highly recommend you ensure your threaded input structure starts from 1 and all residues are consecutively numbered, even in PDB numbering.)
Another thing I should be clear on is that a fragment file for a complex is not simply the two fragment files for the partners concatenated. There’s missing residue indicies that mean that the numbering in the fragment file will be off. When generating your fragment file, I recommend you just concatenated your sequences into a single “chain”, and then just make sure your loops file doesn’t try to rebuild the connection between the chains. (So the fragments for that region will never actually be used, but will exist to give you the correct numbering.) For repeat proteins you’ll have to generate fragment files for the actual repeated sequence – you can’t economize by concatenating fragment files for the monomers.
-
October 8, 2014 at 7:25 pm #10411
Anonymous
Thanks for the input. I’ve checked the numbering pretty exhaustively, but I’ll take a second look.
The fragments might actually be where I’ve been going wrong, I didn’t realize the fragments were sensitive to multimer numbering like that.
-
-
AuthorPosts
- You must be logged in to reply to this topic.