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: 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: 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: 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. 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 |