Tue Jun 22 09:43:20 PDT 2004 T0211 DUE 26 July Tue Jun 22 12:51:38 PDT 2004 Kevin Karplus looks like a fold-recognition hit for b.18.1.* Tue Jun 22 18:25:59 PDT 2004 Kevin Karplus Essentially all the alignments in the t2k.undertaker-align set are in agreement, but there is enough diversity to offer some hope of improvement. The try1 model looks fairly good. I'll want to increase the constraints for helices and strands, and try to pack things a bit tighter, but I think this one will be pretty easy. Tue Jun 22 20:35:13 PDT 2004 Kevin Karplus The try2 model looks good to me--perhaps a bit better than try1, though it doesn't score quite as well with the try2 cost function. I just need to pack it a bit tighter and it will be done, I think. I'll do one more run from the alignments, after tweaking the cost function to like try2 better than try1 (mainly increasing break cost, but also removing strand constraints that aren't consistent). After that run, I'll repack the models with Rosetta, do another run starting from all the models, and submit it. Tue Jun 22 23:11:39 PDT 2004 Kevin Karplus try3 looks similar to try1 and try2. I'll try repacking all three. In try1, Rosetta really does not like S66, S131, P27, P26, L100, E97, Q87, F68, Y114, Y67, I16, ... after repacking. (All problems with clashes.) other-bump: 1.71728 Ang (T0211)S66.CB and (T0211)S131.CA threshold= 3.17553 cost= 0.974988 neighbor-bump: 1.55998 Ang (T0211)P26.CB and (T0211)P27.N threshold= 2.77997 cost= 0.968777 neighbor-bump: 2.18718 Ang (T0211)P26.CB and (T0211)P27.CD threshold= 3.05 cost= 0.86401 ... In try2, Rosetta does not like I4, S10, P26, P27, S66, S131, P82, S79, Y114. In try3, Rosetta does not have many objections after repacking. Undertaker has quite different views of the three models, preferring try2, then try1, then try2 repacked, then try1 repacked, then try3, then try3-repacked. I'll have to raise the weight of the soft_clashes and reoptimize from existing models. Upping the weight of soft_clashes makes the repacked models look much better. Wed Jun 23 06:31:06 PDT 2004 Kevin Karplus Unfortunately, try4 seems to have increased the clash weight too much relative to the parameters that hold things in position. The residues have been pried apart, but some of the backbone hbonds have gone missing. I can't do a repack this morning, because /projects/compbio/usr/karplus (where Rosetta is) seems to be inaccessible. I'll need to increase the weight of the hbond_geom_pair term, I think, or even add some SheetConstraint commands to hold the first strand on. I tweaked the cost function in try5.costfcn, until try2-opt2 just barely beat try4-opt2 and am running try5. I hope that this will produce a decoy that scores well even once the constraint on the first strand is removed, since that is the main "improvement" that try2 has over try4. I fear that the run will just pry off some other strand in order to reduce clashes. Mon Jul 5 19:24:42 PDT 2004 Kevin Karplus I haven't looked at this for a while! try5 scores well, and I don't see any obvious problems. There is a slight foaminess, so we should reoptimize with the dry weights turned up. Maybe the helix from D84-L93 needs to be rotated a bit, to turn the dry side inward. Maybe a constraint between W88.CH2 and I74.CA would help orient it better. Perhaps L93.CD1 and L62.CD1 also. Turning the helix in an already optimized model would be hard, so I'll start again from alignments. Tue Jul 6 08:09:09 PDT 2004 Kevin Karplus In try6, the helix has turned back into a strand. It is possible that this is a correct structure, though less likely than the try5 model. It should be included in our models, though not high on the list. We could try to get the helix back, but oriented better, by increasing the weight of the helix constraints and of constraints in general. Fri Jul 9 23:11:57 PDT 2004 George Shackelford Looked at try6, opt2. Will try to add constraints that will enforce the helix. Built the T0211.134.rr and T0211.134.rr.constraints files. The constraints file is empty due to the limit of .35. I will check the weaker predictions tomorrow. I hope to work with either Martina, Sol, or Jenny on learning the use of scripts in Rasmol. Fri Jul 16 11:45:03 PDT 2004 Kevin Karplus No comments in this README file for quite a while! I looked at try10-opt2, which has the helix nicely formed, but still oriented the wrong way, with the wet side buried. There are still some bad clashes: other-bump: 1.10365 Ang (T0211)I89.O and (T0211)L93.CD1 threshold= 2.74046 cost= 0.995734 neighbor-bump: 2.20754 Ang (T0211)P26.CB and (T0211)P27.CD threshold= 3.05 cost= 0.856237 other-bump: 2.29093 Ang (T0211)I89.C and (T0211)L93.CD1 threshold= 3.0897 cost= 0.833821 other-bump: 2.48484 Ang (T0211)L62.CD1 and (T0211)F117.CZ threshold= 3.10031 cost= 0.734931 other-bump: 2.22511 Ang (T0211)Y67.C and (T0211)V69.N threshold= 2.74083 cost= 0.713703 neighbor-bump: 2.27222 Ang (T0211)P26.CB and (T0211)P27.N threshold= 2.77997 cost= 0.701832 other-bump: 2.61017 Ang (T0211)I16.CG2 and (T0211)F49.CE1 threshold= 3.12096 cost= 0.657799 neighbor-bump: 2.48012 Ang (T0211)T113.C and (T0211)Y114.CD1 threshold= 2.93845 cost= 0.638487 other-bump: 2.70628 Ang (T0211)S66.CB and (T0211)S131.CA threshold= 3.17553 cost= 0.616875 self-bump: 1.88965 Ang (T0211)E97.N and (T0211)E97.C threshold= 2.19456 cost= 0.592431 and lots of breaks: T0211.try10-opt2.pdb has 12 breaks T0211.try10-opt2.pdb breaks before (T0211)V69 with cost 0.966313 T0211.try10-opt2.pdb breaks before (T0211)F68 with cost 0.844403 T0211.try10-opt2.pdb breaks before (T0211)D124 with cost 0.577272 T0211.try10-opt2.pdb breaks before (T0211)P26 with cost 0.554253 T0211.try10-opt2.pdb breaks before (T0211)V94 with cost 0.531047 T0211.try10-opt2.pdb breaks before (T0211)G98 with cost 0.527839 T0211.try10-opt2.pdb breaks before (T0211)E103 with cost 0.435087 T0211.try10-opt2.pdb breaks before (T0211)T113 with cost 0.342076 T0211.try10-opt2.pdb breaks before (T0211)H108 with cost 0.29606 T0211.try10-opt2.pdb breaks before (T0211)W39 with cost 0.195149 T0211.try10-opt2.pdb breaks before (T0211)I105 with cost 0.139506 T0211.try10-opt2.pdb breaks before (T0211)P46 with cost 0.122243 There are no breaks near F85 and L93, where we would need them to rotate the helix. I think we may need to do manual rotation of the helix by a half turn, then reoptimize to close the gaps. I'm not sure whether ProteinShop or SwissModel is the better tool for doing this manual manipulation, never having used either for the job. We can also try adding more constraints of the atoms of the helix, trying to force it around, turning down the break penalty, so that it can move. I'll try some stiffer constraints, including some to repel the buried charged residues, and reduce the break cost for try11. From karplus@soe.ucsc.edu Fri Jul 16 12:25:44 2004 Date: Fri, 16 Jul 2004 12:25:42 -0700 From: Kevin Karplus To: ggshack@soe.ucsc.edu CC: karplus@soe.ucsc.edu, sol@soe.ucsc.edu, ggshack@soe.ucsc.edu, learithe@soe.ucsc.edu, martina@soe.ucsc.edu, bbarnes@ucsc.edu, marcias@ucsc.edu, rph@soe.ucsc.edu In-reply-to: <200407161147.28781.ggshack@cse.ucsc.edu> (message from George Shackelford on Fri, 16 Jul 2004 11:47:28 -0700) Subject: Re: T0232 and T0233 I did a make try10.repack on T0211, but it did not look done to me---the helix is still oriented the wrong way. George, you have to leave more comments in the README file---there was nothing added for a week, and no comments on try7, try8, try9, try10. I can't read your mind to know the status of the prediction and what tries were attempting to do and whether or not they succeeded. Jenny, you offered to try turning the helix on this protein manually. You could try that breaking near F85 and L93 and giving the helix about a half turn? Kevin Karplus ------------------------------------------------------------ Fri Jul 16 13:15:19 PDT 2004 Kevin Karplus It looks like try11-opt1 is succeeding in turning the helix (starting from alignments). I'll have to do crossovers between try11 and the other models when it's done, though, since it is not producing as polished a core as the previous models. From learithe@soe.ucsc.edu Fri Jul 16 14:03:49 2004 MIME-Version: 1.0 Date: Fri, 16 Jul 2004 14:03:45 -0700 (PDT) From: Jenny Draper To: Kevin Karplus cc: ggshack@soe.ucsc.edu, sol@soe.ucsc.edu, learithe@soe.ucsc.edu, martina@soe.ucsc.edu, bbarnes@ucsc.edu, marcias@ucsc.edu, rph@soe.ucsc.edu Subject: Re: T0211 helix packing In-Reply-To: <200407161925.i6GJPgVQ004667@cheep.cse.ucsc.edu> It was looking like George was getting the helix turned, so I didn't try to move the helix... I've done it now, as: decoys/T0211.try4-opt2-hand.pdb -Jenny On Fri, 16 Jul 2004, Kevin Karplus wrote: > I did a > make try10.repack > on T0211, but it did not look done to me---the helix is still oriented > the wrong way. > > George, you have to leave more comments in the README file---there was > nothing added for a week, and no comments on try7, try8, try9, try10. > I can't read your mind to know the status of the prediction and what > tries were attempting to do and whether or not they succeeded. > > > Jenny, you offered to try turning the helix on this protein manually. > You could try that breaking near F85 and L93 and giving the helix > about a half turn? > > Kevin Karplus > Fri Jul 16 14:47:44 PDT 2004 ggshack I am going to do a try12 using try10 as the base and re-specify the range of the misbehaving helix. The should allow for an easier turn Fri Jul 16 17:05:40 PDT 2004 Kevin Karplus try11 seems to have the helix about right, but the breaks are not great. I'll make a try13 cost function that turns up the break and clash costs and turns down the constraints, but still has try11 scoring better than try10. The hope is to get crossover to fix the bad parts of try11, without losing the position of the helix. I also changed the burial constraints somewhat, to try to pack the tryptophan in better. Sat Jul 17 05:20:28 PDT 2004 Kevin Karplus try14 is beginning to look pretty good, and scores well without constraints. There should be a bit more polishing to reduce clashes and close gaps. Also, we should look for the possibility of dimeric structure. I created a make-dimer-try14.under script that superimposes try14 on the 1gqp pdb structure, but that turned out to be useless, because the dimerization interface in 1gqp consists of a helix that isn't in T0211. None of the other matches dimerize. My biggest concern is buried charge for K76. Undertaker likes burying it to make the hydrogen bond with N102.O, but perhaps I should pry it out by adding a constraint to E104.OE2?? There is also a buried charge at E14, and a buried polar at N102. Perhaps I should try for a salt-bridge between K76.NZ and E14.OE2? Even swinging the K76 so that it points directly toward E14 would leave us about 2Ang too far away for a salt bridge. Maybe one mediated by K76.NZ-N102.OD1 + N102.ND2-E14.OE2? Nope, that is an even harder distance to bridge. Let's try the salt bridge between K76.NZ and E14.OE2 for try15, without other constraints, but starting from existing models. In the best of the existing models (try13-opt2.repack-nonPC), these atoms are 7.9 Ang apart, though there may be a water-sized hole between them. Sat Jul 17 10:06:08 PDT 2004 Kevin Karplus try15-opt2 forms the requested salt bridge, and scores the best with the unconstrained cost function, but looks just a little foamy. Perhaps one more polishing run, with the dry weights turned up and the wet weight down a little? Also increasing breaks and soft_clashes, since these are not quite as good as I'd wish. I adjusted the weights from unconstrained.costfcn for try16.costfcn, making sure that I didn't move the so much that another model came out better than try15. My first attempt at doing this was unsuccessful, bringing try8 to the top. The problem was mainly with phobic_fit, which doesn't like the buried charges, no knowing about the salt bridge. I turned the weight of phobic_fit down until try15 was best again. Rosetta still likes try6-opt2.repack-nonPC best, which has a strand rather than a helix for E86-H95. It would be a good representative of the other possible fold prediction. Sat Jul 17 15:43:10 PDT 2004 Kevin Karplus try16-opt2 has removed the salt bridge, leaving E14 buried without K76. We may want to submit this model in addition to the salt-bridge model. We need about 4.6 points for try15 to beat try16, which we can probably get by using the constraint of try15 with a constraint weight of 1 added to the try16 cost function. Let's try reoptimizing with that as try17. Sat Jul 17 18:41:10 PDT 2004 Kevin Karplus try17 forms the saltbridge again, but try17-opt1 scores better than try17-opt2. Without the saltbridge constraint (try16.costfn), try16-opt2 scores slightly better. I think we've reached the point of diminishing returns on this target. I'll submit try17-opt1, try6-opt2.repack-nonPC (the one Rosetta likes best), try1-opt2 (the automatic one), and two alignments to templates.