Posts by Chu

1) Message boards : Rosetta@home Science : Structure prediction of zinc-binding proteins (Message 63372)
Posted 15 Sep 2009 by Chu
Post:
An idea to think of for handling proteins that bind to other metal ions:

Create a module similar to the one for handling zinc ions, but with more adjustment parameters so that you can make it handle a wide variety of metal ions.

Then, if you need to handle any proteins bound to at least two types of metal ions, just include two or more of these modules in future versions of minirosetta, but instruct them to get their parameters from different files.


That is exactly how it is handled in Rosetta. An input parameter file handles the type of metal ion and the geometries of how it is bound to the protein. Once we show this approach works for zinc-binding proteins, it can easily be expanded to simulate structures of other metal-binding proteins. Happy crunching!
2) Message boards : Number crunching : Minirosetta v1.47 bug thread. (Message 58144)
Posted 23 Dec 2008 by Chu
Post:
greb_be and all,

When there is a new version of minirosetta update, we usually put a windows debug symbol image in a downloadable location. So when a WU crashes out, it should provide a backtrace of how an error is caused (this does not work every time and that makes our debugging very hard). If it is an error from Minirosetta program or bad command line/input file setup, the stdout or stderr usually will print out a message as hints, for example, the hbond NAN problem in the previous versions. Also, we should see a significantly higher error rate among either all or certain batches of WUs running. If it is caused by interfacing with the host's hardware or software, we will usually see that certain client hosts kept encountering errors or failure. We wish we could tell what have been wrong in every scenario when an error occurs, however, most of us Rosetta developer are far from being an expert on computer software/hardware and we can only hope to trap errors locally on our testing machines to continue with debugging.

Thank you all for voluntarily helping us on doing this project and sorry about any inconvenience/trouble caused on your computer. Please continue to report problems and/or possible fixes you have found as every bit of such information will certainly help us to improve R@H stability and resolve hidden bugs/problems sooner or later. Happy holidays to every one and happy crunching!

I have the same problem on 64 bit Win 2008 server only for all Minirosetta tasks. Minirosetta 1.45 had this problem too. All other PC (32bit, XP64bit) have no problem.

Zdenek


Chu,

Thanks for replying. I suspect its my over clock speed. If you have that many clients returning good tasks and I see the last one I posted went through to another client ok, I have to assume my speed is to high for these tasks on RAH.
I dropped the speed by 10 mhz to see if that corrects the problem, if it continues then I will drop it some more until things become steady. as of a week ago I could run at the faster speed with no problems. But this week the majority die.

Normally when my speed is to high, the tasks fail immediately. So I don't understand how a task can run eight thousand seconds and then crash. I had another one that ran up to 10 mins of completion and died.

Can you tell me how to see the difference between a error due to windows or OC speed vs a program error that triggers a windows dump with '-1073741819 (0xc0000005)'?

Thanks again for the reply.



3) Message boards : Number crunching : Minirosetta v1.47 bug thread. (Message 58126)
Posted 23 Dec 2008 by Chu
Post:
Hi greg_be, this WU is one of my jobs and I just double checked this sub-batch, so far about 9000 clients have returned results successfully with normal error rate. The fact that you recently have got same error code from many different Rosetta@home workunits makes me think that it is more likely due to some certain incompatible setup on your computer, though I don't know what is exactly causing this. Did this problem happen to you before?

your vanilla task died at 2hrs and 23 mins.
this makes about 12 failures now in 2 days.
http://boinc.bakerlab.org/rosetta/result.php?resultid=216178144
1g47A_BOINC_MPZN_vanilla_abrelax_5901_7554_0
Client state Compute error
Exit status -1073741819 (0xc0000005)
CPU time 8912.25
stderr out

<core_client_version>6.4.5</core_client_version>
<![CDATA[
<message>
- exit code -1073741819 (0xc0000005)
</message>
<stderr_txt>
# cpu_run_time_pref: 14400


4) Message boards : Number crunching : Minirosetta v1.45 bug thread (Message 57714)
Posted 8 Dec 2008 by Chu
Post:
Hi everyone, due to a limitation on command line length set by BOINC, the jobs with name "*_ZN_ABRELAX_*" have their command lines automatically truncated when sent out on Rosetta@Home. That is why you see it stopped with an ERROR like "ERROR: Illegal value for integer option -run:jran specified: " right away. In fact, the same workunits returned with very good success rate on the testing server. We are investigating why the alpha testing server did not catch such errors in the first place. This is another unfortunate incident which will be a new lesson for us. Sorry for any inconvenience this has brought to you.
5) Message boards : Rosetta@home Science : What do you do with the results we send back? (Message 57615)
Posted 5 Dec 2008 by Chu
Post:
Actually there is a lot to be investigated from those results. To name a couple of examples, some results will let us find out problems in our energy force field and its improvement will help us to make better models. Some optimization runs will create native-like structure models that are to be experimentally characterized later on. There are many great articles around in this forum describing aims of each individual project and it is impossible to finish them if without generous contribution from users all over the world.
What do you do with the results from the optimization runs that we send back to you?

