This app update includes a fix for checkpointing.

Please report issues and bugs here!

thanks,

DK

Hi,

I'll be resubmitting the *gbnnotyr* protein design trajectories to boinc over the next few hours. The tests I ran on ralph showed that the checkpointing issue is resolved. To make sure that there are no other issues, I will submit these trajectories 'slowly' starting with a modest sized batch, and according to the responses I get on the thread I will increase the number of work units over the next few days. Please keep me posted about these problems. Your reports have been invaluable in tracking this problem down!

Sarel.

---

This app update includes a fix for checkpointing.

Please report issues and bugs here!

thanks,

DK

Hi,

I have a strange graphic I wanted to show you... I *think* there *might* be a problem...

Please go to see this sreen shoot :

http://www.flickr.com/photos/37828392@N08/4273
(Capitain Flam is my account on Flickr)


Possible bug for the application BOINC / ROSETTA, because the protein is *completely* folded, in a tiny meat ball ;-)

I hope this is NOT a bug, or even, I hope it will help you to solve it ;)

This app update includes a fix for checkpointing.

Please report issues and bugs here!

thanks,

DK

Hi,

I have a strange graphic I wanted to show you... I *think* there *might* be a problem...

Please go to see this screen shoot :

http://www.flickr.com/photos/37828392@N08/4273

(Capitain Flam is my account on Flickr)


Possible bug for the application BOINC / ROSETTA, because the protein is *completely* folded, in a tiny meat ball ;-)

I hope this is NOT a bug, or even, I hope it will help you to solve it ;)

Sorry, I didn't cut'n'paste well the link... Here it is !

http://www.flickr.com/photos/37828392@N08/4273113531/

Sorry sorry sorry :-|

Bad news guys just woke up today and my homopt_cstmc WU is stuck @ 40% using no CPU time. Although 3-4 other different named WU's have gone through and been totally fine. Just thought id let you know.

Admin, please double check the application version those are running under. (it is shown in the tasks tab of the advanced view under the application column)

---

Rosetta Moderator: Mod.Sense

Admin, please double check the application version those are running under. (it is shown in the tasks tab of the advanced view under the application column)

About
http://www.flickr.com/photos/37828392@N08/4273113531/

I confirm running under :
Rosetta mini 2.03

I can 100% confirm i am/was running the new version mini rosetta 2.05 when i got the stuck homopt WU. Heres the WU link: https://boinc.bakerlab.org/rosetta/workunit.php?wuid=282419440. A wingman seems to have also had a compute error, but I can confirm i was running the updated 2.05 client.

New app working well. And it seems that now the WU need less RAM (about 100 MB per WU). Is it true? If it is, then may be this is a step to rosetta's GPU client? :-)

Although I didnt grab a screenshot the task details of the work unit show "application version 2.05" You can check it out at https://boinc.bakerlab.org/rosetta/result.php?resultid=310562856. I wish i could give you guys more information, anything else i can do to help you guys solve this issue? All other work so far has gone through fine, but upon further investigation the common factor is windows 7. I have a boinc_filtered loopbuild_threading running now at 33% which gave me problems on 2.03, so i will see how it goes on 2.05 and give an update.

One of my tasks has "meatballed" too:

lr5_no_pro_close_no_dun_A_rlbd_1rnb_SAVE_ALL_OUT_IGNORE_THE_REST_DECOY_16701_583_0

Running new 2.05

According to the time to completion, it's going to be a long old process too.

Thanks! If these were the *gbn* runs, then they have a low-memory step which is memory efficient, but then they /might/ go on to a memory intensive step requiring 300-500Mb...

New app working well. And it seems that now the WU need less RAM (about 100 MB per WU). Is it true? If it is, then may be this is a step to rosetta's GPU client? :-)

---

Although I didnt grab a screenshot the task details of the work unit show "application version 2.05" You can check it out at https://boinc.bakerlab.org/rosetta/result.php?resultid=310562856. I wish i could give you guys more information, anything else i can do to help you guys solve this issue? All other work so far has gone through fine, but upon further investigation the common factor is windows 7. I have a boinc_filtered loopbuild_threading running now at 33% which gave me problems on 2.03, so i will see how it goes on 2.05 and give an update.

I wouldn't worry about it. A number of these have failed. I have just sent in two that failed on their second run.

---

While The boinc_filtered WU went through fine, i have another that has stalled: opttest2.2d4f..... just thought id give an update, it froze at 18.046%. Other than that 2.05 seems stable although sometimes the graphics crash when i try to look at them.

Just had to shut down boinc, which i did properly to run a few programs quickly. Seems both Wu's the computer was working on started from model 0 when the client restarted. Both units were between 10-15 models done for being around 20% complete which they are currently (20% complete and now working on model 1). Did the units really just start over from 0 and erase all the previous work? Is this another issue we are tracking? Just trying to be helpful!

In another thread, I've seen something about workunits using one of the new features not having working checkpointing while that feature is running. Checkpointing still works for workunits that don't use that feature.

I was reading the 2.03 thread and saw something about the checkpoint issue, which i saw with myself just now thats why I thought I would point it out. Your saying everything is fine even though the model says its starting from 1 again correct? Thanks for the help!

New app working well. And it seems that now the WU need less RAM (about 100 MB per WU). Is it true? If it is, then may be this is a step to rosetta's GPU client? :-)

I too notice that version 2.05 uses less RAM, and not only on tasks *gbn*. Somewhere 200-250 MB instead of 300-350 in version 2.03.
Is it one of "and other minor updates" about which is written in "Version Release Log"?
If so it seems to me not absolutely "minor" :)

I noticed such thing in the new version (though it can feature of the concrete WU - this type of WU in version 2.03 did not come across to me). At model calculation at first steps go very fast, for example 36000 steps have been calculated all for 6 minutes after that calculation has gone very slowly and following 10 steps have occupied more than 10 minutes.
And it is conceived?
Task example: job_boinc_1bm8__broker_random_pairings_from_psipred_16 906_1305_1

Please don't presume that the information from the Project Team is an inaccurate description and that your memory observations are a new and permanent condition for all to enjoy going forward. As Sarel points out, they introduced a new type of work unit which has a new low-memory phase to execution. And so you are only going to see the lower memory usage when that specific type of task is being worked on. And this new type of work unit was introduced in prior versions, so the actual delta to v2.05 is small. Since this new type of work is a current area of review, you may see a high concentration of this type of work for a period of time. But it doesn't mean we can presume more then was stated.

---

Rosetta Moderator: Mod.Sense