all charmm34a26.23 with mod0013b
seem to be bad
Don’t matter if it is 1liiq_43 / 44 or 1hvk
again from what I can tell if it has mod0013b in it… it’s bad.
Will not finish, yet judge for yourself and keep us all informed on your analysis.
Just found this: http://docking.cis.udel.edu/community/forum/thread.php?id=460&nowrap=true#5744
Some mod0013b are good, but very few. You just have to check the properties of each WU. if file size is 0.00, the abort. Yet how many of use have the time to check each on. I am just setting for no new tasks till this issue is resolved.
Seems it depended when you got it - I just checked my work units and only had one that was a '0 byte file - that I aborted since it had been started yet - otherwise mine are going through. I will keep an eye on it
I have a lot of 13b units not one so far has been bad, so maybe this problem is not as widespread as we think
I’ve binned almost 50 of them. The last lot to download I ran each one for just under a minute before they clicked over showing they were working. The previous lot hadn’t moved after 2-3 minutes so were dumped. Three rigs were affected so all-in-all I’ve lost well over 30hrs of work. Still checking to see if there are duds in the mixture. :furious:
Update: Another 17 duds to the bin and the other 35 have checked out OK :xfinger:
Only had to bin 8 of them after about 3 hours processing on each, plus 7 subsequent failures @ 3 minutes each , all of them on my Linux boxes - this thread gave me the heads up - also coincided with the server glitch so no more duff ones downloaded- binned them and got a shed load more, only 24 hours processing lost