| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Drug Search for Leishmaniasis Forum
Thread: Batch 40 all (?) erroring - Unable to update graphics data. Application exited with RC = 0x1 |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 21
|
|
| Author |
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges: 
|
nano, I need to clear out the work units first. Target 40 will basically be put on the back burner until we can fix the issue. It is basically a configuration issue in the build script. It got told to look for file ./3P01.pdbqt instead of target_00000040.pdbqt. Thus the issue.
Thanks for your patience, -Uplinger |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
ca05065,
The short answer is no. I need to get back to clearing out the work units to get this project running again. 195 means an exit code (any exit code other than 0) came from the vina application called from the wrapper. Thanks, -Uplinger |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
Greetings all,
The transitioner is attempting to clear all the workunits. It will take some time since there were 60+k workunits loaded into boinc. Once it clears these out, it will move onto putting target 41 into the feeder. I think at the pace this is going it could be 30 minutes (JUST AN ESTIMATE) before workunits will begin to flow again for DSFL. These workunits will be from target 41. Thank you for your patience, -Uplinger |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges: 
|
Thanks for the update and fixing this!
Much appreciated to get some updates for the project, not like the "sound of silence" when there is an issue at R@H... Ralf |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
Hello again,
DSFL has been started up again. I have downloaded a workunit for target 41 and they appear to be working properly. Thanks again, -Uplinger |
||
|
|
nanoprobe
Master Cruncher Classified Joined: Aug 29, 2008 Post Count: 2998 Status: Offline Project Badges: 
|
Hello again, DSFL has been started up again. I have downloaded a workunit for target 41 and they appear to be working properly. Thanks again, -Uplinger Thanks for the update and for such a quick resolution to the problem.
In 1969 I took an oath to defend and protect the U S Constitution against all enemies, both foreign and Domestic. There was no expiration date.
  |
||
|
|
jerseywindowfactory_dot_com
Advanced Cruncher Joined: Aug 29, 2009 Post Count: 84 Status: Offline |
Another reason I like to keep my cache size relatively small....
---------------------------------------- |
||
|
|
martin64
Senior Cruncher Germany Joined: May 11, 2009 Post Count: 445 Status: Offline Project Badges: 
|
Another reason I like to keep my cache size relatively small.... Not sure whether I understand this. If someone has selected DSFL as the only project, and had a small cache, BOINC will quickly have loaded and finished enough erroneous WUs to get locked out due to quota limits. If someone had a large cache, he would still be crunching the "good" WUs from the last batch at the time the error is fixed. The WUs with problems will be server aborted even before they start to run. So I think the opposite is right: a large cache can help someone to avoid running into these types if problems. Regards, Martin  |
||
|
|
gb009761
Master Cruncher Scotland Joined: Apr 6, 2005 Post Count: 3010 Status: Offline Project Badges: 
|
Another reason I like to keep my cache size relatively small.... Not sure whether I understand this. If someone has selected DSFL as the only project, and had a small cache, BOINC will quickly have loaded and finished enough erroneous WUs to get locked out due to quota limits. If someone had a large cache, he would still be crunching the "good" WUs from the last batch at the time the error is fixed. The WUs with problems will be server aborted even before they start to run. So I think the opposite is right: a large cache can help someone to avoid running into these types if problems. Regards, Martin I agree with you Martin. Whenever I'm crunching just 1 project, I've always got a smallish cache of 1.5-2 days, so that if an issue like this surfaces, then the techs can get notified, have a chance to resolve the issue and then server abort the affected WU's before I start crunching/erroring out on them (which, would simply pass the issue onto someone else).  |
||
|
|
yoro42
Ace Cruncher United States Joined: Feb 19, 2011 Post Count: 8979 Status: Offline Project Badges:
|
More of the same...
----------------------------------------DSFL_ 00000040_ 0000001_ 0291_ 3-- JAMAL Server Aborted 10/22/11 21:42:15 10/23/11 17:42:23 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000001_ 0291_ 4-- 619 Error 10/22/11 21:44:07 10/23/11 00:00:14 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000001_ 0291_ 3-- 619 Server Aborted 10/22/11 21:42:15 10/23/11 17:42:23 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000001_ 0291_ 2-- 619 Error 10/22/11 20:10:40 10/22/11 21:43:42 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000001_ 0291_ 1-- 619 Error 10/22/11 14:18:18 10/22/11 21:41:13 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000001_ 0291_ 0-- 619 Error 10/22/11 14:18:10 10/22/11 20:09:49 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 2-- JAMAL Server Aborted 10/22/11 15:22:38 10/23/11 17:42:23 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 4-- 619 Error 10/22/11 22:38:44 10/23/11 00:51:48 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 3-- 619 Error 10/22/11 15:24:33 10/22/11 22:38:07 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 2-- 619 Server Aborted 10/22/11 15:22:38 10/23/11 17:42:23 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 1-- 619 Error 10/22/11 15:21:10 10/22/11 15:21:27 0.00 0.0 / 0.0 DSFL_ 00000040_ 0000003_ 0521_ 0-- 619 Error 10/22/11 15:21:03 10/22/11 15:22:15 0.00 0.0 / 0.0  |
||
|
|
|