Posts by Bin Qian

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:
FRA_a016_STRUCTURAL_GENOMICS_hom001_2_a016_2_1i74A_IGNORE_THE_REST_3_1700_2871_0
using 400MB. Peak was 548MB.

I'm sure these WUs were flagged as only for high memory systems, but these usage numbers still seem to be about double previous high memory tasks.

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:

T0316 and t316?

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.

Resultid21972244 (Workunit18429646)



It means that the watchdog function placed to prevent Wu's stuck in time IS WORKING as it is supposed to do. I imagine that that unit and the ones where the watchdog is terminating the processing ( and there are some few recently) will be analyzed to see what is happening that is causing the watchdog to work.

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?

Like this: amino acid n is usually folded x fasion.

If you see my point, you could make a database of all the known structures for that sequence, then weight the probability of an amio acid structure, so as to have a most probable to least probable structure for each of the amino acids sequances, test each to find the energy levels for the overall protein that you are trying to predict.

Of course this wouldn't find a structure that to date is unknown but it maybe a shortcut for the others.

You may do something like this already. It was just a thought that struck me so I thought I'd bounce it off the R@H team.

Edit: clarity

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" . )

BTW 107 types are still showing up: When are we going to get help or more information regarding them?


http://boinc.bakerlab.org/rosetta/result.php?resultid=18820267

Result ID 18820267
HBLR_1.0_1dtj_ROT_TRIALS_TRIE_462_13051_0
Workunit 15562229
Created 1 May 2006 11:58:34 UTC
Sent 1 May 2006 16:07:20 UTC
Received 2 May 2006 1:43:43 UTC
Server state Over
Outcome Client error
Client state Computing
Exit status 1 (0x1)
CPU time 19.34375
stderr out <core_client_version>5.2.13</core_client_version>
<message>Incorrect function. (0x1) - exit code 1 (0x1)
</message>
<stderr_txt>
ERROR:: Exit at: .fragments.cc line:722

</stderr_txt>
Validate state Invalid
Claimed credit 0.0674343140710041
Granted credit 0
application version 5.07


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
even though 'manager' says 5.07.


These errors look very similar to a file error that showed up on Ralph for a particular WU type. I am sure Rhiju or Bin will be along shortly to provide more detail. The fact that your system has moved on so to speak would indicate that it is a Work Unit issue. The version number error is probably just an error message in the code that did not get changed with the upgraded version release.

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.


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. ;-)

Would be great if some Roadmap and charts are available!!!



Will you know on May 8th how many targets you are going to tackle with Rosetta@Home? Will you be able to tell a rough estimate how much models/target you would like to get? Could you from time to time update the information how many models/target you already got?

With this info one could set up a general CASP7-Chart which a single percentage done number. Such a reduction is great in getting people throwing in ressources to bring the "percentage done" number up.

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?

For example, I'm crunching AB_CASP6_t198 and it displays a native view. When I try to find t198 on RCSB Protein Bank Data Bank, I can't. Are they incomplete or is the native view just an optimistic guess?
Ditto for t216, u272, and others.

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. ;-)

Would be great if some Roadmap and charts are available!!!

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:

http://ralph.bakerlab.org/workunit.php?wuid=82603

I completed it successful but it was aborted on a slower comp. Btw can't you just abort the current model and see if the next model is progressing and just kill the whole WU after three models have failed or after the target CPU time has been met?

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.


Next 20



©2024 University of Washington
https://www.bakerlab.org