one of my machines produces validate errors - what could be the problem ? the only other project is GPUgrid running

Assuming this wasn't the case before the update:
It's not you, we've been getting lots of validate errors since the version update to 3.62.
GPUGrid, or any other project for that matter, wouldn't cause such errors.

---

If you get any type of errors on your task:

Step 1: Add a quick note on the type of error and the task id number in the Minirosetta 3.62 thread. That will help the scientists to investigate the problem and hopefully speed up finding a solution.

Step 2: Check the work unit details for the invalid task. If one user gets an error the task is sent out to another user to try again. If both users had an error then it is safe to say there is a problem with the work unit. If the other user was successful when you failed then that could suggest a problem with your machine (though I would only make that assumption after several errors that turned out successfully on other machines - one error may just be an isolated glitch).

One of your recent errors was on task 756849504 and checking the associated work unit, 685776063, shows that the second user also had an error. In this case it is safe to assume the problem is with the task and not your computer.


One important point to remember with validate errors is that it is possible for 99% of your data to be useable by the scientists. The system will report a validate error if the final decoy information doesn't come back correctly. In this task you submitted 1,261 decoys so it is possible that 1,260 of them came out fine (unfortunately there is no way for us to tell on the user side whether the data we submit is usable solely on the error message).

One of your recent errors was on task 756849504 and checking the associated work unit, 685776063, shows that the second user also had an error. In this case it is safe to assume the problem is with the task and not your computer.

This in a "FFD*" task, they all end with validate errors. All his validate errors are from those work units, so no problem on his end.

---

.

One of your recent errors was on task 756849504 and checking the associated work unit, 685776063, shows that the second user also had an error. In this case it is safe to assume the problem is with the task and not your computer.

This in a "FFD*" task, they all end with validate errors. All his validate errors are from those work units, so no problem on his end.

My advice explains what to do when validate errors occur in the future and I also pointed out the current issue is not with their machine. I don't see what was wrong with my reply...

Nothing wrong with your reply, just added a link to the thread about those tasks, actually as a hint for the OP to check at least few most recent threads for known problems, that way it's often possible to get an answer faster than by starting a new thread.

---

.

Not even got this small problem sorted yet?

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

Shooooot! Thanks for the report, we're working on canceling the jobs and fixing the bug.

Not even got this small problem sorted yet?

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

Last night I got 3 validate error

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

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

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

I hope it helps to find solution.

---

Seti@home Classic account User ID 955 member since 8 Sep 1999 classic CPU time 539,770 hours

Task 768264227 gave Validate Error.

6H_TUBE8_AB_6H_TUBE_07.pdb_15_10_12_32_13_globalDocking_1_SAVE_ALL_OUT_309429_46_0

rb_12_07_59935_105598_ab_stage0_t000___robetta_IGNORE_THE_REST_12_12_313657_76_0

99 decoys generated (i think that's where all WUs stop), first delivery, no restarts, outcome "invalid"

:-(

rb_12_07_59935_105598_ab_stage0_t000___robetta_IGNORE_THE_REST_12_12_313657_76_0

99 decoys generated (i think that's where all WUs stop), first delivery, no restarts, outcome "invalid"

:-(

Was still counted towards science and towards your points total, if you scroll to the bottom of the page you linked to you'll see this:

Claimed credit 142.733357277178
Granted credit 142.733357277178

It has the WU state "cancelled" now, one more from the same series has the same outcome and it is cancelled too.

The credits have been granted later on that first one, I guess someone checked the problem and granted manually (thanks for that!), as the new one still shows 0 granted.

App version: Rosetta Mini 3.67

I'm still getting some validate errors from two different i7.

These 24 hours of computing have 0 granted credit... why???
https://boinc.bakerlab.org/rosetta/result.php?resultid=777361677
https://boinc.bakerlab.org/rosetta/result.php?resultid=777391503

App version: Rosetta Mini 3.67

I'm still getting some validate errors from two different i7.

These 24 hours of computing have 0 granted credit... why???
https://boinc.bakerlab.org/rosetta/result.php?resultid=777361677
https://boinc.bakerlab.org/rosetta/result.php?resultid=777391503

Both of those WUs came from jobs that got cancelled by the researcher (see here and here - note the 'errors' field shows the job was cancelled) after your received the WU in your queue. Generally if you wait a couple of days the claimed credit will be granted on a future sweep of the validator program.

Situations like this are why David has been looking at tightening up the required 'average TAT' for some jobs. It doesn't appear to me that the BOINC client/server supports any kind of 'remote kill switch' for a given WU once it's been downloaded, so there's no way to prevent said WUs from needlessly running after queued if the job they belong to gets cancelled.

Personally, to improve my average turn around time for my boxes and thus increase the chance that the crunching I'm doing is actually going to contribute to someone's query results, I've actually tightened my queue settings (I basically don't queue any tasks) and my target runtime is a more modest 8 hours.

Both of those WUs came from jobs that got cancelled by the researcher (see here and here - note the 'errors' field shows the job was cancelled) after your received the WU in your queue. Generally if you wait a couple of days the claimed credit will be granted on a future sweep of the validator program.

Ok! I thought granted credit was immediately equal to claimed credit when a WU failed and the only credit counter was updated after a couple of days. Glad to know I was wrong.

Situations like this are why David has been looking at tightening up the required 'average TAT' for some jobs. It doesn't appear to me that the BOINC client/server supports any kind of 'remote kill switch' for a given WU once it's been downloaded, so there's no way to prevent said WUs from needlessly running after queued if the job they belong to gets cancelled

I've seen many times workunits to get "cancelled by server" when are no longer needed or for other reasons.

Personally, to improve my average turn around time for my boxes and thus increase the chance that the crunching I'm doing is actually going to contribute to someone's query results, I've actually tightened my queue settings (I basically don't queue any tasks) and my target runtime is a more modest 8 hours.

I usually run default WUs. I was doing some tests and my queue's settings were "min/max reserve of work" = "0.5/0.6 days".

Both of those WUs came from jobs that got cancelled by the researcher (see here and here - note the 'errors' field shows the job was cancelled) after your received the WU in your queue. Generally if you wait a couple of days the claimed credit will be granted on a future sweep of the validator program.

Ok! I thought granted credit was immediately equal to claimed credit when a WU failed and the only credit counter was updated after a couple of days. Glad to know I was wrong.

And credited already. It seems to be an overnight job that mops up validate errors, so usually within 24hrs. It is disconcerting, I agree

---