Wed May 31 09:37:31 PDT 2006 T0308 Make started Wed May 31 09:38:44 PDT 2006 Running on orcas.cse.ucsc.edu Wed May 31 11:52:44 PDT 2006 Kevin Karplus Excellent blast hit (E-value 2.e-35) for 1mr3F. There are 25 PDB files with excellent (< 1.e-10) e-values. HMMs are consistently finding c.37.1.8 with excellent e-values, with over 103 examples in the template library. Wed May 31 14:46:43 PDT 2006 Kevin Karplus The first hit to something that is in SCOP and *not* c.37.1.8 is for 1lv7A which is the same superfamily (c.37.1.20), and it is rank 146 in the list of hits---so we have at least 145 templates to use! Wed May 31 18:48:48 PDT 2006 Kevin Karplus All the models in the undertaker-align set are almost identical, though there is a slight disagreement about one sheet constraint. most alignments have SheetConstraint (T0308)F37 (T0308)F42 (T0308)F52 (T0308)L47 hbond (T0308)S38 43.901 but 2a5dA favors SheetConstraint (T0308)I39 (T0308)S44 (T0308)F52 (T0308)L47 hbond (T0308)E40 43.5294 In try1 the initial alignment favored was from 1o3yA, and in try1-opt2, we ended up with SheetConstraint (T0308)G36 (T0308)S44 (T0308)S55 (T0308)L47 hbond (T0308)S38 1 We do have an rr constraint between T34 and D53, which would favor the unselected (more common) sheet constraint. [T34 is also conserved.] I think our biggest problem with this target will be choosing which phase to use for this strand pair. Thu Jun 1 21:25:09 PDT 2006 Kevin Karplus The alignments all have a big gap between G36 and F37, and many also have a bad gap between S46 and L47, so we need to see how these gaps have been closed. This looks ok in try1-opt2. The only part of try1-opt2 that I don't like much is D120-D138, which seems to be copied directly from 2a5dA. Some of the other templates have a nicer looking helix here, though the sheet looks a bit better in the 2a5dA-based alignment than in the others. Fri Jun 16 10:07:56 PDT 2006 Kevin Karplus With unconstrained.costfcn, our models (particularly SAM_T06_server_TS1) score best. The top-scoring oterh server models are ROBETTA_TS4 ROBETTA_TS3 PROTINFO_TS5-scwrl PROTINFO_TS1-scwrl ROBETTA_TS5 HHpred3_TS1-scwrl ROBETTA_TS3-scwrl PROTINFO_TS5 HHpred2_TS1-scwrl ROBETTA_TS4-scwrl RAPTOR-ACE_TS4-scwrl karypis.srv.2_TS2 BayesHH_TS1-scwrl PROTINFO_TS1 RAPTORESS_TS1-scwrl karypis.srv.2_TS5 HHpred3_TS1 All these servers agree with try1 on the structure of D120-D138, but most have chosen the other alignment for pairing with F52-L47. We should probably submit one model for each alignment, to hedge our bets. The main question is "which first"? Sat Jun 17 12:27:16 PDT 2006 Kevin Karplus I see that Zack started playing with creating a try2.costfcn last night, but did not do a make decoys/score-all.try2.pretty to test it out yet, nor did he put any notes in the README file to say what he was trying to do. I'll leave him to work on it for a while. All the top hits seem to be monomers, so I'm not sure how we are going to create an oligomer for this target, though it is one of the ones that we've been asked to oligomerize. Sat Jun 17 1:31 PDT 2006 Zack Sanborn Sorry, I started to work on this, but got interrupted almost immediately. I'm picking it back up today. I've made the chimera pdb file. I copy-and-pasted the helix from D120-H142 from model 16 into our model 1 (from the best-models.pdb). The new chimera pdb is called T0308.try1-opt2-chimera-D120-H142-mod16.pdb. I've made an unconstrained costfcn (try2.costfcn) and a try2-chimera.under script to optimize the structure and try to heal the gaps caused by the copy-and-paste job. I've doubled the weights for all of the gap-related portions of the cost function to help with this. The new optimized pdb files will be named T0308.try2-chimera-opt1.pdb and T0308.try2-chimera-opt2.pdb and I will score these after they're built. Well, I had a problem with the first run. I got A LOT of these sorts of error: Warning: unaligning (T0308)I18 because of BadResidue code BAD_PEPTIDE in next template residue (1byuA)K28 Warning: unaligning (T0308)N19 because of BadResidue code BAD_PEPTIDE at template residue (1byuA)K28 Warning: unaligning (T0308)P33 because of BadResidue code BAD_PEPTIDE in next template residue (1byuA I'm going to check if I screwed up the chimera PDB file. I don't see anything wrong it, so I'm wondering if this is normal behavior with chimeras. Sat Jun 17 14:14:09 PDT 2006 Kevin Karplus The terms "model 1" and "model 16" are not good ones to use in the README file, since superimpose-best.under (hence best-models.pdb.gz) change frequently. model 1 is T0308.try1-opt2.pdb model 16 is T0308.undertaker-align.pdb model 2, from alignment to 2bcgY Zack, the warnings are normal---many templates have portions that undertaker is not fond of, so refuses to use. The "bad_peptide" test may be set a little too strictly, as it fails more often than I'd like. Unaligning one or two residues does very little harm in the long run, though, as the gaps are pretty easily refilled, and the breaks do allow a bit more flexibility in moving pieces of the model around. Sat Jun 17 2:20 PDT 2006 Zack Sanborn Wow, thanks for the input Kevin! That's a relief, since I couldn't see a problem with the PDB file or the try2-chimera.under script. A good point about "model 1" and "model 16" -- I've taken note. After this unconstrained optimization finishes, I will make the score-all.pretty file and see how this model looks relative to the others. If it looks good, I will make two more models using the different set of sheet constraints. The model T0308.try1-opt2.pdb has the following sheet constraint (looks like it came from the 3rd-best alignment to 2a5dA): SheetConstraint (T0308)G36 (T0308)S44 (T0308)S55 (T0308)L47 hbond (T0308)S38 1 But, noticing that several of the top scoring models (such as T0308.undertaker-align.pdb, from the alignments to 1r2qA, 2bcgY, and more) had this sheet shifted to: SheetConstraint (T0308)F37 (T0308)F42 (T0308)F52 (T0308)L47 hbond (T0308)S38 43.901 So, we'd like to try the above sheet constraints on the models T0308.try1-opt2.pdb and the chimera being constructed right now. This would give us a total of 4 models from which to choose for final polishing runs before CASP submission. There might be a 5th model if the chimera comes up with a different beta sheet configuration. BTW, the chimera optimization run is running on camano.cse.ucsc.edu, started at 2:00pm. Sat Jun 17 2:47 PDT 2006 Zack Sanborn Well, the optimization run died with the following error: undertaker: ConformationPool.h:49: Conformation*& ConformationPool::conform(int): Assertion `0<=sub && sub. I'm looking at the top-scoring alignments, and am finding what Kevin found. The top-10 models are all monomers. I'm completely unfamiliar with the prediction of multimeric proteins, but it seems we need at least one decent template that is multimeric to start with. Wait, I may have to take that back. The top scoring template in the t2k alignments (1o3yA) appears to have second chain (1o3yB) in its crystal structure. Their interface appears to be the same helix we're trying to fix with the chimera. Not sure if this will work for making a dimer, though. I'll have to ask Kevin. Sat Jun 17 15:29:29 PDT 2006 Kevin Karplus I'll try setting up a dimer based on 1o3yA. Incidentally, zack is not using the standard script naming convention: try2.under try2.costfcn to allow the standard method of running the script (make -k T0308.do2 >& do2.log; gzip -9f do2.log) This probably means that he'll be missing a number of the post-processing steps: gzipping the pdb file, running rosetta to repack sidechains and gromacs to try other optimzations, making decoys/score-all.try2.pretty, ... Sat Jun 17 15:36:06 PDT 2006 Kevin Karplus Also, it is a good idea to comment out the "PrintTemplateAtoms" after the first run, unless the set of templates is expanded. I've created a dimer in dimer/decoys/dimer-try1-1o3yA.pdb.gz It is a plausible interaction, but probably needs to be optimized. It isn't clear whether we should build several dimers, and optimize each separately to help choose a monomer, or j=choose the monomers first and then build dimers. The proposed interaction in dimer-try1-1o3yA is small enough that it is essentially just a pair of monomers. Sat Jun 17 16:04 PDT 2006 Zack Sanborn My future runs will follow the standard naming convention. For the current run, I will try to follow what the make file would have done (all in all, might be a good exercise to know what is happening "behind the scenes"). Thanks for making the dimer. I agree that the interaction is small, but I haven't found any other examples. Sat Jun 17 17:15 PDT Zack Sanborn The chimera optimization run finished. I haven't made the score-all.pretty file yet (that's next), but I took a quick look at the structure, and it appears that the helix we were trying to alter has reverted to its old shape (with a kink at Cys132). Not sure why. I'll try to add the different sheet constraints (described above) to see if they have any effect (I don't think they will). I'll use the standard naming conventions this time, too. I've started the new optimization (try3) using the sheet constraints, and I've lowered the *Breaks costs back to their original values to see if that helps get the desired structure. Sat Jun 17 18:52:47 PDT 2006 Kevin Karplus I renamed and gzipped the try2 log files, and gzipped the Template.atoms file. The reason that the optimization "reverted" is that the try1 optimization results were also considered as starting points. You need to remove the "include read-pdb.under" if you don't want to consider all the existing models. Zack's try3 has the same problem. I'll start a try4 that uses the same costfcn as try2, but starts only from the chimera. In doing "make decoys/score-all.try4.pretty" I noticed that there is a duplicated atom in T0308.try1-opt2-chimera-D120-H142-mod16.pdb.gz I removed it to make chimera1.pdb.gz Oops---that isn't enough, since the chimera is missing 123-125, which were missing from the alignment that Zack copied from. Actually, they are missing from ALL the models that have the neater helix---so this chimera is doomed from the start---there *is* an insertion in that region. So, I'll delete decoys/chimera1.pdb.gz and try4.under. We need to leave this helix alone (unless we come up with some other idea for accomodating the insertion). Perhaps Zack should work on optimizing (with constraints) to choose between the strand alignments. I will set up a try4, using Zack's try2-chimera.costfcn, but starting from some of the top server models. (started try4 on orcas) Sat Jun 17 20:50:13 PDT 2006 Kevin Karplus try4-opt2 ended up polishing PROTINFO_TS5-scwrl We have two development paths: alignments -> try1 -> try2-chimera, try3 servers -> try4 Currently try2-chimera-opt2 (poorly named, since the chimera was not used in optimizing it), try3-opt2, and try4-opt2 are our best models. I'm going to redo superimpose-best.under to start with them. All of our models, except the ones that are just side-chain replacement on the alignments, agree that S44 is paired with L47. The ones with the other alignment are not capable of closing the gap. I think I've convinced myself that there is nothing really here to do---the kinked helix is necessary and the strand alignment is correct. We can do one more polishing run, then try to polish the "dimer" (if it is one). I'll set up try5 to do some polishing, using all the existing try* models. Sat Jun 17 21:08:25 PDT 2006 Kevin Karplus try5 started on shaw. Sat Jun 17 21:45 PDT 2006 Zack Sanborn Boy, a LOT can happen when you're at dinner! Well, it looks like I screwed up a bunch of times, but at least some good models came out of it... plus, I've learned a lot. I suppose the only thing left to do is to optimize the "dimer". I'll look into it. Whoops, looks like the dimer directory is not group-writable. Maybe I'll start looking at my next target (T0306) instead. Sun Jun 18 09:05:34 PDT 2006 Kevin Karplus I'll run fixmode . to make the dimer directory group-writable. Sorry about that. I'd better run fixmode on all the targets, to make sure that I haven't left other files or directories unwritable. The try5-opt2 model, which now scores best, is based mainly on try2-chimera-opt2. It has more clashes and breaks than try4-opt2, but gets better Hbonds and sidechains. Rosetta still prefers to repack the backbone of try4-opt2. I will submit try5-opt2 our best? try3-opt2 optimized from servers try4-opt2 lowest clashes, rosetta's favorite try1-opt2 fully automatic align1 alignment from 1r2qA Our models are within about 1.2 Ang all-atom RMSD, which is probably as good as our tools are good for. If dimerizing comes up with a different monomer preference, we can replace one or more of the submissions. Zack, we should dimerize 3 or 4 of the different monomer models, since what scores best as a monomor may not be best as a dimer. Sun Jun 18 09:54:18 PDT 2006 Kevin Karplus I've submitted the monomers for T0308, now we just have the dimers to work on. Sun Jun 18 11:51 PDT 2006 Zack Sanborn I've begun making the dimers. I plan on having dimers for the top 3 models given above, and a model near the bottom of the score-all.rdb for a little bit of diversity. So, the dimers we have will be constructed from the following monomers: try5-opt2 dimer-from-try5-opt2-1o3yA.pdb try4-opt2 dimer-from-try4-opt2-1o3yA.pdb try3-opt2 dimer-from-try3-opt2-1o3yA.pdb try1-opt2 dimer-try1-1o3ya.pdb (created previously by Kevin) try1-opt1 dimer-from-try1-opt1-1o3yA.pdb These models will then be optimized. I made the scripts try1.under and try1.costfcn according to the CASP7 README. (At least I hope I did everything I needed to!). I've begun the optimization run on camano at 12:23pm, and it appears it's working well. I used all of the models given above (using the ReadConformPDB command, with Multimer 2) and will let undertaker figure out which is best, hopefully that was the right thing to do. Also, I reduced the super_num_gen of the OptConform by half to hopefully speed up computation time. Sun Jun 18 12:57:32 PDT 2006 Kevin Karplus The dimer/try1 run is *not* doing what you want: # command:Warning: Couldn't open file decoys/dimer-try1-1o3A.pdb.gz or decoys/dimer-try1-1o3A.pdb.gz.gz for input Trying dimer-try1-1o3A.pdb.gz Error: Couldn't open file dimer-try1-1o3A.pdb.gz or dimer-try1-1o3A.pdb.gz.gz for input Error: can't open file dimer-try1-1o3A.pdb.gz in ReadConformPDB ... The problem is spelling errors (1o3yA, not 1o3A). It is important to look at the try*.log file to detect these problems. When you are doing all models, you can "make decoys/read-pdb.under" and use "include decoys/read-pdb.under" in your file. I'll set up try2.under, identical to try1.under, but using read-pdb. No--not quite identical. Zack had TweakMultimer turned off, I turned it up high, and adjusted the pseudocounts for some of the other operators as well, to encourge crossover and reduce the number of times InsertSpecificFragment was tried. I was tempted to add "alpha 1 prev_alpha 1" to the try2 costfcn, but did not. dimer/try2 started on lopez. Sun Jun 18 13:08:00 PDT 2006 Kevin Karplus We get to submit 5 dimer models, so it might also be a good idea to start a run from *each* of the initial dimers. We can then do another "polishing" run to select among the different models. We can probablly speed things up by not using so many alignments, since we aren't like to use any really long fragments. Commenting out "ReadFragmentAlignment NOFILTER SCWRL all-align.a2m" would save about half an hour of startup (mostly in SCWRL). Sun Jun 18 15:00 PDT 2006 Zack Sanborn Darn typos. I killed the try1 job. I did however, MOSTLY get it right this time. I turned off TweakMultimer simply because it was suggested by the CASP7 README in the homodimer section. Oh, I see why. For "tight" interfaces, you should turn off TweakMultimer. But, in our case, the interface is fairly small, so TweakMultimer would unlikely cause the monomers to separate. Noted. I'll begin the optimization runs for each dimer (instead of all dimers that's being run right now). Began try3, copying Kevin's try2.under and try2.costfcn, removing the "include read-pdb.under" and reading in just the try5-opt2 structure. try3 is optimizing the structure dimer-from-try5-opt2-1o3yA.pdb.gz. It will create T0308.dimer-t5o2-try1-opt2.pdb, where "t5o2" abbreviates try5-opt2 so we keep a handle on where these dimer models originated. Began try3 on camano at 15:35. I've started doing the single runs for each of the initial dimers. I'm getting the error: Error: Reading chain from PDB file dimer-from-try5-opt2-1o3yA.pdb.gz failed. when I do the ReadConformPDB with Multimer 2. I noticed that "read-pdb.under" does not set Multimer 2 when it does its reads, so I removed it from try3.under, restarted the run and am now getting the warning: WARNING: atom 1321 has residue number 1 < previous residue 165 in dimer-from-try1-opt1-1o3yA.pdb.gz This is also found in Kevin's try2.log. So, which way is the right way? I'm going to let my try3 run (with the warning) continue, but won't start any more runs until I hear back from Kevin. Sun Jun 18 16:15:14 PDT 2006 Kevin Karplus I think it is a bad idea for the try3 job to create anything other than try3-opt1 and try3-opt2. It is hard enough keeping track of things without random naming conventions added to the mix. At least if the output of the job matches the input file that creates it, we can go and look to see what was done. Setting "multimer 2" after a ReadConformPDB marks the conformation as a cyclic multimer. Using "multimer 2" in Optconform forces all conformations generated to be treated as cyclic multimers. Sun Jun 18 16:57 PDT 2006 Zack Sanborn Alright, I'm using the better naming convention for the next jobs try4 and try5. As for the setting of "multimer 2" in ReadConformPDB and OptConform. Currently, ReadConformPDB does not have that setting (see the Error it gave above). However, OptConform is set with "multimer 2". If this isn't the right thing to do, then I'd suggest fixing the CASP7 README section "Handling a homodimer," as it is currently misleading. We will also have to kill all current dimer jobs. Jobs try4 (optimizing dimer-from-try4-opt2-1o3yA.pdb) and try5 (optimizing dimer-from-try3-opt2-1o3yA.pdb) were started, both on shaw at 17:03. Jobs try6 (optimizing dimer-from-try1-opt1-1o3yA.pdb) was started on peep at 17:15 and try7 (optimizing dimer-try1-1o3yA.pdb) was started on orcas at 17:16. All optimizations for single dimeric models have been started. So far, no errors. Sun Jun 18 18:16 PDT 2006 Zack Sanborn The optimization run considering all dimeric models (try2) has finished. The top scoring model (T0308.dimer-try2-opt2.pdb) had a score 139.49. This puts it into the middle of the pack of monomeric models. I'm not sure if, with a dimeric model, if the scores are comparable. Sun Jun 18 20:22:37 PDT 2006 Kevin Karplus Dimeric models and monomeric models are not on the same scale. We've never come up with a cost function that remains invariant under changes of length. Currently, the best scoring decoy is dimer/decoys/0308.dimer-try4-opt2, which I'm *guessing* omes form the dimer/try4.under script. There are many closely scoring dimers, so we wil have to superimpose them and chose the best 5 to submit. We may want to do a poishing run starting from all dimers first. Sun Jun 18 21:26 PDT Zack Sanborn All runs have completed, so started polishing run (try8) starting from ALL dimers at 21:29 on camano. Current best scoring decoy is T0308.dimer-t5o2-try1-opt2.pdb, but only by a bit. BTW, this model came from the try3.under script, one of only two models using the "random" naming convention (the other being T0308.dimer-t5o2-try1-opt1.pdb). Mon Jun 19 08:47:38 PDT 2006 Kevin Karplus Now dimer-try8-opt2 is the best scoring, though there are several that are very close. dimer-try8-opt2 is based on T0308.dimer-t5o2-try1-opt2.pdb, and is almost identical to it---in part because it was "polished" with the same costfcn. Usually for polishing we turn up breaks and clashes. I'll do another polishing run, but with a new costfcn. In addition to turning up breaks and soft_clashes a lot, I'll increase sidechain slightly and add in alpha and alpha_prev. For the optimization run, I'll reduce the size of each generation and reduce the number of generations a little, to speed things up. I'll also turn up CrossOver, to encourage swapping of good bits between models. With the dimer/try9 costfcn, dimer-try4-opt2 beats out dimer-try8-opt2 by a little bit. dimer/try9 started on lopez. I made dimer/superimpose-best.under, edited to have different dimer models that scored well with try9, and looked at them. They seem to be distinctly different dimer packings! This one looks like a hard one to pack into a dimer, as there is no obvious hydrophobic patch to line up. I suspect it it biologically a monomer, even if it packs into something in the crystal. Although dimer-try4-opt2 scores best, I rather like the packing of dimer-try7-opt2. Perhaps we should do a polishing run on just that one??? We might even be able to make some Hbonds between the monomers---perhaps lining up F37 (and its counterpart F202) and Hbonding them? The rings might be difficult to arrange to pack with each other, though, but SheetConstraint F37 I39 I204 F202 Hbond F37 might work. I'm a little worried that I35 would get a bit exposed. Maybe it would be best just to optimize dimer-try7-opt2 without trying to make Hbonds between the monomers. I'll set this up as try10. I'll also go back to the standard nomenclature (try10, not dimer-try10) so that the automatic repacking of sidechains by rosetta and gromacs optimization will be done. We rarely use the gromacs optimization, but it is *very* useful to have rosetta's opinion about how easy it is to put sidechains on the backbone. Mon Jun 19 09:37:56 PDT 2006 Kevin Karplus I made all the rosetta repackings for the existing models which started with 'dimer', and I'll make the ones for "*opt2.pdb.gz" file also. Mon Jun 19 10:19:50 PDT 2006 Kevin Karplus Rosetta likes best repacking dimer/ dimer-from-try4-opt2-1o3yA Of course, this just may mean that it is the loosest conformation, so allows the most sidechain movement. Mon Jun 19 10:36:29 PDT 2006 Kevin Karplus dimer/ try9-opt2 is based on try4-opt2, as expected. Mon Jun 19 11:07:34 PDT 2006 Kevin Karplus STOP: T0308 was reported in T0308.doc.html as being a TRIMER in the unit cell. ONLY TRIMER submissions will be accepted. We have to REDO everything based on a trimer. Mon Jun 19 15:48 PDT 2006 Zack Sanborn I've built the 3mer initial PDB using our best guesses based off a look at the dimer/best-models.pdb superposition. The dimeric models try9-opt2 and try10-opt2 were used. The superposition was on one of the monomers from each of the dimers, which we'll call chain A. So, to build the trimer, chains A & B were taken from try9-opt2 and chain C of the trimer came from chain B of try10-opt2. The results are stored in decoys/3mer-try1-model.pdb.gz. An optimization run (unconstrained) for a symmetric trimer was started on camano at 16:05. An optimization run (unconstrained) for a non-symmetric trimer (by turning off multimer 3) on lopez at 16:24. Had some problems running it at first due to a silly global-search-and-replace that changed the initial model PDB filename. Might be smart not to put "try1" in these filenames, and also to look over the file once before running it and bugging Kevin with the inevitable error. Tue Jun 20 11:45 PDT 2006 Kevin Karplus The two trimer runs (symmetric and non-symmetric trimers) for T0308 finished some time late last night. The top five best scoring models are: T0308.try2-opt2.pdb.gz (non-symm) T0308.try1-opt2.pdb.gz (symm) T0308.try2-opt1.pdb.gz T0308.try1-opt1.pdb.gz 3mer-try1-model.pdb.gz The non-symmetric trimers came from run try2 and the symmetric trimers came from try1. The model "3mer-try1-model.pdb" is the initial model that all the runs were trying to optimize. These runs took probably 12 hours to complete. I've emailed Kevin so that he may submit these trimeric models, as they are due tomorrow. Tue Jun 20 12:04:13 PDT 2006 Kevin Karplus We really have only two trimeric models: 3mer/decoys/T0308.try2-opt2.pdb.gz # possible hexamer, tight interface 3mer/decoys/T0308.try1-opt2.pdb.gzp # symmetric trimer, small interface I don't know if we have time to optimize the hexamer as a hexamer. I'll try submitting the two trimers as is. Tue Jun 20 12:25:42 PDT 2006 Kevin Karplus I had some difficulty submitting the trimers for T0308, because Zack left the decoys directory not group-writable. I move it to old-decoys and copied the files to a new decoys directory. It might be a good idea for him to do mv -f old-decoys/* decoys/ to get the files in the decoys to have his name on them, rather than mine. I have submitted the two trimers. From: Zack Sanborn Subject: Re: today's targets Date: Tue, 20 Jun 2006 13:37:54 -0700 Sorry about that Kevin. I remembered to use fixmode on *almost* all of the directories. I'll be more vigilant in the future, especially since it can affect the ease of submissions. I've moved the files over. Is there anything more to be done on T0308? I'll try to look at the unassigned targets you sent out this morning to choose one. Thanks, Zack Date: Tue, 20 Jun 2006 14:55:46 -0700 From: Kevin Karplus To: jsanborn Subject: Re: today's targets There is one more thing we could do on T0308 Our non-symmetric trimer could be made into a hexamer then reoptimized twice (once a "dimer", once as a "trimer"). ------------------------------------------------------------ Tue Jun 20 19:51:11 PDT 2006 Kevin Karplus I made 3mer/decoys/T0308.try2-opt2.reversed.pdb.gz by copying try2-opt2.unpack and reordering the chains to be CBA instead of ABC. Then I superimposed (using 3mer/superimpose-best.under) on the first chain. Tue Jun 20 20:02:04 PDT 2006 Kevin Karplus The internal dimers are A<>B and A<>C, so this just swaps A and C, giving us only one new monomer position. What I really need to do is to superimpose B and C in the two models. Since B is in the same place in both 3mers, that means I need a different order. Say CAB and BAC. Tue Jun 20 20:17:36 PDT 2006 Kevin Karplus I superimposed 3mer/ try2-opt2.BAC and try2-opt2.CAB on the first chain with 3mer/make-5mer.under, then removed the duplicated chain to get 3mer/ 5mer.pdb.gz Now I just need to do one more superposition to fill in the hexamer. Tue Jun 20 20:45:02 PDT 2006 Kevin Karplus I made a rearranged 5mer.BACDE.pdb.gz, and superimposed it on 5mer.unpack.pdb.gz I then selected out a clean 6mer without duplication from the 10mer full of duplicates. (chains AB DE IJ of 10mer, making 3mer/6mer.unpack.pdb.gz) Unfortunately the "hexamer" we get is not S_{3,2}. Instead we seem to have a dimer that packs fairly tightly against itself in an alternating stack---AB crossing CD crossing EF. But if this is right, then the unit cell should have 2, 4, or 8 in it, not 3. So, I'm pretty sure that both our "trimers" are wrong, but I don't think that there is time to come up with a new trimer. Oh well. I could try optimizing the hexamer as a cyclic trimer, with TweakMultimer turned up, to see what it comes up with, but I don't expect anything reasonable. This would keep one of the "dimer" interfaces (the current AB iinterface in 6mer.unpack) and discard the other one (the AC interface). I'm not sure it is worth the trouble to set up, since we don't have time to optimize it by tomorrow. I'm giving up on this target---too many others to work on and not enough time (or sleep). Wed Jun 28 10:30:48 PDT 2006 Kevin Karplus T0308 was chosen as one of the 'refinement' targets. I did make fetch_refinement to get the decoys/tr308.pdb.gz file. I'll recompute all the score files, to see how well my cost-function likes it. Well---try1 doesn't like it much. Too few hbonds, poor packing, and terrible sidechains. Clashes are very low. Same story with try3, try4, try5, and unconstrained. I think that refining this model will consist first of SCWRLing it, then doing the usual polishing run. We actually have a choice of using try5.costfcn for the polishing, or adding in a few sheet constraints from our best models, in an attempt to get better beta sheets. try6 to start refinement started on orcas. Wed Jun 28 10:48:57 PDT 2006 Kevin Karplus For some reason, the score obtained in score-all.try5.pretty for tr308 is different than that for the try6 run, though the cost functions are identical. This worries me, as it could mean a bug such as an uninitialized variable. It could be differences in the way the gaps are handled, since the score-all script does read in a different set of pdb files for the generic fragment library. In any event, SCWRLing tr308 did not improve its score by much. Wed Jun 28 13:43:38 PDT 2006 Kevin Karplus With a little wiggling, but no major changes, try6-opt2 improved on tr308-scwrl. Clashes went up quite a bit from the tr308 to tr308-scwrl, and did not come all the way back down. The Rosetta repacking reduces clashes again, with some loss on the packing thers and the sidechain probability. For try7, I'll up the clash and break penalties, and lower the sidechain and dry weights a little. Tue Jul 4 14:46:58 PDT 2006 Kevin Karplus One thing that may help is to do gromacs followed by rosetta repacking to reduce clashes to a minimum, then polish the result with undertaker. Because try7 run didn't run earlier because of a typo, I'll run it now (on the farm cluster) including try6-opt2.gromacs0.repack-nonPC as a possibility. I think that try7 will mainly work with try6-opt2.gromacs0 though. Sun Jul 9 17:00:51 PDT 2006 Kevin Karplus I'll finish the do7 run (gromacs still not running on the farm cluster). Rosetta now likes best decoys/T0308.try4-opt2.gromacs0.repack-nonPC.pdb.gz (followed by the try6 and try7 versions) try7-opt2 is the best of the refinement models, though it doesn't score as well as try4-opt2, having much larger breaks. It does almost as well as try5-opt2 (our top model) on the try5 costfcn. Started another optimization (try8 on lopez) starting from just the try6 and try7 gromacs0.repack-nonPC models, which have a long way to go to be improved, but which have very small clashes. After try8 finishes, I might want to do a polishing run for try6-try8 with the dry weights turned up to get tighter packing. Sun Jul 9 21:00:28 PDT 2006 Kevin Karplus Well, try8-opt2 is a bust---it does not do as well as try7 according to either undertaker or gromacs0+rosetta. I'll start try9 on cheep, optimizing from all the try6 through try8 models. I expect to get only minor tweaks to try7-opt2. Mon Jul 10 09:31:04 PDT 2006 Kevin Karplus try9-opt2 scores the best with the try9 costfcn, finally beating out try5-opt2, but rosetta still likes decoys/T0308.try4-opt2.gromacs0.repack-nonPC.pdb.gz best, and thinks that try6,try7,try8,try9 have been getting gradually worse. There are a couple of bad breaks that try9-opt2 has not closed: T0308.try9-opt2.pdb.gz breaks before (T0308)N25 with cost 1.12277 T0308.try9-opt2.pdb.gz breaks before (T0308)D147 with cost 0.903484 One has been there since try6-opt2 T0308.try6-opt2.pdb.gz breaks before (T0308)N25 with cost 1.23478 T0308.try6-opt2.pdb.gz breaks before (T0308)P100 with cost 0.932035 T0308.try6-opt2.pdb.gz breaks before (T0308)D147 with cost 0.896138 T0308.try6-opt2.pdb.gz breaks before (T0308)S24 with cost 0.628209 T0308.try6-opt2.pdb.gz breaks before (T0308)N30 with cost 0.619701 but the original was even worse: tr308.pdb.gz breaks before (T0308)I31 with cost 2.50407 tr308.pdb.gz breaks before (T0308)N30 with cost 2.12729 tr308.pdb.gz breaks before (T0308)N25 with cost 1.54569 tr308.pdb.gz breaks before (T0308)S24 with cost 0.775567 tr308.pdb.gz breaks before (T0308)D147 with cost 0.717045 S24-T34 is the region where the loop had to be made up, and it seems that their loop closer did a crummy job. The other region where the refinement models differ from try4 is at I102-R106, which continues the short (unpredicted) helix in try4, but not in the models from refinement. I'm not sure what to do here---undertaker and rosetta are pointing in opposite directions. Is it allowed to cut and paste from try4? Is it even desirable? Wed Jul 12 14:14:35 PDT 2006 Kevin Karplus It *is* permitted to redo loops. So do we want to? Let's try making a try9-opt2 try4-opt2.gromacs0.repack-nonPC chimera, taking from the older try4 model S146-G151 P100-P108 K20-N25 Thu Jul 13 12:55:22 PDT 2006 Kevin Karplus Made chimera-9-4 as described above. Thu Jul 13 13:02:38 PDT 2006 Kevin Karplus started try10 on cheep to optimize chimera-9-4, which had bad breaks and clashes (as one would expect from a chimera). Thu Jul 13 16:08:31 PDT 2006 Kevin Karplus try10-opt2 does not score as well (with the try10 costfcn) as try9-opt2 or try7-opt2, but beats try8-opt2 and try6-opt2. Rosetta still prefers decoys/T0308.try6-opt2.gromacs0.repack-nonPC, and try10 doesn't even come up to try9's level. Sat Jul 15 11:14:12 PDT 2006 Kevin Karplus Starting another polishing run (with slightly different weights) beginning with only ReadConformPDB T0308.try10-opt2.gromacs0.repack-nonPC.pdb try11 started on farm cluster. Sat Jul 15 13:26:39 PDT 2006 Kevin Karplus Oops, the try11 run accidentally is optimizing for the "try1.costfcn" Let's try again on try12. Sat Jul 15 13:28:15 PDT 2006 Kevin Karplus try12 started on farm cluster. Sat Jul 15 21:40:27 PDT 2006 Kevin Karplus Because the missing libraries on the farm cluster have still not been installed, I'm redoing the do11 and do12 on cheep to make the gromacs0 and gromacs0.repack-nonPC models. Sat Jul 15 21:45:31 PDT 2006 Kevin Karplus Rosetta likes try12 better than try10, but still prefers try4 (ours) and try6 (refinement model) to them (for that matter, try6, try7, try8, and try9 all beat try12, so far as rosetta is concerne). undertaker doesn't care all that much for try12 either, putting try9, try4, try5, try7, and try10 all ahead of it. Since we don't really have a good optimizer for this fine level of detail, I think I'll just submit: try9-opt2 best with try12 costfcn try6-opt2.gromacs0.repack-nonPC rosetta's favorite try10-opt2 best chimera, replacing loops S146-G151 P100-P108 K20-N25 try12-opt2.gromacs0.repack-nonPC (rosetta's favorite from chimera-9-4) try7-opt2 Sat Jul 15 22:06:47 PDT 2006 Kevin Karplus "refinements" submitted. I hope they are not *too* terrible. Sun Sep 10 08:09:44 PDT 2006 Kevin Karplus Our best submitted model was try4-opt2 (model3), which was beaten by only one server model (FOLDpro_TS1). Our best model before we got tr308 to refine was try4-opt2.gromacs0.repack-nonPC, which still did not beat FOLDpro_TS1. Our best post-refinement model was try9-opt2.gromacs0, followed closely by try9-opt2 (our top choice for refinement). Our refinement model2, try6-opt2.gromacs0.repack-nonPC is somewhat worse, but still better than tr308. but try10-opt2 and try12-opt2.gromacs0.repack-nonPC are worse than tr308 (so our chimera with try4 was not a good move). The 5th refinement model, try7-opt2, is better than the second model, hence better than tr308, but not as good as the first. Note: tr308 has a higher GDT than try9-opt2, and lower rmsd_ca, but higher all-atom rmsd, and worse real_hbond and clens scores. Note that scwrling tr308 actually made it worse (discarding some real H-bonds and other contacts) though it did reduce the all-atom rmsd. Wed Mar 21 20:47:37 PDT 2007 Kevin Karplus With the improved GDT implementation and the current real_cost function, our try7-opt2.gromacs0.repack-nonPC scores best (it is a refinement model). Lots of models score better than tr308, but they are all refinement models from after we had tr308 to refine. Our refine.model1 is the best refinement model we submitted, and it *is* better than tr308. We had one almost as good as tr308 (try4-opt2.gromacs0.repack-nonPC), but the best we submitted was model3=try4-opt2, which was optimized from server models.