|I don't know if I've told anyone this before, but listings of the successive best results are available at http://stephenbrooks.org/muon1/successives/ for each lattice. Note the results are not in order, you'll have to sort them yourself. But it could show the evolution of where the optimum is.|
|I also discovered the following while plotting the best yield vs. time graph in a different way (for PhaseRotEb1):|
Not quite sure what it means, or whether that linear-ish trend in yield against log(results) would continue.
|Yeah, but you could also ask yourself if log-ish trend yield against linear in first (upper) graph would continue...|
|Well it can't continue indefinitely, but I'm wondering if it resembles a log graph because the improvement directions get exponentially harder to find as the optimisation progresses.|
|"Harder to find" also includes more time needed for computation because mpts gets much higher.|
|That's true but I've plotted it against "number of results" so the effect of later results taking more real time doesn't show on this graph.|
|Yes, I see. First 100k results brought score to 3, last 100k only 0.2 or so. There is no time component.|
One influence of longer computational time might be less variance of results (smaller gene pool). At the begining there are many results per day, on one client a lot of generations is computed. At the end, there are maybe two or three results per client (if there is queued result it takes damn long) and when samplefile is loaded every day it easy get in very narrow way. Maybe at the later stage, samplefiles shoud be loaded less frequently ? It seems that boinc way realy helped last simulation (they are doing their own samplefile with highest mpts results).
|The other day I was reading this and was wondering if such sparse strategies for testing parameters might be useful to us. Our problem is I'm afraid the parameters are quite correlated with each other so some of those strategies won't work.|
I got there via this blog post (see also this)
You can try some of the design-of-experiments stuff yourself using the TEST mechanism for testing manually-generated results.
|To be more exact, for the Boinc clients I take the 200 results with the highest mpts and Stephens samplefile as samplefile.|
|Well, not everyone does the samplefiles either. I almost never run the samplefiles, which is why you'll see my results usually in a different band. in d2 I'm barely positive, and in the new c2 lattice I've done some manual designs that give long sims with a linac (the current just-positive results don't seem to include one) so my client is attacking things a different way.|
While the samplefiles are great at moving things along, if you have a bunch of computers, maybe have one in 10 (maybe even just one in 20) not run a samplefile, so we can possibly get some new 'species' of results, and another path to try. The problem is, the more the clients investigate this localised area, the less they'll look elsewhere, and we could get trapped in a local maximum.
It's also why I've suggested to Stephen not generating a samplefile for the first 48 hours or so of a new lattice, as it'll give us a wider base, before most clients start drifting together.
|Should I run the Boinc hosts without samplefile?|
|Not permanently, unless you have some way of exchanging results between clients within BOINC.|
|There are more of us running the native client, that do not use the sample files, but create our own. |
You can see this clearly as a "bump" around 1500Mpts on d2.
Some of the Team Norway user are collaborating on this effort, just to try to make an interesting "anomaly", guessing the focus on high Mpts might disregard some interesting optimizations with lower Mpts.
As BOINC users produce usually more than any other users, their results tend to fill the sample file more frequent. Stephen's sample file is therefore heavily influenced on the high Mpts results yoyo inserts in their sample files. I think this pushes everyone in the same direction as yoyo's sample file most of the time.
[Edited by runesk at 2010-10-16 19:46:45]
|Here's another thing I found about the 10d2 optimisation:|
It shows the bump on the muon yield vs. time curve was at the point where the linac was switched on.
|And here's the score vs. log-time plot for this more recent optimisation (time is easier to get out of the database than "results received").|