Preparing S5R4 - No new Apps for S5R3

I guess im not the only one who want to know this: When will the first S5R4 WUs reach our computers?

According to internal statistics the last Workunits of S5R3 will be generated in the first days of August.

In particular this means that the development of the Einstein@home Applications will now focus on what is needed for S5R4, there will probably be no more new Apps for S5R3.

We're discussing measurements to average out the runtime differences visible in the current workunits in the workunits by splitting the sky among them differently from the way we do it now.

The S5R3 Apps have become much faster and more reliable and we even gained some more computing power from more and newer machines in past months. The Workunit Generator where the overall run progress on the server status page is derived from doesn't know about that and its predictions still average over the whole run, so are slightly off. According to internal statistics the last Workunits of S5R3 will be generated in the first days of August.

Therefore the Einstein@home development team has begun to prepare the next run "S5R4", which will include the remaining data from S5 that wasn't available when we started the previous S5 searches (that much we know yet - the data that will actually be used will be chosen from the whole S5 data in the next few weeks).

In particular this means that the development of the Einstein@home Applications will now focus on what is needed for S5R4, there will probably be no more new Apps for S5R3.

Some details for the techs: The "Fstat" engine will stay the same, with all optimizations achieved so far. In the "Hough" code we'll probably switch on the "weights", which might need some adaption of the optimizations done to the "weightless" code. Some more columns with additional (statistical) information about the "candidates" will be added to the result file. This will probably slightly increase the size of the files sent back to the server, and that of the checkpoint files, too. We're discussing measurements to average out the runtime differences visible in the current workunits in the workunits by splitting the sky among them differently from the way we do it now.

Won't stop me writing tools! I have a 'cradle' for development now anyway, and have learnt alot to boot. :-)

Won't stop anyone else either, I dare say .... if the 'cyclic' behaviour is lost/diminished/whatever, we'll find something else to focus on! :-)

Might I add - for any current or potential users - that the pleasant dynamic that exists at E@H between the project management/developers and the user base here is superb and represents an 'emergent' trend likely not originally predicted. Keep it up! :-)

This point is good news from my point of view, no bad. The runtime differences have been a real obstacle to some potentially important comparisons--we've had a continuing stream of posts by people making inappropriate comparisons of aps and platforms, and often broadcasting wrong conclusions. I'm not sure how much actual harm that caused, but at the least it was a substantial noise factor.

For those who pay attention to credits, the considerable variation in "pay equity" over appreciable periods of time has been a distraction as well.

While playing with data can be fun, I'm really only interested when there are potential beneficial consequences. Here, specifically, I hoped that my bit--some contribution to empirical curve-fitting models, and lots of graphs--might in the short term reduce noise in posted comparisons, and perhaps therefore help a few people make better ap choices. In the medium term my highest hope was that the project might iron out much of the credit vs. actual work done variation.

That they are intending to do so is good, whether or not my posts nudged them along in any way.