does this mean we need to crunch WUs till number 2800000+, or the final number is now let's say 2700000 WUs ?

why do we increase it to 20% then ? to provide better docking results on the last 10% of WUs? :)

SekeRob,

You are correct. They are maxed out at 255 runs per workunit. When I asked armstrdj to increase the runtimes by 20% I forgot about the max runs. Long story short, please disregard the message about 20% increase in runtime.

Rilan,

There are still 286,000+ work units given to us by the researchers. We split them into smaller chunks. When we increase the runtime of a project, it usually means less work units (sent to members) to do the same amount of work. But the CPU time used for an entire batch would be about the same.

Thanks,
-Uplinger

According to uplinger we are to disregard the 20% increase in run times.Thus I think we are running into some "harder" molecules. I am seeing a few WU's running very long, 50+ hours on my slow machines where the "normal is between 15 and 24 hours. On the faster machines I am seeing some 20+ hours versus less than 8 hours of the "normal" units. Having them run this long doesn't bother me, but it does throw the DCF out of whack for a while. These would be on machines which I only connect to the internet every two or three days, so I try to maintain a three day cache. So far it has not gotten too far out of whack to cause any missed deadlines, but it does have an effect on how may jobs are queued. I was wondering if anyone else has observed these "heavy duty" jobs.
Cheers

As was noted, the extension was *not* applied to HFCC work units [not possible in fact]. There is though variability in the time it takes for different compounds to complete all the dockings, there's always been throughout the project. The average run time is though very constant, as can be seen in this chart: http://bit.ly/WCGHFC [light blue line near bottom].