Today I thought more about an algorithm (a rule, a test, a way to calculate) I'd outlined that would decide when our Perl simulations of USS accumulation had reached equilibrium. (I had to think more because my initial explanation was very hard to follow.)
It's actually two algorithms, one for deciding how often to report the latest status of the simulated genome, and one to decide whether, at a report time, equilibrium has been reached and the run should stop.
The first algorithm is needed because how many cycles a run takes depends very strongly on the conditions we set. We want frequent reports, but if the run is going to take 500,000 cycles we don't want a report every cycle, or even every 10 or 100 cycles. How often we want reports also changes within a single run: at the start of the run things are changing fast and we want frequent reports, but as conditions approach equilibrium we want reports less often.
Here the solution is to make the reporting frequency a function of how many cycles have elapsed. The new rule is: only report results if more than 1% of the total run has elapsed since the last report. The result is that, for the first 100 cycles we get a report every cycle, but after 1000 cycles we only get a report every 10 cycles, and after 10,000 cycles we only get one every 100 cycles. Even if the run lasts 1,000,000 cycles, we'll only have about than 1000 reports. The best thing is we don't need to have any idea of how long the run might take.
The second algorithm is more complicated and I'm not going to describe it until we've had a chance to try it out.
How not to run a university - like a business
12 hours ago in The Phytophactor