Mon Jun 16 09:02:42 PDT 2008 T0454 Make started Mon Jun 16 09:03:13 PDT 2008 Running on cheep.cse.ucsc.edu Mon Jun 16 12:02:08 PDT 2008 Kevin Karplus 1vi0A and 1pb6A are strong hits with the w0.5 HMMs. I'm not sure yet whether this is a one-domain or two-domain hit (a.4.1.9,a.121.1.1). There seem to be over 100 examples of this pair of domains in the template library, so I suspect that it is a 2-domain hit. Mon Jun 16 18:27:05 PDT 2008 Kevin Karplus try1-opt3 looks pretty good. The breaks before T172 and L67 may need to be reduced though. I'll start a polishing run with breaks and clashes turned up. I'll also remove the various beta-sheet and cysteine costfcns, since this appears to be an all-alpha protein with no cys clustering. Helix constraints will be taken from try1-opt3. Mon Jun 16 19:39:03 PDT 2008 Kevin Karplus try2-opt3 seems to have done a decent jobs of closing breaks and avoiding clashes. It may have "foamed" a little bit to avoid clashes---the packing is not quite as tight as I would like to see, but the pred_nb11_back and dry terms are better for try2-opt3 than for try1-opt3, so it can't have gotten too bad. I wonder if I should look for a dimer for this target. 2uxu (the top hit) is dimeric. (http://www.ebi.ac.uk/msd-srv/pqs/) The try1 model seems to be based mainly on 1vi0A, which is also dimeric, so I should probably make a dimer based on 1vi0A and optimize that in a dimeric context. Tue Jun 17 03:43:20 PDT 2008 Kevin Karplus dimer/decoys/dimer-try2-1v10.pdb does not look bad, but has some clashes. My first attempt to resolve those clashes (dimer/try3-opt3) pulled the monomers apart too much. The problem seems to be with the C-terminal tails, which are not from alignment, but which ended up tucked into the dimer interface, instead of sticking out. I need to chop off A196-A203 from the monomer and move it out of the way. Perhaps I should make a broken monomer that has this tail in pieces well out of the way, make a dimer of it, then reoptimize that dimer without letting the monomers move much. I could add some constraints, like that the two Y24.CG atoms stay within about 4 Angstrom, P109.CA stay within about 4 Ang of S104.CA in the other chain, and I189.CB within 4 Ang, to keep the two monomers together. Keeping the G156.CA atoms close would also be good. Let's try Constraint Y24.CG Y227.CG 0 4 6 Constraint G156.CA G359.CA 0 5 7 Constraint I189.CB I392.CB 0 3 6 to hold the dimer together and try closing the gaps on the dimer-broken-1vi0 model. Tue Jun 17 04:55:27 PDT 2008 Kevin Karplus dimer/try4 failed after a few iterations (which seemed to be going ok) undertaker: AlignedFragments.cc:1078: virtual int AlignedFragments::OK(int): Assertion `kk::abs(length2-dist2) < 1.e-3*(dist2+1)' failed. This assertion is a check on tertiary edge length, and I have no idea where it might be getting messed up. I'll try another run (with a different random seed), to see if I can avoid this bug, but I'll save the log file, in case I want to try running under the debugger with the same seed to try to actually *find* the bug. Tue Jun 17 07:55:53 PDT 2008 Kevin Karplus Foo! try4 crashed again with a different assertion failure: undertaker: XYZpoint.h:57: void XYZpoint::unitize(): Assertion `mag>0' failed. Tue Jun 17 09:08:26 PDT 2008 Kevin Karplus For the tertiary-edge-length crash, the bug is reported from make_spanning_tree, right after recompute_edge_lengths(). make_spanning_tree was called from insert_fragments, from insert_fragment, from CrossAndInsert. The fragment was a single residue (A62). The problem is with EdgesInSet[12] {Owner = 0x112f6408, FirstAtom = 469, SecondAtom = 474, Length2 = 8.18274693e+25, NoDelete = 0} So how did recompute_edge_lengths() get messed up? AtomLoc->Points[469] is messed up: {X = 9.04689992e+10, Y = 9.00468965e+11, Z = 9.00046887e+12} and atom 469 is the first atom of the residue being inserted. The problem may simply be that the "FAR_POINT" used to wipe out the residues being replaced is so far out that rounding error makes the length computation have too much error. Tue Jun 17 15:19:11 PDT 2008 Kevin Karplus I'm now triggering a "mag>0" assertion failure from coplanar_trans(), transforming second->N_atoms to first->C_atoms in merge_segments() (from merge_all_short_segments, from insert_fragments, from insert_fragment, from CrossAndInsert. The problem seems to be in about the same CrossAndInsert call as before, with res=61 Hmm, first->C_atoms.Points[0] is (Nan,Nan,Nan), while second->N_atoms seems ok. Tue Jun 17 18:58:22 PDT 2008 Kevin Karplus I think I found a bug in find_breaks that was introduced 2 years ago, that would explain the bad behavior. Let's hope this fixes the problem! Tue Jun 17 20:33:49 PDT 2008 Kevin Karplus Different crash in almost the same place, and gdb can't even tell me where the unitize() assertion failure occured. Fri Jun 20 14:12:17 PDT 2008 Kevin Karplus MQAU favors MULTICOM-REFINE_TS4, MUProt_TS3, and MULTICOM-CLUSTER MQAC favors MAETATASSER, pro-sp3-TASSER, and Zhang-Server MQAC predicts GDT of 72% for the top models and only 64% for the SAM-T08-server model. I've started metaserver predictions with the try2 costfcn. Fri Jun 20 14:41:15 PDT 2008 Kevin Karplus MQAU2 is based mainly on MUProt_TS3 MQAC2 is based mainly on Phyre_de_novo_TS1 Sat Jun 21 14:59:59 PDT 2008 Kevin Karplus try2 favors try2-opt3, MQAU2-opt3, MQAC2-opt3, try1-pot3.gromacs0 Sat Jun 21 15:04:24 PDT 2008 Kevin Karplus The different top models are only very slightly different from each other. If I can get this to optimize in a dimeric context, I should be all set. I may want to do a polishing run to close the smal remaining gaps in try2-opt3. Sat Jun 28 14:19:09 PDT 2008 SAM-T08-MQAO hand QA T0454 Submitted Sat Jun 28 14:19:09 PDT 2008 SAM-T08-MQAU hand QA T0454 Submitted Sat Jun 28 14:19:09 PDT 2008 SAM-T08-MQAC hand QA T0454 Submitted Wed Jul 2 13:06:32 PDT 2008 Kevin Karplus I'll try making a dimer from MQAU2-opt3 and the 1pb6A/B template, and see if I can optimize it without crashing. Wed Jul 2 15:25:05 PDT 2008 Kevin Karplus Nope, try5 crashes also, so I really need to debug undertaker! undertaker: ../ultimate/src/Transform/Transform.h:80: bool Transform::OK() const: Assertion `is_finite()' failed. I think that the problem is in computing the transformations to the xy plane---I must sometimes get a 0/0 error or something. Wed Jul 2 19:18:42 PDT 2008 Kevin Karplus After protecting against a 0/0 error in the xyplane call, dimer/try5 ran successfully. I'll retry dimer/try4 also. Wed Jul 2 19:58:59 PDT 2008 Kevin Karplus dimer/try4 is getting past the place where it crashed before, so I may have squashed that bug finally. Thu Jul 3 03:52:22 PDT 2008 Kevin Karplus Yes! dimer/try4 finished, and scores almost as well as dimer/try5--slightly more breaks, slightly less clashes, at least after running through gromacs. Thu Jul 3 04:02:46 PDT 2008 Kevin Karplus The dimer optimization does not seem to have moved things much. I'll do one more monomer optimization (including the dimer models), then one more dimer optimization and declare this done. Thu Jul 3 05:41:44 PDT 2008 Kevin Karplus The try6 optimization (from try2-opt3) scores well. I'll make a dimer from that and optimize it. Thu Jul 3 09:15:19 PDT 2008 Kevin Karplus All the models are still quite similar. I'll submit 1 dimer/T0454.try7-opt3.unpack.pdb chain A #< dimer-try6-1vi0 < try2-opt3 2 dimer/T0454.try5-opt3.unpack.pdb chain A #< dimer-MQAU2-1pb6 < MUProt_TS3 3 dimer/T0454.try3-opt3.unpack.gromacs0.repack-nonPC.pdb #< dimer-try2-1vi0 < try1-opt3 < align(1vi0A) 4 T0454.MQAU2-opt3.pdb # < MUProt_TS3 5 T0454.MQAC2-opt3.pdb # < Phyre_de_novo_TS1