BAD ERROR! Boinc 5.4.9 crunching WU t283__CASP7_ABRELAX_SAVE_ALL_OUT_hom024__528_13504_0, screensaver appeared.. suddenly windows error message appeared about Rosetta@home doing illegal operation and windows had to end this process.. "send report to microsoft? [send] [don't send]" you probably know that message.. after closing the message: boinc happily crunches another WU.. now it looks like it was normal computing error .. but it wasn't ..

I was seeing those in Ralph on one computer, but not the others. I turned off the screensaver and haven't see it again. I reported this in Ralph.

WU: JUMP_RELAX_ALLBARCODE_t285__SAVE_ALL_OUT_530_2909_0
result: https://boinc.bakerlab.org/rosetta/result.php?resultid=21309179

This WU looks like it finished normally with no problem, but while it was crunching I looked at the stdout.txt file and it was 74,807,795 Bytes. It was mostly filled with lines like:

...
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
...

And so on. On rare occasion there would be a line like:

scored_frag_close( 80 91 100 240 ) cycle= 100 total-closed-frags: 11 0.00487611 -61.1343

thrown in. After great stretches of this there would be some normal looking stuff, then there would be another great stretch of "move not allowed" messages.

WU: JUMP_RELAX_ALLBARCODE_t285__SAVE_ALL_OUT_530_2909_0
result: https://boinc.bakerlab.org/rosetta/result.php?resultid=21309179

This WU looks like it finished normally with no problem, but while it was crunching I looked at the stdout.txt file and it was 74,807,795 Bytes. It was mostly filled with lines like:

...
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
...

And so on. On rare occasion there would be a line like:

scored_frag_close( 80 91 100 240 ) cycle= 100 total-closed-frags: 11 0.00487611 -61.1343

thrown in. After great stretches of this there would be some normal looking stuff, then there would be another great stretch of "move not allowed" messages.

thanks! this will be easy to track down and fix

---

https://boinc.bakerlab.org/rosetta/result.php?resultid=21413607

Maximum disk usage exceeded

Anders n

---

--sorry my mistake

---

I've just finished, 5 minutes ago, and uploaded task t283__CASP7_ABRELAX_SAVE_ALL_OUT_hom008__528_3596_0 . But I can't seem to find that work unit in my stats, nor credits are awarded ?? What happened??

The work unit did complete succesfully.

My computer ID is: 76755

The total uploaded batch was:
24/05/2006 20:10:49|rosetta@home|Started upload of file v287__CASP7_ABRELAX_SAVE_ALL_OUT_cterm__527_6789_0_0

24/05/2006 20:10:49|rosetta@home|Started upload of file v287__CASP7_ABRELAX_SAVE_ALL_OUT_cterm__527_6790_0_0

24/05/2006 20:10:54|rosetta@home|Started upload of file t287__CASP7_ABRELAX_SAVE_ALL_OUT_hom001__527_6789_0_0

24/05/2006 20:10:54|rosetta@home|Started upload of file t283__CASP7_ABRELAX_SAVE_ALL_OUT_hom008__528_3596_0_0

Once the work unit is complete, it is uploaded back to the servers. That unit then becomes "ready to report". It is not uncommon for BOINC (on your PC) to not report right away and actually accumulate several results to "report" back. This could take several hours.
Once reported the work unit goes through several steps before it actually shows up as complete in your stats. If they are working on any of the servers and have one of the components down, that could also influence when you actually get the credit.
I have never seen a work unit actually "lost" but I have heard of it a LONG LONG time ago, and I would not be afraid of that. Just be patient, you will get the credit due you.

---

https://boinc.bakerlab.org/rosetta/result.php?resultid=21413607

Maximum disk usage exceeded

Anders n

When I reported this error, it was because I had a question over how 100% Rosetta , use no more than 50% of the HD, leave at least 100 Megs of HD space would equal 100,000,000 bytes on a roughly 30 gig partition with roughly 8.5 gigs free.
It was suggested that like AMD_is_logical, my error report had grown incredibly large (in my case to over 100,000,000 bytes) and tripped this error.

