 |
| Stephen Brooks 2010-10-27 19:27:36 | I've put the v4.44e that was released up here, though I suspect it isn't the same as my "4.44e", which is a development version. Still, would be interesting to see if there are any differences between the released d and e. |
| [DPC] Mr. Aldi 2010-10-27 21:03:47 | Ok, as soon as my block 700-750 is ready, I'll start this run. Allthough, Maniacken actually already finished this block as well  |
| RGtx 2010-10-27 21:31:22 | I, think you might have left some development/debug code in this release, I'm getting a number of Simulation_scorerampdistance_xxxxxxxx text files (one for each simulation run). |
| [DPC] Mr. Aldi 2010-10-27 22:01:49 | Yeah, see kwaak It will work anyway ^_^ (edit needed to exclude the bork from link) [Edited by [DPC] Mr. Aldi at 2010-10-27 22:02:15] (and to make it clickable) [Edited by [DPC] Mr. Aldi at 2010-10-27 22:03:15] |
| [DPC] Mr. Aldi 2010-10-28 00:50:36 |  In order to restore an autosave you must run w/o the -q switch, otherwise autocli.sav gets overwritten. Got a crash due to problems with graphics card  [Edited by [DPC] Mr. Aldi at 2010-10-28 00:50:47] |
| [TN]opyrt 2010-10-28 14:08:47 | Isn't it a bit unfortunate that the results are so noisy? It seems that on the extreme, adding a small value to the parameter boosts the result by 0.5%, then adding another small value again drops it 0.5% (first scan, around 150). 0.5% is a significant value when we usually end our simulations at 2.5%-3.0%. I DEMAND AN ANSWER! No, actually I don't, but it would be interresting to see your comments on this.  |
| Stephen Brooks 2010-10-28 15:14:11 | --[Isn't it a bit unfortunate that the results are so noisy?]-- Why do you think I'm doing this scan anyway? To try and understand the sources of noise so I can reduce them. There will always be *some* sort of noise in a simulation with a finite number of particles, but we appear to have slightly more noise than I would expect. The good thing is the optimiser appears to be able to pick out values near the peak anyway, even with a quite large amount of noise. But it might do better if I can find the source(s) of the noise and reduce them, which is what I will do in subsequent scans. The _axial3 lattice (scan#2) was the easiest of the various ways I had to reduce the noise, but it hasn't done so - in fact it appears to have done almost nothing at all, which is a bit surprising in itself. But don't worry, I have several other things to try. |
| [TN]opyrt 2010-10-28 16:57:16 | Thanks for your answer. Atleast we've seen that you're on to something in the dev-version of the software as it has a lot less noise. |
| [DPC] Mr. Aldi 2010-10-28 23:29:17 | Thanks for your comment on this. I had the same thoughts about the result as opyrt I've sent 700-749. Now running the simulation to find out what curve the 4.44e would produce. For the first run, I needed less Mpts. For runs around 700 I needed 7600 Mpts with 4.44d. I'm interested to see how much Mpts I need for v4.44e to calculate around 700. |
| Haiya-Dragon 2010-10-29 00:15:53 | Sent 550-599 |
| Stephen Brooks 2010-10-29 15:20:46 | I've added the new results to the scan2 graph: |
| [DPC] Mr. Aldi 2010-10-29 17:17:05 | The optimum for this magnet seems to be around 450 if you look at the curve, instead of 500 which produced the current highest yield. To me this optimum seems to be higher because of the noise. So if you'd take 450 for this magnet and also make a scan like this for the other magnets to look whether the 'exact' optimum would be and correct accordingly, what would you get? Just a question. Of course, if you change the other magnet's 'optimum', you may also influence the optimum of this magnet. |
| Boots 2010-10-31 08:53:32 | Done and sent 850-899 Boots |
| [DPC] Mr. Aldi 2010-10-31 13:50:17 | Sent 650-699 and results from try with 4.44e 4.44e that I got from Stephen did produce the same type of result as 4.44d, only took more time. [Edited by [DPC] Mr. Aldi at 2010-10-31 13:53:00] |
| [DPC]white_panther 2010-10-31 15:20:31 | am I correct to assume that 800-849 isn't taken yet? if so than i'll take the last one. 0-29 RGtx 30-59 [dpc]white_panther 60-89 K`Tetch 90-119 [dpc]white_panther 120-149 RGtx 150-179 [dpc]white_panther 180-209 [dpc]white_panther 210-239 RGtx 240-269 Stephen Brooks 270-299 Stephen Brooks 300-319 tomaz 320-339 tomaz 340-359 Boots 360-379 Boots 380-399 Boots 400-419 Boots 420-439 Cameron 440-459 Haiya-Dragon 460-479 tomaz 480-499 tomaz 500-549 tomaz 550-599 Haiya-Dragon 600-649 [dpc]white_panther 650-699 [DPC] Mr. Aldi 700-749 [DPC] Mr. Aldi 750-799 Stephen Brooks 800-849 [DPC]white_panther 850-899 Boots 900-949 Stephen Brooks 950-999 Hydrox oh and i send 600-649 |
| Stephen Brooks 2010-11-01 16:19:01 | Some more results arrived over the weekend and I updated the scan2 graph above. Looks like 750-799 (mine, still running, done 750-794 so far) and 800-849 (just taken by white_panther) remain. |
| [OcUK]diogenese 2010-11-02 07:18:20 | My PC has finally made it to the other side of the world, is there more to do here or should I let it carry on with what it gets on it's own? OcUK in NZ! |
| Stephen Brooks 2010-11-02 11:15:25 | My block 750-799 has finished. There won't be anything more to do on these until I bring out another scan. |
| Maniacken 2010-11-02 23:08:59 | Where do you want me to send results to? Do i need to then upload the results to get credit? |
| [DPC] Mr. Aldi 2010-11-03 10:42:56 | See email address below If you use manualsend, results.txt should give you the credit |
| Nexus 2010-11-04 02:09:57 | Hi Stephen, can I re-check 550-599? |
| Maniacken [US-Distributed] 2010-11-04 05:45:27 | Maniacken 000-999 Complete |
| Stephen Brooks 2010-11-04 10:28:05 | I've received Maniacken's long results file. When I get the last white-panther block I'll put everything on the graph. Hopefully the two sets of results will agree... [edit] Decided it might be interesting to see the result "noise" on a smaller scale. There is now a super-high-res scan that looks only at a tiny range around ls51=500-504 on the previous lattice. Simulations should be shorter than scan2 as the 3x particles trick is switched off. |
| [DPC] Mr. Aldi 2010-11-04 18:46:42 | 0-49 50-99 100-149 150-199 200-249 250-299 300-349 350-399 400-449 450-499 500-599 [DPC] Mr. Aldi 600-699 [DPC] Mr. Aldi 700-799 [DPC] Mr. Aldi 800-899 [DPC] Mr. Aldi 900-999 [DPC] Mr. Aldi You can add: sb9r=349;sb9l=647;sb9f=932;sb8r=426;sb8l=149;sb8f=390;sb7r=797;sb7l=295;sb7f=945;sb6r=797;sb6l=295;sb6f=945;sb5r=724;sb5l=457;sb5f=618;sb4r=974;sb4l=049;sb4f=670;sb3r=000;sb3l=999;sb3f=187;sb2r=000;sb2l=999;sb2f=990;sb1r=000;sb1l=631;sb1f=103;sb10r=096;sb10l=647;sb10f=932;s2r=234;s2l=992;s2f=000;s1l=999;s1f=996;rf9v=235;rf9p=000;rf8v=715;rf8p=118;rf7v=571;rf7p=688;rf6v=043;rf6p=583;rf5v=604;rf5p=940;rf4v=991;rf4p=849;rf3v=918;rf3p=702;rf2v=537;rf2p=000;rf1v=992;rf1p=809;rf10v=926;rf10p=855;ls9l=992;ls9f=000;ls8l=431;ls8f=000;ls7l=629;ls7f=995;ls6l=875;ls6f=036;ls5l=490;ls5f=997;ls4l=761;ls4f=999;ls3l=991;ls3f=984;ls2l=898;ls2f=997;ls1l=992;ls1f=000;ls10l=999;ls10f=000;linaccells=997;ld9=509;ld8=231;ld7=751;ld6=999;ld5=048;ld4=483;ld3=552;ld2=480;ld10=000;ld1=000;decaycells=018;db9l=000;db8l=255;db7l=817;db6l=734;db5l=178;db4l=403;db3l=400;db2l=137;db1l=446;db10l=097;d4l=679;d5l=679;d3l=958;d2l=169;d1l=449;tantalumrodz=222;tantalumrodr=000;#runs=5; 2.489781 (38278.4 Mpts) [v4.44d] <Linac900Ext10d2_zoom> {B26F6D6E110EF2639F253DED} To results.dat to reduce 5x checks. Muon1 does not check the hash from results.dat? Testing configuration above, I get: 2.284293 (2567.5 Mpts) [v4.44d] <Linac900Ext10d2_zoom> |
| RGtx 2010-11-04 21:30:30 | I've taken 0-49. |
| Boots 2010-11-04 22:34:13 | I have taken [edit] Sorry correction: 0-49 RGtx 50-99 100-149 150-199 200-249 250-299 Boots 300-349 Boots 350-399 Boots 400-449 450-499 500-599 [DPC] Mr. Aldi 600-699 [DPC] Mr. Aldi 700-799 [DPC] Mr. Aldi 800-899 [DPC] Mr. Aldi 900-999 [DPC] Mr. Aldi |
| Stephen Brooks 2010-11-05 12:44:10 | I've taken (scan3) 400-449. |
| Cameron 2010-11-06 04:28:19 | I'll Take (scan3) 50-99 and (scan3) 450-499 |
| RGtx 2010-11-07 22:28:42 | 0-49 returned & 100-149 taken. |
| Stephen Brooks 2010-11-08 12:39:49 | 400-449 done, taking 150-199 (scan3) 0-49 RGtx 50-99 Cameron 100-149 RGTx 150-199 Stephen Brooks 200-249 250-299 Boots 300-349 Boots 350-399 Boots 400-449 Stephen Brooks 450-499 Cameron 500-599 [DPC] Mr. Aldi 600-699 [DPC] Mr. Aldi 700-799 [DPC] Mr. Aldi 800-899 [DPC] Mr. Aldi 900-999 [DPC] Mr. Aldi |
| [DPC] Mr. Aldi 2010-11-08 14:44:06 | Got a recheck, you now can use sb9r=349;sb9l=647;sb9f=932;sb8r=426;sb8l=149;sb8f=390;sb7r=797;sb7l=295;sb7f=945;sb6r=797;sb6l=295;sb6f=945;sb5r=724;sb5l=457;sb5f=618;sb4r=974;sb4l=049;sb4f=670;sb3r=000;sb3l=999;sb3f=187;sb2r=000;sb2l=999;sb2f=990;sb1r=000;sb1l=631;sb1f=103;sb10r=096;sb10l=647;sb10f=932;s2r=234;s2l=992;s2f=000;s1l=999;s1f=996;rf9v=235;rf9p=000;rf8v=715;rf8p=118;rf7v=571;rf7p=688;rf6v=043;rf6p=583;rf5v=604;rf5p=940;rf4v=991;rf4p=849;rf3v=918;rf3p=702;rf2v=537;rf2p=000;rf1v=992;rf1p=809;rf10v=926;rf10p=855;ls9l=992;ls9f=000;ls8l=431;ls8f=000;ls7l=629;ls7f=995;ls6l=875;ls6f=036;ls5l=935;ls5f=997;ls4l=761;ls4f=999;ls3l=991;ls3f=984;ls2l=898;ls2f=997;ls1l=992;ls1f=000;ls10l=999;ls10f=000;linaccells=997;ld9=509;ld8=231;ld7=751;ld6=999;ld5=048;ld4=483;ld3=552;ld2=480;ld10=000;ld1=000;decaycells=018;db9l=000;db8l=255;db7l=817;db6l=734;db5l=178;db4l=403;db3l=400;db2l=137;db1l=446;db10l=097;d4l=679;d5l=679;d3l=958;d2l=169;d1l=449;tantalumrodz=222;tantalumrodr=000;#runs=5; 2.502057 (12785.4 Mpts) [v4.44d] <Linac900Ext10d2_zoom> {3B26C801876AC7FF505A2893} for results.dat to reduce rechecks |
| [DPC] Mr. Aldi 2010-11-08 15:03:58 | As muon1 does not check the hash, you could also just edit the yield |
| Stephen Brooks 2010-11-08 18:01:39 | I've updated the scan2 graph with everything including the full-scan, though it mostly overlaps exactly except where there are some purple or red results. And here's the graph for scan3:  Looks like my development version is following a different line to the 4.44d. On the other hand, the results still vary exceptionally quickly with what are very small variations in a solenoid length. |
| Boots 2010-11-09 23:34:25 | Sent 250-399 Boots |
| RGtx 2010-11-10 16:41:34 | 100-149 returned, 200-249 taken. |
| Stephen Brooks 2010-11-10 18:08:03 | My results finished, updated the graph above. |
| [DPC] Mr. Aldi 2010-11-11 23:16:04 | My cows have finished 500-999  Now they deserve some crunchy cattle cake [Edited by [DPC] Mr. Aldi at 2010-11-11 23:18:25] |
| Stephen Brooks 2010-11-12 16:55:59 | Thanks, those have been added to the graph. I'm currently doing some testing of previous versions to try and understand the large difference between my current development version (purple) and the others. (The noise is probably a separate issue) |
| RGtx 2010-11-13 13:24:58 | 200-249 returned. 150-199 taken, to be repeated with v4.44d. |
| RGtx 2010-11-16 13:13:50 | 150-199 (v4.44d) returned. 400-449 taken, to be repeated with v4.44d. |
| Stephen Brooks 2010-11-17 17:00:39 | One more graph update, why not? |
| [DPC] Mr. Aldi 2010-11-18 07:52:55 | Conclusion, it is quite flat? But on the scale of flatness, The Netherlands are more flat, I guess ^_^ |
| Stephen Brooks 2010-11-18 14:12:37 | It's flat, but the noise is on a very small scale, so tiny variations in the solenoid length cause the decays etc. to "randomise" in a different way. This is likely to be random number generator related, but could possibly be something else. I'm going to have to do a bunch of individual tests here before I can be conclusive. |
| [DPC] Mr. Aldi 2010-11-18 17:55:37 | I see. While in fact these tiny variations shouldn't matter for the final result and in theory we actually would have to see a horizontal line? |
| RGtx 2010-11-18 19:15:51 | The "noise" over a larger number of runs is of comparable magnitude: sb9r=349;sb9l=647;sb9f=932;... ...;ls5l=443;... ...;#queued=1;#runs=14; 2.406860,2.411453,2.366582,2.407996,2.442189,2.400140,2.386119,2.398943,2.371480,2.403803,2.411973,2.444274,2.363483,2.428977 (35557.1 Mpts) [v4.44d] <Linac900Ext10d2> {9396CFB4A0216FD4F*******} |
| Stephen Brooks 2010-11-18 23:41:15 | Thanks, that's going to be useful actually to compare noise of multiple runs on one result with noise between results. |
| RGtx 2010-11-19 10:56:52 | 400-449 (v4.44d) returned. |
| Stephen Brooks 2010-12-06 16:12:13 | scan3 updated with results from Cameron, it is now complete. |
| Stephen Brooks 2011-02-10 19:56:18 | It took longer than I thought but I think I've found a bug that could be responsible for our "fuzzy" yields that vary under even very small perturbations. Sometimes when the RF cavity phases are being synchronised, two hits of the test particle are registered instead of one, leading to small errors in the phase setup. These double-hits are intermittent and sensitive to tiny differences in input parameters. I think I'll do a new scan when I believe I've eliminated it, and that should show smoother results. |
| Stephen Brooks 2011-02-14 18:38:42 | This is good news. Two very nearby accelerator designs, differing by only a few microns used to get: 2.430789 (2566.4 Mpts) 1.980075 (2550.8 Mpts) ...but now I've fixed a bug in a root-seeking algorithm, they get: 2.263001 (2553.5 Mpts) 2.262357 (2553.8 Mpts) ...which is the sort of smoother variation I'd have liked to see. Right now the fixed version is a bit slower, the top two results took 3482.075255 seconds 3440.207097 seconds ...whereas the bottom two took 4119.901874 seconds 3955.677171 seconds (which is about 1/6 longer). I have an idea for how to make it faster again, though. |
