1)
Message boards :
Number crunching :
Problems with Rosetta version 5.62
(Message 40492)
Posted 7 May 2007 by Bin Qian Post: Hi Mike and Feet1st, You were right - these jobs were only sent out to high memory hosts! They are for a protein with 400 residues so it was expected to take up a bigger chunk of memory. Bin Upon reading Mike's post, I took a look. I have: |
2)
Message boards :
Number crunching :
New CASP results
(Message 29466)
Posted 16 Oct 2006 by Bin Qian Post: Hi All, Thanks for your careful reading of the top prediction page! I made a mistake when taking the user's id from the result's tag. The error has been corrected. Thanks again for all your help. Bin |
3)
Message boards :
Number crunching :
Typo in WU name? T181
(Message 21334)
Posted 28 Jul 2006 by Bin Qian Post: Very observertive! And very good guess too! This is for t381, which is a two domain protein. So I named them t181 and t281 when I model the domains separately. Also expect to see WUs with name t281 tomorrow! Thanks! |
4)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.25
(Message 19720)
Posted 2 Jul 2006 by Bin Qian Post: Sharp eye! You are totally right - t103 is not in casp7. It's the N terminal domain of T303. The same is true for t130, the N terminal domain of T330. I just got this WU. Its named Fra_t103_Casp7... I assume that is a typo and probably means t303 since no t103 exists in CASP7. |
5)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.25
(Message 19719)
Posted 2 Jul 2006 by Bin Qian Post: Thanks for reporting this error! The jobs have been deleted from the queue, but if you still got those queued up on your system, please feel free to delete them. Sorry! About a third of the 1000 starting structures were not recognized by the rosetta application for this WU. When that happened, Rosetta will finish within a couple of minutes of starting. Since no .out.gz result file was produced, boinc reports a "file not found" error. Apparently those bad starting structures were not included in our ralph test of this WU where only a samll subset of the starting structures were used. We will remove the bad starting structures and resend the jobs. Thanks again for reporting this! I also had FRA_t329* WU crash on WinXP. Perhaps the project should delete them from the queue? |
6)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.24
(Message 19099)
Posted 22 Jun 2006 by Bin Qian Post: This protein is one of the largest CASP target we ran on r@h - 336 residues. We've marked these WUs as high memory jobs and they will only be sent to machines with more than 512M memory. As David Kim has said in his post below, the queueing system will make sure there are always low memory jobs available for all the users. |
7)
Message boards :
Number crunching :
T0's and t's
(Message 18765)
Posted 16 Jun 2006 by Bin Qian Post: They are different names for the same CASP target number 316. Im just curious as to what the difference between say: |
8)
Message boards :
Number crunching :
Rosetta Application Version Release Log
(Message 18183)
Posted 8 Jun 2006 by Bin Qian Post: Version 5.22 is up: 1. We have put in a symbol store to give us more debugging information. We'll only get this information back, though, if you have the latest BOINC release, available here. If you have the time, please download it! This will be our number one debugging tool. 2. Apps that can't find the appropriate libraries to display graphics (for whatever reason) will now not display graphics. Hopefully, this will help with some of the rare cases where graphics is triggering errors. 3. We removed the excessive print statements to stdout.txt that were filling up some users's disks for a particular kind of workunit. 4. We we made some fixes to the graphics, like removing the ghost "Accepted Energy" and making sure all protein pictures are properly centered. 5. There have been some fixes to clean up how different threads (e.g. rosetta itself, graphics, the watchdog) shut down at the end of the run. We expect this to reduce errors. 6. A version for Mac Intel machines has been released! |
9)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.16 II
(Message 17481)
Posted 31 May 2006 by Bin Qian Post: Thanks to your helpful messages, we've tracked down the rare bug that's causing this in the code and fixed it. The fix will be included in the next release. Great job all! Luckily we only sent out 5000 of these bad WUs (A very small number compare to the 120,000 done everyday) and about a third of them were affected. You will still get credits for those jobs killed by the watchdog when our credit-grantor runs nightly! It's been ages since I had another error to report, but this morning I noticed one... never seen that one before. |
10)
Message boards :
Rosetta@home Science :
Comments/questions on Rosetta@home journal
(Message 15459)
Posted 3 May 2006 by Bin Qian Post: Great thoughts! You are definitely on the right track of a general protocol for structure prediction. The approach you described - the comparative modeling approach - is actually being routinely used by biologists nowadays. One aspect of the Rosetta@Home project is to develope methods to improve the template-based structure models. Some of the work units you are currently running are doing extractly this type of work! You can read a little more about these work units here. If you know the amino acid sequances, and you know the structures of mutiple proteins then why don't you combine the two? |
11)
Message boards :
Rosetta@home Science :
Rosetta@home Active WorkUnit(s) Log
(Message 15302)
Posted 2 May 2006 by Bin Qian Post: I've just sent out some work units with names starting with: HOMO_xxxx_h0xx_1_LOOPRLX_ You all have been well informed by David(s) and Rhiju about the ab-initio approach they are using to fold a protein from its amino-acid sequence. I'm working on another category of the protein structure prediction problem, namely the "comparative modeling" approach. Here is how this approach works: when we want to predict the structure of a protein, we usually first do a database search on the available protein structures. Often times we can find that the protein we want to predict has a brother/sister (called a homologous protein) with its structure solved by one of the accurate but time-consuming experimental methods. It is well known that for a pair of homologous proteins, they share more or less similar shapes. This important information can give us a "short cut" towards solving our target protein's structure because now we can jump-start our coarse-grained conformational search with the homologous protein's structure, and only search parts of the structure that are either missing or likely to be different from the homologous protein structure. This coarse-grained search is followed by a fine-grained search in which we are trying to locate the precise positions of a protein's hundreds of thousands of atoms (called fullatom relax stage) based on its rough shape determed by the coarse-grained search. This is the same fullatom relax stage as the second step in David(s) and Rhiju's approach. On the screen saver you will likely see the WU starts with a compact protein structure (the homologous structure), then some parts of the structure start to move around. After they settle down, the whole protein will start to wiggle with smaller scale motions. |
12)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.07
(Message 15236)
Posted 2 May 2006 by Bin Qian Post: Hi Jose, ".fragments.cc line:722" says that Rosetta thinks the "fragment file" it's reading has wrong format. Since all the work units named HBLR_1.0_1dtj_ROT_TRIALS_TRIE_462_xxxxx_x will read in the same "fragment file" during rosetta initialization stage, it probably indicates that the file in your reported WU has crashed or been truncated during file transfering. We have received successful results for this batch so this is very likely an isolated case. But we will keep an eye on it. Thanks. A new type of error has shown up. (Meaning a "non 107 Type" . ) |
13)
Message boards :
Number crunching :
Report Problems with Rosetta Version 5.07
(Message 15234)
Posted 2 May 2006 by Bin Qian Post: Thanks for reporting. I think Moderator9 is right - it's likely a file transfer error and probably just an isolated case. just noticed in my previous message that rosetta vesion is shown as 5.01 |
14)
Message boards :
Rosetta@home Science :
CASP7 to start in April
(Message 14926)
Posted 28 Apr 2006 by Bin Qian Post: In the previous CASPs, the targets were released throughout the period of the competition, with due dates usually several weeks after the release date. We will post the sequences and related information of the CASP7 targets as we receive them, and give you estimation of the number of decoys we request and the number of decoys returned. By the way I just posted casp6 target list in another thread. The "Entry date" is the target release date, and the "Expiry-date" is the target due date.
|
15)
Message boards :
Rosetta@home Science :
Are the 'Native' graphics incorrect?
(Message 14925)
Posted 28 Apr 2006 by Bin Qian Post: t198 stands for Target number 198, which is the 198th target released since CASP1. You can find the complete list of targets for CASP6 as well as their links to the PDB database in the page below: casp6 target list Are the 'Native' graphics incorrect? |
16)
Message boards :
Rosetta@home Science :
CASP7 to start in April
(Message 14831)
Posted 28 Apr 2006 by Bin Qian Post: We will definitely have a thread posting CASP7 target charts as we get them. On May 8th we will get the first target! People like progress charts. ;-) |
17)
Message boards :
Number crunching :
Release log history (read only)
(Message 14799)
Posted 27 Apr 2006 by Bin Qian Post: Rosetta 5.06 is up. This version has some new error-catching features and some new science: (1) Multiple checkpoints. Rosetta saves more information along the way. If its preempted and restarted, now it doesn't have to start from scratch. For large jobs, these checkpoints have tripled the rate of structure prediction on our test project RALPH! (2) Watchdog timer. This timer will abort jobs that appear to be stuck in infinite loops (no progress for an hour) or have gone over the preferred CPU run time by four-fold. This should help those clients that cannot be continuously monitored, like the ones from big computer farms. (3) "Jumping" We're also implementing a new simulation protocol that works better for large complex proteins, with some parts of the chain glue together and other parts broken to release the strain. You'll see some pretty interesting simulations! |
18)
Message boards :
Number crunching :
Auto abort for Hung Work Units - Discussion
(Message 14486)
Posted 23 Apr 2006 by Bin Qian Post: This is exactly what we are going to do based on all your excellent suggestions! Make the client trouble free. That means that if the project feels even the errors are useful, then report them to the project (i.e. select a unique exit message), but don't bother the client about it (i.e. don't show it as an error). If the client ends the WU, and returns valid results that are useful to the project... well, then it's NOT an error. Even if the result is just to identify a hung WU and Rosetta combination that needs to be investigated further. |
19)
Message boards :
Number crunching :
Auto abort for Hung Work Units - Discussion
(Message 14485)
Posted 23 Apr 2006 by Bin Qian Post: This is actually a case indicating the new watchdog is improving! I think Rhiju fixed a bug in the v5.02 watchdog (the one killed one of your WU by mistake), and the fixed v5.03 watchdog let the WU went through! [quote]I'm not sure, see this WU: |
20)
Message boards :
Number crunching :
Auto abort for Hung Work Units - Discussion
(Message 14460)
Posted 23 Apr 2006 by Bin Qian Post: BTW, does the watchdog thread take into account the speed of the system? A very slow system will need more time to complete a percent-incrementing step. By default the watchdog kills a WU when the energy doesn't change ( = no movement on the searching section of your screen saver) for 30 minutes. It's probably a pretty conservative figure even for the slow computers. |
©2024 University of Washington
https://www.bakerlab.org