Would the programmers please give the error report growing larger than 100,000,000 bytes - its own error message? Perhaps grabbing the first million characters and last million characters of the file.. so the project can see what WUs are having more problems, and what those problems are?
In my case, it was on hour 23 of my 24 hour per WU setting - so it probably isn't an error that will be seen that often. i.e. they need a cpu that cranks out models as fast or faster than mine; need a 12-24 hour per WU setting, and a WU that spits out errors right and left, like the one AMD_is_logical and Anders n are reporting.

---

WU: JUMP_RELAX_ALLBARCODE_t285__SAVE_ALL_OUT_530_2909_0
result: https://boinc.bakerlab.org/rosetta/result.php?resultid=21309179

This WU looks like it finished normally with no problem, but while it was crunching I looked at the stdout.txt file and it was 74,807,795 Bytes. It was mostly filled with lines like:

...
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
...

And so on. On rare occasion there would be a line like:

scored_frag_close( 80 91 100 240 ) cycle= 100 total-closed-frags: 11 0.00487611 -61.1343

thrown in. After great stretches of this there would be some normal looking stuff, then there would be another great stretch of "move not allowed" messages.

I had the same phenomenon with this WU.

https://boinc.bakerlab.org/rosetta/result.php?resultid=21390555

---

Thanks for posting about this big file. I'm fixing this now for the new app --
I thought those print statments would not normally get triggered, but this CASP target has found a way! I'll also see if I can find a way to turn it off for
the current app and resend the workunits.

WU: JUMP_RELAX_ALLBARCODE_t285__SAVE_ALL_OUT_530_2909_0
result: https://boinc.bakerlab.org/rosetta/result.php?resultid=21309179

This WU looks like it finished normally with no problem, but while it was crunching I looked at the stdout.txt file and it was 74,807,795 Bytes. It was mostly filled with lines like:

...
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
set_phi:: move not allowed: 88
set_psi:: move not allowed: 88
set_omega:: move not allowed: 88
...

And so on. On rare occasion there would be a line like:

scored_frag_close( 80 91 100 240 ) cycle= 100 total-closed-frags: 11 0.00487611 -61.1343

thrown in. After great stretches of this there would be some normal looking stuff, then there would be another great stretch of "move not allowed" messages.

I had the same phenomenon with this WU.

https://boinc.bakerlab.org/rosetta/result.php?resultid=21390555

---

A short message about one workunit. It is completing
successfully on all clients. But one some
Windows machines, it appears to be grabbing and
excessive amount of memory as the workunit progresses.
If your computer is crunching a workunit
with the following name, please abort it, just in case:

t283__CASP7_MAPRELAX_...

We have canceled these jobs for now. Incidentally,
not too many of these work units have been sent
out, maybe 1000 out of the 100,000 in progress --
but we want to make sure there are no problems during CASP7.

Thanks! The TeraFLOPS estimate has exceeded 30 TFlops
thanks to your efforts and a record low error rate!

If I've got one running on a system here, but can afford the memory to keep it going, should I let it run to completion? Also, I've got another one queued on one of my Linux systems. Should I let that one run as well?

---

2 successive application crashes, look like memory errors. Gave the machine a reboot and it seems ok again. WUs:

17905138
17921169

Linux is fine -- keep it going, please! I'd recommend aborting the Windows one, just in case.

A short message about one workunit. It is completing
successfully on all clients. But one some
Windows machines, it appears to be grabbing and
excessive amount of memory as the workunit progresses.
If your computer is crunching a workunit
with the following name, please abort it, just in case:

t283__CASP7_MAPRELAX_...

We have canceled these jobs for now. Incidentally,
not too many of these work units have been sent
out, maybe 1000 out of the 100,000 in progress --
but we want to make sure there are no problems during CASP7.

Thanks! The TeraFLOPS estimate has exceeded 30 TFlops
thanks to your efforts and a record low error rate!

