stephenbrooks.orgForumMuon1GeneralHigh-res scan project
Username: Password:
Page 1 2 3 4 5 6
Search site:
Subscribe to thread via RSS
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
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]
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.
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.
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.
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]
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.
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.
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
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
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:

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>
2010-11-04 21:30:30
I've taken 0-49.
2010-11-04 22:34:13
I have taken
[edit] Sorry correction:
0-49 RGtx
250-299 Boots
300-349 Boots
350-399 Boots
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.
2010-11-06 04:28:19
I'll Take (scan3) 50-99 and (scan3) 450-499
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
0-49 RGtx
50-99 Cameron
100-149 RGTx
150-199 Stephen Brooks
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

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.
2010-11-09 23:34:25
Sent 250-399 Boots
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)
2010-11-13 13:24:58
200-249 returned.
150-199 taken, to be repeated with v4.44d.
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?
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.
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.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel RSS feed

Site has had 24953446 accesses.