stephenbrooks.orgForumMuon1GeneralAn optimisation question
Username: Password:
Search site:
Subscribe to thread via RSS
tomaz
2009-03-19 19:54:52
Stephen, on my understanding we are tracking some ammount of particles through an accelerator.  We want to optimise accelerator in such a way, that we get as mush as possible particles at the exit of the machine.  What is the starting (entering) number of particles ?
It is obvious that with progress of optimization we get more particles traveling longer time in the machine, thus computational times are longer.  Would be possible to reduce number of entering particles as optimisation progress ?  This would reduce computational time and speed up optimisation.  When we rach max.  (or when we think we reached it) we could run same lattice with more particles just to check it...Does it has sense ?
RGtx
2009-03-20 11:07:41
You could run muon1 from the command line using the switches -c -/n. Then rerun the highest scoring genomes in a queue file normally.

For example, as a test I am running "muon1 -c -/50", and within 2.5 hours I have already gone positive.  These results are generated without any checksum, so do not score pointswise if returned (If your a "stats whore" tough!).
tomaz
2009-03-20 13:35:08
Thank you, I wasn't aware of that.  Is there any list of switches with explanations ?  It is usefull but I had something else in mind.
At the begining of tracking, some 2500 particles are put in and tracked to the end.  Only some of them survive till the end.  Now, when machine is not very well optimised, only few paricles survive.  Because of statistical reasons large amount (2500 ?) of particles have to be put in.  My point is, why not reduce number of starting particles as optimization goes better ?  When we are at 3% muon maybe 1500 starting particles would be enough ?  Just a thought.

RGtx
2009-03-20 14:30:29
Use "muon1 -?" for a list of switches, detailed here: http://stephenbrooks.org/muon1/faq/
Stephen Brooks
2009-03-20 14:42:19
The thing is, at later stages in the optimisation (higher yields), the yield often increases quite gradually.  That means it's small differences *between* yields and not the overall accuracy that counts.  So we must maintain a large number of particles even if the yield is big.  For instance, sure, I could reduce the number of particles to keep the relative error in the yield at 10%, but that 10% is awfully big compared to the tiny steps up the optimisation makes.

It's very interesting that the optimisation progresses quite well with a reduced number of particles (at least in the early stages), though.
tomaz
2009-03-20 15:10:55
OK, thanks RGtx.

Stephen, I see.  But what if there is another side of same stick?  With less paricles we could search more genomes and with "rougher" results maybe avoid some local extremas?  Than when there is obvious that we hit "the wall" we recompute best ones with more particles?
tomaz
2009-03-20 15:20:12
cool, i'll test -/10 now !
tomaz
2009-03-21 00:51:21
Since RGtx gave me a new toy I played a little.  I let it run for few hours with -/10 and -/20 switch.  Then I took some results and rerun them in normal mode.  Bellow are compared results (muon% and Mpts) for -/x run and {normal run}
I decided to let it run with -/5 swich for a day or two and see where it goes...


-b -/10

1.914980 (139.4 Mpts) [v4.44d] <Linac900Removable6c2> {1.951250} {1443.1 Mpts}

1.915638 (138.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.882577} {1432.6 Mpts}

1.930497 (144.7 Mpts) [v4.44d] <Linac900Removable6c2> {1.941209} {1491.1 Mpts}

1.945546 (123.2 Mpts) [v4.44d] <Linac900Removable6c2> {1.787847} {1283.0 Mpts}

1.959270 (139.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.920069} {1443.7 Mpts}

1.970214 (134.1 Mpts) [v4.44d] <Linac900Removable6c2> {1.882331} {1367.2 Mpts}

1.970438 (139.1 Mpts) [v4.44d] <Linac900Removable6c2> {1.953155} {1442.7 Mpts}

1.996171 (132.6 Mpts) [v4.44d] <Linac900Removable6c2> {1.925833} {1372.6 Mpts}

2.010308 (139.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.956223} {1452.0 Mpts}

2.010308 (139.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.956223} {1452.0 Mpts}

-b -/20

1.665890 (70.5 Mpts) [v4.44d] <Linac900Removable6c2> {1.848585} {1373.7 Mpts}

1.959574 (71.2 Mpts) [v4.44d] <Linac900Removable6c2> {1.928187} {1371.0 Mpts}

1.961045 (70.9 Mpts) [v4.44d] <Linac900Removable6c2> {1.998373} {1394.5 Mpts}

1.993968 (69.4 Mpts) [v4.44d] <Linac900Removable6c2> {1.999322} {1439.3 Mpts}

2.101536 (353.2 Mpts runs=5) [v4.44d] <Linac900Removable6c2> {1.959327} {1392.5 Mpts}

1.995481 (352.2 Mpts runs=5) [v4.44d] <Linac900Removable6c2> {1.955345} {1443.3 Mpts}

1.856260 (72.2 Mpts) [v4.44d] <Linac900Removable6c2> {1.947751} {1457.4 Mpts}

2.087852 (362.8 Mpts runs=5) [v4.44d] <Linac900Removable6c2> {1.956485} {1441.2 Mpts}

2.039589 (70.4 Mpts) [v4.44d] <Linac900Removable6c2> {1.959327} {1392.5 Mpts}

1.945341 (74.7 Mpts) [v4.44d] <Linac900Removable6c2> {1.972306} {1483.9 Mpts}
tomaz
2009-03-22 00:33:00
Seems like same mess with /5 so I rather run it on /25. Much faster and results seems OK.  Will see where it goes.  Basicaly, it's like 25 day work in a one day...

-b -/5

2.015088 (1332.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.980727 (1388.9 Mpts)}

1.974747 (274.6 Mpts) [v4.44d] <Linac900Removable6c2> {1.990434 (1441.0 Mpts)}

