That's excellent news - thanks to everyone concerned

Wonder how the approach on this will be if opted in to run in full, just with the normal 10x current average FPOPS header runtime cutoff:

1. ..., wingman assignment will have to do too?
2. ..., pair with wingman that does at least the first 3 critical jobs to get a reasonable validation?
3. ..., stroke of luck wingman pairing continues.

--//--

Rather counter intuitive for the DCF increase to lead to shorter runtime permitted.

Yes, but the limits was present long before DCF was introduced, so any estimates and therefore any cut-off was only based on the benchmark.

While DCF will give more or less "correct" estimated cpu-time, it was probably decided to not also adjust the cut-off-limit. Some projects has initially grossly over-estimated the run-time, something that can give DCF less than 0.01, and then the estimates is adjusted, a cut-off including DCF of 0.01 would mean all tasks with new estimate will error-out.
Similarly, some projects can have tasks terminating early (example LHC@home), and with a string of such tasks in a row the DCF can also become very low and this would give the same result with all later work being terminated...

So, more accurately the table would be:
1: Benchmark says 6 hours cpu-time, meaning 120 hours cut-off or 5 days.
2: Benchmark says 8 hours cpu-time, meaning 160 hours cut-off or 6.67 days.
3: Benchmark says 12 hours cpu-time, meaning 240 hours cut-off or 10 days.

That WCG's estimates is so far off that for #1 the DCF is 2.0 and for #2 the DCF is 1.5 don't have any effects on the cut-off.

WCG being off with more than 2 isn't so uncommon, a quick look reveals had a CMD2 earlier today that bumped DCF to 2.499, while a CEP2 was at 0.601...

Hi Jack007,
Two comments: 1) HT is not the same as a physical core and is for various reasons much less efficient; 2) If you run 8 CEP2 wus simultaneously, your hd may be the bottleneck (another indication for this is if your wall-clock and cpu time are very different).
We recommend reducing the number of CEP2 wus to maybe 4 in the profile and fill up the rest with another project which is less demanding.

Hi SekeRob,
The wingman will not be affected by this - validation will be performed on an early stage. In addition we hope to get rid of the wingman-validation in 2-3 months completely.

Hi skgiven,
It is not quite that easy. After job 3 we have a first impression of a system but we cannot say anything ‘safely’. But the more data we have on it, the more solid this impression gets. The wus are also designed to give the later jobs in a very efficient manner (it’s called a projection or boot-strapping scheme). But there is a trade-off of more detailed results on fewer molecules vs less detailed ones on more molecules. In the grand scheme of things it does not make a big difference for us. There are pros and cons for having longer vs shorter runs and they balance out in the end as long as we have a decent mix. The way we designed our wus gives them a wide window in which different contributions are useful. We want to give people the choice and hope that motivates them to donate more time to CEP2 – that’s what really counts.

Hi dkt,
We don't want to make promises we cannot keep, but I expect that we talk about weeks rather than months.

Best wishes to you all

Your Harvard CEP team