| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Active Research
Forum: OpenPandemics - COVID-19 Project
Thread: Invalid GPU work units |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 171
|
|
| Author |
|
|
Grumpy Swede
Master Cruncher Svíþjóð Joined: Apr 10, 2020 Post Count: 2207 Status: Offline Project Badges: 
|
That is not true. As long as you are logged in to WCG, you can open those links.
----------------------------------------This result of mine for example, can be opened by everyone who is logged in: https://www.worldcommunitygrid.org/ms/device/...og.do?resultId=1641460226 And this Workunit Status link can also be opened by everyone who is logged in: https://www.worldcommunitygrid.org/ms/device/...s.do?workunitId=628019356 There's nothing secret, or private data contained in those result and status pages. Nobody logged in will be blocked from those pages, as long as they are still in the database, and not purged. [Edit 2 times, last edit by Grumpy Swede at Apr 20, 2021 5:02:45 AM] |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges: 
|
Good morning,
I started looking into the additional invalids. It appears that the flexible residue that is used in batches between 3337 and 4448 have a similar problem that the previous batches listed have. I have suspended those and I'm working with the researchers to make sure that batches beyond 4448 don't have the same issue. Basically think of it this way...you put all the target and ligand into a box of water. This keeps the constraints on search area smaller. However, it looks like the flexible residue is placed on the edge of this box, but it is not 100% in the box...So...it causes invalid results. Which is good that the validation is catching those, it is bad that they are being processed on volunteer computers. As of now, I have suspended all trouble work units that were not loaded onto the grid and I'm working to catch those that come back into error/rerun state and suspending them from going out additionally. Thanks, -Uplinger |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
Ok, I got confirmation from the researchers that they are going to add a check when building batches for us to prevent this from happening on new batches they provide to us. They have also confirmed that batches beyond 4448 are safe and do not show issues like the bad batches.
Thanks, -Uplinger |
||
|
|
pututu
Senior Cruncher United States Joined: Jan 3, 2016 Post Count: 241 Status: Offline Project Badges: 
|
Thanks for the update!
---------------------------------------- |
||
|
|
nanoprobe
Master Cruncher Classified Joined: Aug 29, 2008 Post Count: 2998 Status: Offline Project Badges: 
|
Ok, I got confirmation from the researchers that they are going to add a check when building batches for us to prevent this from happening on new batches they provide to us. They have also confirmed that batches beyond 4448 are safe and do not show issues like the bad batches. Thanks, -Uplinger Thanks Keith. Will there be any credit given for the invalid tasks?
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.
  |
||
|
|
Grumpy Swede
Master Cruncher Svíþjóð Joined: Apr 10, 2020 Post Count: 2207 Status: Offline Project Badges:
|
Thanks Uplinger for the explanation.
I will now turn on my stone age GPU crunchers.  |
||
|
|
Grumpy Swede
Master Cruncher Svíþjóð Joined: Apr 10, 2020 Post Count: 2207 Status: Offline Project Badges:
|
Good morning, I started looking into the additional invalids. It appears that the flexible residue that is used in batches between 3337 and 4448 have a similar problem that the previous batches listed have. I have suspended those and I'm working with the researchers to make sure that batches beyond 4448 don't have the same issue. Basically think of it this way...you put all the target and ligand into a box of water. This keeps the constraints on search area smaller. However, it looks like the flexible residue is placed on the edge of this box, but it is not 100% in the box...So...it causes invalid results. Which is good that the validation is catching those, it is bad that they are being processed on volunteer computers. As of now, I have suspended all trouble work units that were not loaded onto the grid and I'm working to catch those that come back into error/rerun state and suspending them from going out additionally. Thanks, -Uplinger I have a question about this though. If the researchers are interested in these targets and ligands, why not increase the size of the search box/box of water, to make these batches run without producing invalid results? We do have as it seems more than enough GPU power available to handle much more than we are doing now. [Edit 1 times, last edit by Grumpy Swede at Apr 20, 2021 4:30:56 PM] |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
Ok, I got confirmation from the researchers that they are going to add a check when building batches for us to prevent this from happening on new batches they provide to us. They have also confirmed that batches beyond 4448 are safe and do not show issues like the bad batches. Thanks, -Uplinger Thanks Keith. Will there be any credit given for the invalid tasks? You should get granted credit for invalid work. I have seen those reporting they are getting like 100 points for GPU. This is normal, because it is not getting good values, the individual jobs are stopping really quickly on the machines. It looks like they are getting about 5% of the total possible points. Currently the total possible points for a GPU work unit is around 1600 points granted. I'm going to sift through some logs to make sure my statement is 100% accurate, but i'm like 98% sure it is. Thanks, -Uplinger |
||
|
|
Grumpy Swede
Master Cruncher Svíþjóð Joined: Apr 10, 2020 Post Count: 2207 Status: Offline Project Badges:
|
There's no credit granted at all for invalid work. Not that it matters much, if this "invalid" issue stops now.
----------------------------------------Example: https://www.worldcommunitygrid.org/ms/device/...s.do?workunitId=628436521 Edit: Some WU's though produces a mix of "invalid" and "valid" results, and in those cases the valid results are given credit, but the invalid results are not. [Edit 2 times, last edit by Grumpy Swede at Apr 20, 2021 4:37:09 PM] |
||
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges:
|
There is a hint of a silver lining to having it send only 2000 work units every 30 minutes. We do not have a backlog of results for me to abort and stopping things. I would imagine there may be a few resends (due to entire workunit being marked in error), but I'm manually catching those and envision 99% of them will be stopped before end of day.
To give a bit of understanding on resends. We send out say 2 copies with a max of say 5 total that can go out due to errors, invalids, abandoned, aborted, time out, etc. Once the work unit gets to error state, we automatically reschedule it to clean up and send it out again. This is due to the fact that when you send out millions of results per day, there is a chance a work unit will get unlucky and get multiple hosts that have issues. This automatic resend allows the work unit to get a fresh start and possibly be sent to another plan class of hosts. Preventing these resends is the manual task I have mentioned before. Note: a resend for a single work unit is only attempted once, if it errors a second time, we save logs and result flies so we can examine the issue in more detail. Thanks, -Uplinger |
||
|
|
|