 |
| Stephen Brooks 2005-06-10 08:47:51 | I've just noticed something odd about the new PhaseRotB results. The parameters beginning with 'p' (specifically, pd# prf#v prf#p ps#l ps#f) seem to be included for cell numbers (#) from 1 up to 100! As far as I can tell, Muon1 should never generate cell numbers above 40 with that lattice. Was this a case of manual seeding? Right now Muon1 is set to preserve "introns" - that is, unused pieces of genetic material - in this case, parameters that do not correspond to any component in the current simulation, because they can encode information that is useful to evolution later on if those parameters become active again. However, I might switch this off to prevent the results becoming filled with rubbish if odd things like this happen. |
| Stephen Brooks 2005-06-14 09:43:27 | After looking at that result, then investigating something else while writing a paper, I had an "idea". PhaseRotB top % should go up some time soon  |
| Stephen Brooks 2005-06-15 09:38:30 | Hmm results not updating very regularly of late - I've just changed something with the log files so it should complete faster in the case of large files. Some people have files >300MB, which even with these monster 10KB-long PhaseRotB results is 30000+. HaloJones has 125000+ results in one optimisation. This is not a _bad_ thing, but I've used 32bit (!) long hashes internally in the duplicates checker and these large populations are causing a lot of collisions. I do have a fallback accurate-check in case of collisions, so it doesn't go wrong, it just goes slower than I expect and logs "rare events" to a file. In a 125000 result file with a 32bit hash I'd expect 2 or 3 collisions but I'm getting a lot more. This, I think, is because the hash I'm using ends up depending on parts of the result but not other parts, so I'm getting more collisions than I should have. Now I've figured it out, will see if I can fix. There's an interim solution in now (making the writes to the logfile faster) anyway. |
| Stephen Brooks 2005-06-16 02:09:59 |
Looks like it worked! That result should appear in the PhaseRotB samplefile later today. It will be interesting to see if it can be optimised further. |
| Stephen Brooks 2005-06-16 03:01:17 | I thought the sample file was only uploaded 15 minutes ago, but somehow two users [AMD Users]bwhite and [AMD Users]vaughan have already produced results based on this new one! |
| Fluid 2005-06-16 05:20:10 | What the Christ. Are results like that even possible?  |
| Stephen Brooks 2005-06-16 05:49:36 | Yeah, my main mission now is to find out why the optimiser didn't find it! It looked like it was increasing _very slowly_, but I think there ought to be a way it could be speeded up. Anyway, the optimiser will hopefully now have fun making this one a bit better, if it can. |
| LostinTime 2005-06-17 13:51:42 | Stephen, YES, it is optomizing higher. Several nice results today. Jim |
| Stephen Brooks 2005-06-18 12:43:53 | So in summary it was on 2.56, I kicked it to 3.07, and now the optimiser has taken it to 3.59, which is further than I kicked it! |
| Stephen Brooks 2005-06-27 15:23:55 | Make that 3.91%. I'm going to want it to go over 4% now. |
| [DPC]Stephan202 2005-06-28 00:47:02 | Well, don't we all  |
| AySz88 2005-07-08 22:29:45 | username v4.4 total Mpts best muon percentage hours since last active 1. MrGristle 146 71682.9 (0.0105%) 4.008864 0 That's our first 4%+ result. Congrats, Gristle! |
| Stephen Brooks 2005-07-09 15:53:53 | I personally feel sorry for [AMD Users]vaughan who got 3.999926 after crunching over 10x as many results! |
| LostinTime 2005-07-09 17:01:04 | Gone for 5 days...got some catching up to do |