1.993296 (264.5 Mpts) [v4.44d] <Linac900Removable6c2> {1.918718 (1367.8 Mpts)}

1.960192 (1353.6 Mpts) [v4.44d] <Linac900Removable6c2> {2.030060 (1440.1 Mpts)}

2.020145 (267.4 Mpts) [v4.44d] <Linac900Removable6c2> {1.983539 (1391.5 Mpts)}

1.981678 (274.4 Mpts) [v4.44d] <Linac900Removable6c2> {1.980876 (1443.5 Mpts)}

1.971235 (275.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.944440 (1449.7 Mpts)}

2.011973 (1391.2 Mpts) [v4.44d] <Linac900Removable6c2> {1.977783 (1453.5 Mpts)}

2.044531 (1382.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.995034 (1438.5 Mpts)}

2.006217 (278.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.950964 (1454.1 Mpts)}

2.019208 (274.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.992070 (1426.2 Mpts)}

2.029138 (1396.4 Mpts) [v4.44d] <Linac900Removable6c2> {2.005599 (1457.6 Mpts)}

2.011644 (277.2 Mpts) [v4.44d] <Linac900Removable6c2> {2.007643 (1449.9 Mpts)}

2.036845 (270.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.972919 (1424.7 Mpts)}

1.964327 (273.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.965179 (1439.7 Mpts)}

-b -/25

2.294110 (302.6 Mpts) [v4.44d] <Linac900Removable6c2> {2.201316 (1561.6 Mpts)}

2.188683 (61.0 Mpts) [v4.44d] <Linac900Removable6c2> {1.995034 (1438.5 Mpts)}

2.077174 (63.3 Mpts) [v4.44d] <Linac900Removable6c2> {1.956846 (1439.7 Mpts)}

2.163864 (290.3 Mpts) [v4.44d] <Linac900Removable6c2> {2.195974 (1569.4 Mpts)}
tomaz
2009-03-22 22:21:41
I'd say that it is reasonable to use this "two level" approach, I got some nice results.  And -/25 seems like a right measure.

RGtx, what happened with your -/50 test ? 

-b -/25

2.350531 (305.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.240300 (1559.5 Mpts)}

2.361861 (315.7 Mpts) [v4.44d] <Linac900Removable6c2> {2.334434 (1623.8 Mpts)}

2.433432 (313.8 Mpts) [v4.44d] <Linac900Removable6c2> {2.341757 (1612.2 Mpts)}

2.444604 (313.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.337324 (1611.7 Mpts)}

2.415719 (313.8 Mpts) [v4.44d] <Linac900Removable6c2> {2.351707 (1612.3 Mpts)}

2.425999 (314.2 Mpts) [v4.44d] <Linac900Removable6c2> {2.268644 (1613.9 Mpts)}

2.450060 (317.8 Mpts) [v4.44d] <Linac900Removable6c2> {2.337297 (1632.7 Mpts)}

2.431361 (316.1 Mpts) [v4.44d] <Linac900Removable6c2> {2.312950 (1623.4 Mpts)}

2.432824 (61.3 Mpts) [v4.44d] <Linac900Removable6c2> {2.309613 (1608.9 Mpts)}
Stephen Brooks
2009-03-25 16:10:54
What happens when you retest the results you get at -/10 or -/25 with the full number of particles (use queue.txt) - how close are they?
tomaz
2009-03-26 08:54:46
Dear Stephen.
That is what I've been posting all the time.  First numbers in a row are from -/25, numbers in { } are from full run.

At the beggining it works fine but after a long run things diverge in a great extend.  Bellow are some results, you can see that difrences are very large and everything becomes unrealistic.

But it is expectable.  I think of folowing "hybrid" method (maybe you can make a test version of software...):
starz with switch -/xx
after 200 or so results turn to normal mode and continue computation
after 50 or so results, delete all previous results except of that of normal mode, turn to -/xx mode and so on...


2.582166 (69.0 Mpts) [v4.44d] <Linac900Removable6c2> {2.349870 (1661.9 Mpts)}

2.613070 (65.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.352723 (1648.0 Mpts)}

2.629349 (62.7 Mpts) [v4.44d] <Linac900Removable6c2> {2.347305 (1611.4 Mpts)}

2.613070 (65.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.352723 (1648.0 Mpts)}

2.609397 (67.7 Mpts) [v4.44d] <Linac900Removable6c2> {2.358065 (1655.7 Mpts)}

2.605596 (61.2 Mpts) [v4.44d] <Linac900Removable6c2> {2.353294 (1652.2 Mpts)}

2.690808 (337.0 Mpts) [v4.44d] <Linac900Removable6c2> {2.301029 (1653.3 Mpts)}

2.682386 (68.5 Mpts) [v4.44d] <Linac900Removable6c2> {2.225737 (1651.9 Mpts)}

2.686847 (332.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.324464 (1647.4 Mpts)}

2.604212 (67.8 Mpts) [v4.44d] <Linac900Removable6c2> {2.307201 (1651.0 Mpts)}

2.656345 (68.9 Mpts) [v4.44d] <Linac900Removable6c2> {2.335736 (1651.0 Mpts)}

2.641545 (69.4 Mpts) [v4.44d] <Linac900Removable6c2> {2.312803 (1648.6 Mpts)}
Stephen Brooks
2009-03-26 16:20:32
Oh, I see it now.  Yes, the fact that having too few particles makes it easy for the code to optimise for *those* particular particles and not a realistic whole distribution is something I've considered before and is another reason why we run with tens of thousands of particles all the time.

Most of the processing power is spent trying to squeeze the last bit out when the optimisation is advanced, so we aren't losing too much by using the full number of particles in the early stages, though I agree it's a good shortcut for advanced users.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17125396 accesses.