6) Message boards : Rosetta@home Science : Structure prediction of zinc-binding proteins (Message 57614)
Posted 5 Dec 2008 by Chu
Post:
Great data mining work, robertniles! Thank everyone for such a wonderful discussion. Definitely all the other metals are our to-do list and we are very excited about introducing for the first time metal into Rosetta structure modeling. As mentioned in my original post, Zinc is one of the most abundant metals found in natural protein molecules, playing both important structural (stabilizing proteins) and catalytic (helping realize protein functions) roles. A lot of zinc-binding proteins are involved in DNA binding and recognition and the most popular structure motif is referred as "zinc finger". For example, an enzyme called Integrase in HIV virus has a structural domain that contains zinc-binding sites and is believed to be responsible for multimerization of this enzyme. To understand how the zinc binding affect this process will certainly help us find new insights to fight against HIV. I am glad to see the last post mentions matrix metalloproteases because I am soon to join a new lab which have done a lot of work in characterizing unknown MMPs in human proteomics which are believed to be cancer related. I am very grateful to everyone's contribution to our project and I will surely keep everyone posted when there is any exciting results we will obtain in future.
Could we have some indication if which other metal ions minirosetta can now handle binding to proteins? For example, some which can bind are copper, cadmium, cobalt, iron and magnesium.

Are any more of these planned for the future?

7) Message boards : Number crunching : Minirosetta v1.40 bug thread (Message 57345)
Posted 29 Nov 2008 by Chu
Post:
Hi everyone,

the fix to the NAN hbonding problem will be included in the next update (probably after this weekend) and we are still investigating the problem of lockfile and that some WUs cannot be suspended. Sorry for the trouble and inconvenience and we will try our best to avoid such problems from happening on such a large scale in future.

Please continue to report other errors and problems that are not mentioned above.
8) Message boards : Number crunching : Minirosetta v1.40 bug thread (Message 56745)
Posted 6 Nov 2008 by Chu
Post:
we have also located the graphic problem when there is non-protein ligand displayed and implemented a fix to that. So please let us know if you still observe such problems.
9) Message boards : Number crunching : Minirosetta v1.39 bug thread (Message 56688)
Posted 3 Nov 2008 by Chu
Post:
A quick look at your host's recent job history showed that you got client errors for almost all types of WUs sent out, which have been running fine and have had models returned successfully on other host computers. I would suggest to restart your boinc manager to see if the problem goes away. And sorry for this trouble you have had on your computer.
I'm having many WU's with this message

--> http://boinc.bakerlab.org/rosetta/result.php?resultid=204831583

What I have to do?

10) Message boards : Number crunching : Minirosetta v1.39 bug thread (Message 56687)
Posted 3 Nov 2008 by Chu
Post:
Hi everyone, thanks for reporting the graphic problem of ZN workunits. We are currently running local tests hoping to locate and fix the problem as soon as possible. Meanwhile, please be assured that this error does not seem to affect actual model production and your credits should not be affected at all. Sorry for the inconvenience.
I haven't noticed any graphics instability with the with 1.39 with the 15 work units I have done/doing today. I have XP (service pack 3) using BOINC 6.2.19


I think it is related to the Zink-Workunits. Other workunits do not seem to be affected.



see my post which I identified one Zinc work unit that the graphics cut out on me. See if you have a matching or similar named task.

These zinc tasks are causing all kinds of fun problems for the team to explore.

11) Message boards : Number crunching : Minirosetta v1.39 bug thread (Message 56686)
Posted 3 Nov 2008 by Chu
Post:
Hi, this could happen if during the course of simulation, different energy functions are switched at different stages.
Not sure if this actually belongs here, but nevertheless:

I just noticed that the low energy value in the screensaver jumps to a higher value at times.
Is that intended?

Edit: I wouldn't have posted this if that had happened when the computation of a new model started.