If I've got one running on a system here, but can afford the memory to keep it going, should I let it run to completion? Also, I've got another one queued on one of my Linux systems. Should I let that one run as well?

---

Jimi, if you happen to be running something
beside rosetta@home, have you noticed application crashes with other
BOINC apps that have graphics?

2 successive application crashes, look like memory errors. Gave the machine a reboot and it seems ok again. WUs:

17905138
17921169

---

Rhiju, I've had those fatal windows errors with both 5.12 and 5.16 on this machine. All errors stopped when I turned off the screensaver. See project list in Signature. No other project has caused this fatal windows error when the screensaver was running. (note: some don't have a screensaver, and the ones will zero RAC, I haven't run in a while)

hope this helps

tony

---

This may be coincidence, but I just downloaded the most recent BOINC Client and all my numbers are dropping. Work per day is about 1/2 of what it was before the new client. This is true on MacX and Intel P4 systems. Is it just me?

What version of BOINC did you install?

Sorry, Client is 5.4.9 all both systems. One thing I noticed and changed after I noticed the slow down and it appears to help the Intel boxes. I turned off the screen saver. At least 2 Intel boxes were hanging on the screensaver (no Rosetta progress while screensaver was active). On both these boxes, BOINC & Rosetta has consistently run better without the screensaver mode. The new install defaulted to turning on the screensaver. numbers have been improving since this change.

---

This may be coincidence, but I just downloaded the most recent BOINC Client and all my numbers are dropping. Work per day is about 1/2 of what it was before the new client. This is true on MacX and Intel P4 systems. Is it just me?

What version of BOINC did you install?

Sorry, Client is 5.4.9 all both systems. One thing I noticed and changed after I noticed the slow down and it appears to help the Intel boxes. I turned off the screen saver. At least 2 Intel boxes were hanging on the screensaver (no Rosetta progress while screensaver was active). On both these boxes, BOINC & Rosetta has consistently run better without the screensaver mode. The new install defaulted to turning on the screensaver. numbers have been improving since this change.

I have sent an e-mail to David Kim concerning the screen saver issue. He will be working specifically on this issue until it is fixed. He may post additional questions here to all of you on this point soon.

---

Moderator9
ROSETTA@home FAQ
Moderator Contact

This computer Result ID Work unit ID

Rosetta version 5.16
BOINC version 5.4.9
OS WinXP home service pack 2

error msg:

25/05/2006 1:36:40 PM|rosetta@home|Aborting task JUMP_ALLBARCODE_t285__SAVE_ALL_OUT_530_9568_1: exceeded disk limit: 103510443.000000 > 100000000.000000
25/05/2006 1:36:40 PM|rosetta@home|Unrecoverable error for result JUMP_ALLBARCODE_t285__SAVE_ALL_OUT_530_9568_1 (Maximum disk usage exceeded)


edit: to add more info

---

Client errors here 17525724

and here 17359315


Screen saver never runs on this computer. It has run many successful work units before and after these errors.

---

Sorry Rhiju, just saw this. Rosetta is the only BOINC program on the machine and crunching is all it does at the moment. It looks like memory instability; I lost 4 units in quick succession this morning but a reboot seems to have fixed it.

WUs were:

17959274
17975623
17976020
17981072

I've had trouble with this RAM before and managed to tweak it back into life, it seems to be going sour again. Crucial Ballistix DDR500 2x1GB, it tends to do this kind of thing. :(

Jimi, if you happen to be running something
beside rosetta@home, have you noticed application crashes with other
BOINC apps that have graphics?

2 successive application crashes, look like memory errors. Gave the machine a reboot and it seems ok again. WUs:

17905138
17921169

My bad: found the missing WUs, they have low ID numbers.

Still got this weird imbalance between CPU usage though - on a dual-core, instead of 50:50 it's 97:3 (as in one WU using 97% of both cores).

On other machines, RAM usage is 100MB or 235MB. This WU grabbing all the CPU is using 770MB! Is that some kind of doomsday machine? This is it -

https://boinc.bakerlab.org/rosetta/workunit.php?wuid=17193170