stephenbrooks.orgForumMuon1GeneralVersion of MUON Client
Username: Password:
Search site:
Subscribe to thread via RSS
Pascal
2002-05-18 01:06:13
Actually, we have version 4.03. Will there be future versions, like 4.04 again?

What will be in future?  Version 5, 6, 7 ... ?
What parts of the accelerator are already computed, what has to be done still?

___________________________
1: Athlon TB-C, 1.2 GC/s, 256 MB DDR-RAM, Erazor x², ADSL-Flatrate, NIC Intel, Win 98 SE Mainboard MSI-6380 Rev.  1
2: Pentium III, 600 MC/s, 256 MB RAM, NIC Intel, Win 98 SE
Stephen Brooks
2002-05-18 11:29:00
I'm currently quite busy doing exams.  In the summer (around July), there may be another version of the program, but 4.03 seems to work fine for now.

Basically, the first optimisation run (just designing the solenoid channel) went from versions 1 to 3.11. The current (2nd) optimisation is versions 4 to 4.03 and is optimising the solenoid channel, but also simulating the muons through the "bending chicane" part so the solenoid channel is designed to work best with that added.

The next part to simulate will be a linear accelerator on the end of what we have so far.  This may be released as either version 4.1 or version 5 of the muon program, mainly dependant on how much of the code I alter before adding that part to the simulation.
AySz88
2002-05-18 18:24:04
How's the bug-squashing in v. 4.04 going anyway?
Stephen Brooks
2002-05-18 18:57:26
I'm not fixing bugs in 4.04 right now - gave that up as a lost cause.  I modified two things in that version, one of which was an attempt to support SMP which failed.  The other of which I've actually forgotten what it was.  If there is going to be a version 4.04 I'll probably leave out the SMP support and put some other improvement in instead.  For now, 4.03 seems to work adequately.  If I add in something like intermediate saves (i.e. saving progress of half-done simulations), then I'll release 4.04. But that might have to wait until the summer when I'm working on Muon1 as part of my job.
gogomaus
2002-05-20 10:14:26
quote:
Originally posted by Stephen Brooks:
I'm currently quite busy doing exams.  In the summer (around July), there may be another version of the program, but 4.03 seems to work fine for now.

Basically, the first optimisation run (just designing the solenoid channel) went from versions 1 to 3.11. The current (2nd) optimisation is versions 4 to 4.03 and is optimising the solenoid channel, but also simulating the muons through the "bending chicane" part so the solenoid channel is designed to work best with that added.

The next part to simulate will be a linear accelerator on the end of what we have so far.  This may be released as either version 4.1 or version 5 of the muon program, mainly dependant on how much of the code I alter before adding that part to the simulation.


Does it mean, the "bending chicane" is already fixed definitely ?
Stephen Brooks
2002-05-21 14:25:02
Yes, I asked the guy who designed the bending chicane whether it would be possible to vary any of the parameters in it and optimise, but he said it probably wouldn't be a good idea.
Jwb52z
2002-05-22 12:38:23
Why would the guy who designed the bending chicane not think it would be a good idea to optimize it?
Stephen Brooks
2002-05-22 12:55:28
Because it was designed to have specific properties as far as beam optics is concerned.  If the lengths/fields were varied, the beam would come out OK, but it would probably be the wrong "shape" in some sense.  I.e. the velocity spread might be all wrong.  After the chicane it has to go into a linear accelerator too, and that requires the bunch of muons to be quite "neat".
Stephen Brooks
2002-05-22 17:37:07
quote:
Originally posted by Chris Johnson:
but would there be merit in finding the mapping that the chicane applies to particles, finding the optimum input phase space, and optimising the channel to that.