12) Message boards : Number crunching : Rosetta Application Version Release Log (Message 56522)
Posted 30 Oct 2008 by Chu
Post:
The minirosetta application has been updated to version 1.39. In this version, we added two important applications to minirosetta, docking and protein folding with explicit zinc metal ion. New features have been added to the graphic to show chain colors for a multi-chain protein complex and display metal ions by sphere.
13) Message boards : Rosetta@home Science : protein-protein docking at Rosetta@Home (Message 56503)
Posted 29 Oct 2008 by Chu
Post:
Hello everyone, sorry that I have not been around in this forum for a while and here are some updates regarding my work on protein-protein docking which would not have been possible without you guys' contribution. Based on the data produced from Rosetta@Home, we published a research article last year and I am posting the abstract below. In summary, we found that introducing backbone flexibility into rosetta docking simulation helps to improve sampling around native conformation to some extent (that is, the new treatment allows us to get access to native conformational space which was inaccessible with rigid-backbone assumption) and energy discrimination between native-like and non-native-like models (which means more likely for us to pick out correct structures based on energy). However, the overall problem is still quite challenging because the sampling space is dramatically enlarged when backbone flexibility, especially when there is no any external information which can be used as hints to derive possible types of backbone movements. This is essentially the problem of folding two proteins independently and then dock them. This published paper concluded my Ph.D thesis and I am personally very grateful to all Rosetta@Home users for their generous help.

While I went on to take some different projects(structure prediction of zinc-binding proteins is just one them!), there are other people in the lab who are continuing to develop new algorithms in Rosetta to improve our docking method. All the existing functionalities in Rosetta have been successfully ported over to the minirosetta application (and now with the long-waited docking graphic) and they are ready to test it out on Rosetta@Home. Actually, there is another round of blind docking prediction competition CAPRI (similar to CASP) which was just announced and I believe soon you will get new WUs crunching models to help us find the correct solution for a protein complex with unknown (at least currently to us) structure.

Thanks again for everyone's contribution.

J Mol Biol. 2007 Oct 19;373(2):503-19. Epub 2007 Aug 2.
Protein-protein docking with backbone flexibility.
Wang C, Bradley P, Baker D.

Department of Biochemistry and Howard Hughes Medical Institute, University of Washington, Seattle, WA 98195, USA.

Computational protein-protein docking methods currently can create models with atomic accuracy for protein complexes provided that the conformational changes upon association are restricted to the side chains. However, it remains very challenging to account for backbone conformational changes during docking, and most current methods inherently keep monomer backbones rigid for algorithmic simplicity and computational efficiency. Here we present a reformulation of the Rosetta docking method that incorporates explicit backbone flexibility in protein-protein docking. The new method is based on a "fold-tree" representation of the molecular system, which seamlessly integrates internal torsional degrees of freedom and rigid-body degrees of freedom. Problems with internal flexible regions ranging from one or more loops or hinge regions to all of one or both partners can be readily treated using appropriately constructed fold trees. The explicit treatment of backbone flexibility improves both sampling in the vicinity of the native docked conformation and the energetic discrimination between near-native and incorrect models.
14) Message boards : Rosetta@home Science : Structure prediction of zinc-binding proteins (Message 56500)
Posted 29 Oct 2008 by Chu
Post:
We are currently doing a research project in rosetta aiming at developing methods to predict structures of zinc-binding proteins. Some of the tests are currently being performed on Rosetta@Home now with the newly updated V1.39 application. From the user's view, the most noticeable change will be the graphic in which a protein is folding around a colored sphere, representing the zinc metal ion. And here is a little more background about this project.

A large number of proteins in nature include metal atoms as part of their structures, of which zinc is one of the most commonly employed types. For example, about 3% of the protein sequences inferred from human genome are predicted to contain zinc-binding motifs. Many zinc proteins carry out biologically important functions, including zinc-fingers as transcription factors, matrix metalloproteins involved in cancers and cardiovascular diseases, and zinc proteases as lethal factors in anthrax toxins.

In general, zinc metal in proteins plays either a structural role or a catalytic role. In former cases, it is coordinated by protein sidechains and helps to improve the stability of the structure motif. In latter cases, it employs its unique feature as a transition metal and a positively charge ion to participate in the substrate activation and enzymatic catalysis. Currently, zinc metal has been employed in both structure prediction and protein/enzyme design projects in the Baker laboratory.

For the project of structure prediction of zinc proteins, we are modeling zinc metal ion explicitly during the simulation of ab initio protein folding. One common feature we learned from native zinc-binding(structurally) proteins is that zinc metal ion is coordinated by four protein sidechains, most often, Histidine and Cysteine, in a tetrahedral geometry. That is, zinc is positioned in the center of the tetrahedron, and four itrogen (HIS) or sulfur (CYS) atoms are positioned on the vertexes of the tetrahedron. If you look at the structure displayed on your graphic and color them by CPK (hitting "C" key), you should find out that there are always four either blue (nitrogen of HIS) or yellow (sulfur of CYS) sidechains around the zinc (displayed as sphere). This important zinc coordination motif is implemented as part of rosetta energy function and we are hoping that by combining the explicit zinc metal modeling and Rosetta ab initio prediction method, we can develop a useful method to predict structures accurately for this class of important proteins in nature.

