This is correct. My PC has 12 cores, 24 hyperthreads. I had been running 12 threads of WCG because they get allocated 1 to each physical core and the cores then turbo-boost (inbuilt automatic overclocking) and crunch very fast. It also leaves 12 hyperthreads free to do my work on the computer without noticing any performance decrease.

However, this left me running out of OET WU a lot of the time so I changed it to 24 threads of WCG,so 2 per physical core at which point there is no longer any turbo-boost and they crunch at a more sedate pace. The overall number of WU processed is pretty similar (I think about 10% more with the 24 threads), the crucial difference was that I was no longer running out of OET WU as often because I was being sent a lot more.

It hadn't occurred to me before, but now I realised that the badges come twice as fast this way, so I could have got 10 years of MCM in the time I notched up 5. The logical extension to this is to do as little work as possible in as long a time as possible if you want to get diamond badges easily. Putting it another way, the badges should really be awarded for points earned, not for elapsed CPU time, to reflect actual contributions made to science.

it is not cheating. it is the way how to get more work

changing CPU count is not cheating?

You'll have to help me out then, because I don't understand - it looks simple enough on this chart where I varied the number of WCG threads (all UGM threads at the moment). The heavy line is Total MHz, the other lines are all %CPU per thread, except the almost invisible aggregate %CPU which is flat lining at 100% whenever 12+ threads are crunching. The ~10% step between the 24 threads and 12 threads is pretty clear, the 18 threads splits the difference as you would expect.

However, it also seems that full turbo-boost is required for any thread to hit 100% CPU since the moment 12+ threads are crunching none of them get there. There's an apparent inverse relationship between the number of CPU-bound threads and the maximum %CPU such that by the time all 24 hyperthreads are crunching, there's almost no variability and they appear to average about 55%. Thus I surmised that the turbo-boosting is decreased as the use of second hyperthread per core increases, presumably to remain within the thermal dissipation limit.

From BOINC's perspective in terms of accounting for CPU time it appears that anything >= 55% looks like 100%, so running 12 threads for 24 hours will add 12 days to the stats, whereas running 24 threads for 24 hours will add 24 days to the stats but only do 10% more work!

As a scientist myself I predict no more work for a few months at least. If the guy they hired only starts in Feb, I can't imagine them coming up with testable models immediately. And honestly, you want them to take their time and put out models with the highest probability of success. It's possible that they underestimated how quickly that the grid would burn through the first project. OR it was necessary for their plans to get early demonstration of successful grid-based science to get collaborators and financial backers on board. This is just the way things work and not a mistake or an attempt to mislead people.

Don't forget there are 2 parts to the initial OET work.

1) The rather small set that was processed in 'Rigid' mode, the 560K results we've done
2) The held back 'Flex' mode tasks that run very long, depending on speed of device over 48 hours and -do not- checkpoint. This is magnitudes larger amount of work compared to 1.

The latter is what the technicians are working on [zero info guess], to modify the AD VINA program so that checkpoints are taken in reasonable intervals. This intermediate checkpointing in a single docking run is novel and daunting, to achieve a model restore after resume without upsetting a single bit.