You might as well just simulate the particles forwards through the chicane, as it only takes about 30% as long as simulating them through the decay channel.  Doing a mapping would complicate matters by introducing inaccuracies associated with the phase space being 6-dimensional (you'd have to simulate a LOT of particles to get anything like accurate enough).  So far in this accelerator nothing has been time-dependant, but the next section will be a linac with 88MHz accelerating cavities, so the "optimum" phase-space at the end of the chicane would have to be specified in 6D.

And this raises another point.  The "optimum" phase-space we'd like to see is having all the particles in the same place going at the same speed (going along the same path as what is often called the 'central particle').  I suppose you could look at the acceptance bucket of the linac and run that backwards through the chicane, but again, there wouldn't be too much point when it's more accurate to simulate the particles forwards.

Part of the reason this simulation was written was as a high-accuracy "trustworthy" verification to other codes already available that use tricks such as mappings to speed up the computation. 

quote:
This is pretty similar to me going on about looking at the 14D plot to see how dependent the parameters were on each other for optimisation - I don't know how much (if anything) your 'brute force' method misses by not spotting optimisations obvious to the human eye, e.g. getting stuck in local maxima.


I'm not 100% sure of my optimisation algorithm either, to the extent that I've tested a range of other algorithms that use different techniques to choose which results to generate new designs from (e.g. ones with a tendancy to avoid producing too many similar designs, or ones weighted more strongly by muon percentage).  However the alternatives I tried were all a lot worse than my original attempt.

The Group Leader at RAL (my boss) uses a very different technique to optimise designs, and that is to vary all the parameters slightly from a given design and then move in the direction that seems to increase performance for all of them (hill climbing).  Then repeat when climbing in that direction no longer helps.  This is more susceptable to getting stuck in local maxima than the genetic algorithm, and also does not work unless you have a large number of particles (like 500`000) so that the "small variations" do actually produce a sensible change in efficiency.  So for this particular simulation I chose the genetic algorithm for its general robustness even when the scoring function goes in bigger discrete "jumps".
gogomaus
2002-05-23 10:49:06
Stephen,
I fully agree to "your" approach and especially the evolutionary algorithm.
The only thing "my" human eyes can see obviously is the dominant influence of rod positioning to muon harvest, what is not so surprising due to the given geometry at the starting two solenoids.  Centre z-pos and low rot-angles will lead to good results and vice versa.
I did a little statistics on my 698 runs done so far and would like to present the trends as follows :
Defining a "highland" area by zrsc=[300-799] AND rotrsc=[000-399] and the comliment as "plains" area [independent from the other 10 parameters); I looked for top / good / bad results ( >1,8% / 1.2-1.8% / <1.2% muons) :

area / runs# / top# / good# / bad# / av.muon-yield / best

total / 698 / 92 / 411 / 195 / 1.37% / 2.015%
highl / 554 / 92 / 411 / 51 / 1.60%
plain / 144 / 0 / 0 / 144 / 0.49%

Focussing on the highlands, one would avoid some 20% of pointless results without loosing any relevant info.  Those 20% could be invested into deeper/broader scans of the promising area.
Does your database with more than 120000 runs confirm my simple evaluation ?
Would you consider such a "turbo" search worthful enough to integrate within next program redesign ?
Orbi-tel
2002-05-23 15:10:13
Do we have to wait for a mod to approve attachments before we can see them?
Stephen Brooks
2002-05-23 15:11:28
Well I'm not going to approve IMAGE attachments.  That's foolish.  He can upload the images to HIS OWN webspace and then use the "img" tag to put them in his posts...

(edit) - Image attachments are now not allowed.

(edit#2) - Well that's a bit dim.  The board deletes the messages as well as the attachments.
Chris Johnson
2002-05-23 16:29:55
OK.  Here are some graphs from my set of data (c. 850 runs).

The rotsrc graph shows a clear advanage towards values between 20 and 50, which is where the program has optimised.



The zsrc graph hasn't really got any clear peaks - perhaps slightly higher in the middle.  The program has optimised in two areas here, and the high number of samples account for the apparent double sharp peak.



I was going to do this in 3D so that I could actually see what was going on more easily - if I have time I'll write a viewer that allows plotting of %yield against any two parameters spacially, and perhaps a couple controlling colour as well.
Pascal
2002-05-23 22:17:33
@Chris: If you wanna have some other results for your test, please tell me.

___________________________
1: Athlon TB-C, 1.2 GC/s, 256 MB DDR-RAM, Erazor x², ADSL-Flatrate, NIC Intel, Win 98 SE Mainboard MSI-6380 Rev.  1
2: Pentium III, 600 MC/s, 256 MB RAM, NIC Intel, Win 98 SE
Chris Johnson
2002-05-24 09:51:47
I've written a program (for Windows) to display coloured 3D scatter graphs of the percentage muons result against various input parameters for the accelerator design.

It's available at http://www.chris-j.co.uk/resultsviewer.zip. I wrote this fairly quickly so I can't guarentee it bug free - I haven't tried it on a very large results.dat, for instance, but it seemed stable here.

In my set of results, the plot of s4f against d1l is interesting in that the program has optimised in a "C" pattern, looking rather like a spiral staircase.  This shows that at the horizontal section at the top of the C, the muon results decrease with an increase in X, but at the bottom, they increase.  This has been the only instance that I have found where the parameters are so dependent.

As gogomaus suggested earlier, zsrc and rotsrc are the parameters that generate the most obvious trends.

It would be interesting to see if anyone else gets this pattern too - certainly if you do, you're more likely to understand what on earth I'm going on about.  wink

In reply to Pascal's comment, I would be interested in seeing a larger results set and several more independent (i.e. not using top100) sets.  If you have one of these that you'd like to send to me, I'd be grateful for them - chris@chris-j.co.uk.
Pascal
2002-06-16 01:58:48
are there any new developments?

___________________________
1: Athlon TB-C, 1.2 GC/s, 256 MB DDR-RAM, Erazor x², ADSL-Flatrate, NIC Intel, Win 98 SE Mainboard MSI-6380 Rev.  1
2: Pentium III, 600 MC/s, 256 MB RAM, NIC Intel, Win 98 SE
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17016000 accesses.