Of course, to achieve this goal, we will have to rely on the generous help of all Rosetta@Home users from all over the world. Feel free to let me know if you have any questions or insights on this project. Happy crunching!
15) Message boards : Number crunching : Minirosetta v1.39 bug thread (Message 56498)
Posted 28 Oct 2008 by Chu
Post:
Please report issues and bugs with Minirosetta v1.39 in this thread. In this update, we added two important applications, protein docking and protein folding with explicit metal ions. From the graphics, you probably can tell them by a structure with two different chain colors and a protein folding around a colored sphere, respectively. See the Rosett@home science section for more descriptions on these projects.
16) Message boards : Number crunching : Problems with rosetta 5.48 (Message 37453)
Posted 5 Mar 2007 by Chu
Post:
All the jobs we are running on Rosetta@Home were tested on Ralph@Home beforehand and if we have seen an unusually higher rate of problems, we will not add them to the queue here. For example, all the "HINGE" WUs have been tested on Ralph with the same high memory requirement and the error rate was normal. However, since Ralph is only for testing purpose, we do not usually send out too many jobs for each batch. So this means that 1. one client computer may not get multiple jobs running at the same time; 2. not all platforms are tested with the same distribution as represented on BOINC ( I think Ralph is overly represented by windows platforms ). This could be partially responsible for the problems you guys are reporting here. We are sorry for any inconvenience and will try our best to do better testing in future.

My guess is they only have 4,000 hosts to test on Ralph, but 273,000 to test with on Rosetta. Same as the graphics.........everything seems to get rolled out before it is thoroughly tested on Ralph.

Yet at the same time on the Ralph message boards are questions why there isn't enough work for testers. I don't think a lack of testers and test machines is the issue.

17) Message boards : Number crunching : Problems with rosetta 5.48 (Message 37450)
Posted 5 Mar 2007 by Chu
Post:
I think it is the problem of lacking enough memory as yours has only 256MB.
Other Rosetta wu in que seems to have the same problem... only this one stopt at 1.030%

;-)


At least this wu came with some info...


----------------

<core_client_version>5.8.15</core_client_version>
<![CDATA[
<message>
aborted by user
</message>
<stderr_txt>
Graphics are disabled due to configuration...
# random seed: 3363307
Graphics are disabled due to configuration...
# random seed: 3363307
SIGSEGV: segmentation violation
Stack trace (15 frames):
[0x8b63f87]
[0x8b7fdcc]
[0xffffe420]
[0x8bb654e]
[0x8bb68ad]
[0x82631fc]
[0x86a0dbf]
[0x8ae0a75]
[0x843d845]
[0x80e592d]
[0x8521d37]
[0x863a03b]
[0x863a0e4]
[0x8bdf184]
[0x8048121]

Exiting...

</stderr_txt>
]]>


-----------------

;-)

18) Message boards : Number crunching : Problems with rosetta 5.48 (Message 37449)
Posted 5 Mar 2007 by Chu
Post:
Hi all, the "HINGE" WUs are simulating a very large protein which has more than 800 residues ( versus less than 200 residues normally we have run on BOINC ) and thus requires much more memory than usual. We have put a higher memory requirement on these jobs. Also, high priority has been assigned because it is for a blind docking prediction with the deadline coming soon. That can explain why some low-memory clients can not receive jobs temporarily.
19) Message boards : Number crunching : [Request] Progress Estimation (Message 36924)
Posted 17 Feb 2007 by Chu
Post:
We will discuss about your suggestion and come back with a proposal on how to make this feather best reflect what is actually happening in Rosetta.
No comments of the developers?

20) Message boards : Number crunching : Problems with Rosetta version 5.46 (Message 36923)
Posted 17 Feb 2007 by Chu
Post:
Hi you all, we actually did find a bug which has caused very high rate of "stuck" trjactories for docking workunits and has included it in V5.46 update. Those trajectories are not stuck themselves, but the watchdog thread is fooled to think they are stuck. Although this fix did make improvement a lot, we also find that it is not completely solving the problem. Compared to other "protein folding or farlx" workunits, docking workunits generally have less number of "acceptance" steps and therefore energy values do not change as frquently. That is believed to be the culprit as the watchdog thread is checking energy value periodically to decide whether a run is stuck or not. We have proposed a more robust solution to this problem and plan to include it in the next scheduled update. Thank you all for the help.
i think the docking units are getting stuck on our AMD chips for some reason.
I had a similar error on this: CAPRI_12_ND73_GLOBAL_DOCKING_1562_9081_0 and a similar one. Both were global docking. I read somewhere in here or over in Dr. Bakers message board area that this was likely to happen at random with these WU's.



Next 20



©2020 University of Washington
http://www.bakerlab.org