stephenbrooks.orgForumMuon1GeneralBest linacs and new lattice Linac900Ext6tc2
Username: Password:
Search site:
Subscribe to thread via RSS
Stephen Brooks
2010-10-12 14:58:27
I made a list of the best linac designs (in decreasing order of score) for our 900MeV criterion.

3.891455 (9675.3 Mpts) [v4.44d] <Linac900Removable6c2> #time=94217; by boinc (Boinc Wrapper)
3.684663 (8418.2 Mpts) [v4.44d] <Linac900Removable6> #time=89994; by [DPC]NoizyCows~Bjorga
3.670822 (8389.4 Mpts) [v4.44d] <Linac900Removable12> #time=91894; by boinc (Boinc Wrapper)
3.206615 (9482.1 Mpts) [v4.44d] <Linac900Removable8c2> #time=105247; by boinc (Boinc Wrapper)
3.068246 (8176.2 Mpts) [v4.44d] <Linac900Removable3> #time=102278; by boinc (Boinc Wrapper).txt.RR
2.922755 (6006.5 Mpts) [v4.44d] <Linac900Removable1> #time=87897; by [DPC] Team ColdFusion~SandStar
2.670893 (9206.6 Mpts) [v4.44d] <Linac900Ext8d2> #time=97660; by boinc (Boinc Wrapper)
2.605366 (6174.2 Mpts) [v4.44d] <Linac88MHz900MeV1> #time=85881; by [Crunchers Inc]mgpower0
2.522951 (12801.0 Mpts) [v4.44d] <Linac900Ext10d2> #time=107766; by [KWSN] Grizzly
2.481781 (6466.5 Mpts) [v4.44d] <Linac88MHz900MeV6> #time=97280; by [TA]amd.borg
2.410177 (7422.5 Mpts) [v4.44d] <Linac900Ext10d2_axial3> #time=107766; by TOMAZ
2.280941 (6266.7 Mpts) [v4.44d] <Linac900NoGaps1> #time=85979; by [TA]amd.borg
1.432695 (5169.2 Mpts) [v4.44d] <Linac900Ext6d2> #time=99994; by [DPC]Universal Creations~Darkbartje
0.789847 (3496.0 Mpts) [v4.44d] <Linac900Ext9d2> #time=95613; by boinc (Boinc Wrapper)
0.781853 (3698.6 Mpts) [v4.44d] <Linac900Ext7d2> #time=99234; by [ARS]GOD

Noticably it's the "Removable" lattices that have done best.  So I'm creating a new Ext lattice that reverts one feature (the RF phase range) back to the "c2" setting rather than the "d2". I've also increased the maximum simulation time from 2 to 3.5 microseconds because our current Linac900Ext10d2 was hitting up against the time limit because it made the linac so long!
Stephen Brooks
2010-10-12 16:15:11
[TN]runesk was the first to appear on the new lattice (I suspect this was a manually-provoked results flush, unless the client was right at the end of a results.txt batch when the new lattice updated).
2010-10-12 18:31:23
I've sent 3 results back, and also put it on the facebook page for Muon1
[Edited by K`Tetch at 2010-10-12 18:31:58]
Stephen Brooks
2010-10-13 11:02:01
[DPC] Xanathorn has now made it positive (0.129377%)
2010-10-14 21:54:59
As Stephen noticed, theres a lack of linac in the current designs.

We did some talking last night and got some interesting designs that are positive, and holding about 0.38% right now, but are long (0.380983 (8213.3 Mpts) [v4.44d] <Linac900Ext6tc2> {0FAF160B41BAEC8C924982F3} is my best to date)

I have a linac, but it's not very efficient.
Stephen Brooks
2010-10-14 23:44:47
Ktetch you just changed the vertical scale on the Yield vs. Mpts plot because your design has a massively higher Mpts for roughly the same yield!
2010-10-14 23:46:47
I gotta be special.  No, really, mine has such a high workload for the yield, because mine actually HAS a linac.  takes more to simulate particles over 100m than over 5 after all
(It's here btw for those interested)
[Edited by K`Tetch at 2010-10-14 23:47:55]
2010-10-16 04:09:32
I've got 2 dozen OLD <Linac900Ext6d2>results. 

Would I be able to feed them into the new Lattice by copying to a seperate file change to the New Lattice <Linac900Ext6tc2> and marking as TEST and then feed them in with the -q switch.

Much like the Linac900RemovableX Converter.
2010-10-16 17:36:57
A lot of the variables are different.  I did something similar to this a day or two ago, and thats the high workload designs I've been running for the last few days.
Stephen Brooks
2010-10-16 19:00:10
Cameron - That should work to some extent, but I'd suggest going into the Linac...10d2 lattice not the new ...6tc2 one.  The Linac...Ext... lattice have quite a lot of variables in common with each other, though not all, but the "d2" and "c2" use different RF phase definitions, so aren't directly compatible.  ...6d2 and ...10d2 ought to have a lot in common, though.
2010-10-16 22:17:13
Right so No, for 6tc2. Well at least I asked before I did it.
Stephen Brooks
2010-10-17 01:57:48
Well, you can try but it will probably just produce a lousy result.  Seeding 10d2 (with 6d2) on the other hand, would be interesting.
Stephen Brooks
2010-10-20 20:05:26
I believe TOMAZ's recent 0.820795% result (a more than 0.1 jump) is the first with a nontrivial linac.
2010-10-21 03:53:20
Of course !  I got some ideas how the linac should look so I did extensive manual design and tested it... just fooling

I noticed ktech's high mpts result in a graph so I just put it in a blank result.dat.  After a while I also queued two samples which where mix of ktechs and the highest result at that time (it was more or less random mix just to introduce more variety).  0.82 was 10th or so result which came out from that .dat, not counting gen=0 ones.

0.380983 (8213.3 Mpts) [v4.44d] <Linac900Ext6tc2> #time=107855; by ktetch
2010-10-21 12:30:34
I've now reported a result with 1.01% and I've got a 1.10% in queuecli.  Making progress fast! 
2010-10-21 12:42:02
DAng, and I thought I was suddenly doing well

t = 2167.49ns (26/65799 particles) 2300.0 Mpts
Initiating quarantine of score 0.9324
(best rechecked score for Linac900Ext6tc2 is 0.51949)
Stephen Brooks
2010-10-21 21:52:56
Now [KWSN] Grizzly 1.463784% - a more than 0.25% jump. 
2010-10-24 15:35:57
We've reached 2%
Stephen Brooks
2010-10-24 18:19:54
Well done!  This seems to be faster than the previous optimisation.
2010-10-25 15:22:44
yeah, a lot faster.  I'd like to think the private designs you helped me with had something to do with it, albeit after tomaz put some real power into it.  However, it's going fast indeed.  I'm at 1.2% and that's just me doing what I always do; 10d2 I did the same things (some manual designs, NO samplefiles), and i'm at 0.7% after 2 years. 

Either I got it just right, the procesing power is finally ramping up, or we got lucky in how it ran.
Stephen Brooks
2010-10-25 15:57:41
I'm hoping it's another option: somehow the way I've specified the RF phase ranges in the "c" type lattices is more amenable to optimisation than the "d" type lattices (increasing the time limit so it didn't cut long linacs off probably isn't hurting either).
2010-10-25 17:41:33
BAH!  You're always smashing my dreams Stephen, you big meany!
Stephen Brooks
2010-10-25 19:52:56
2.2 on this versus 2.6 on the old lattice.  Is it going to overtake?  It seems that C is better than D, what we don't know is... Y
[DPC] Mr. Aldi
2010-11-13 11:34:59
w00t @ the jump in 6tc2!

And now I have a result of 3.64 % waiting to be uploaded

It seems that this design was just generated with the optimizers after some help from Tomaz to get the project searching around the 2500 Mpts region
[Edited by [DPC] Mr. Aldi at 2010-11-13 11:40:45]
[DPC] Mr. Aldi
2010-11-13 11:35:53
W00t w00t, my result has 3059 Mpts xD

I had 3 lousy 3000 Mpts results (0,4%) in the sample files and nothing more.  Results.dat was empty.  Could muon1 had combined those (allthough samplefile results were lousy?)

I took the 3,47% and put it in queuecli.txt.  Then I let muon1 run with switch /10. So muon1 really only had best result until now + the 3000+ Mpts results to work with
[Edited by [DPC] Mr. Aldi at 2010-11-13 11:41:37]
[DPC] Mr. Aldi
2010-11-13 12:30:48
My 3059 Mpts result clearly combined a sample o,4% in the 3050 region with the 3.47% result of 2741 Mpts.  There are more differences between my 3059 Mpts result and the one of 2741 Mpts than when compared to a 0,4% yield result in the 3050 Mpts region.

Good to know how the sample file is used
2010-11-13 19:05:22
That is an impressive jump!
[DPC] Mr. Aldi
2010-11-15 07:23:29
t = 3401.36ns (1/68768 particles) 2907.6 Mpts
Initiating quarantine of score 3.92753
(best rechecked score for Linac900Ext6tc2 is 3.89024)

Stephen Brooks
2010-11-16 12:25:55
The current best now beats the old best result (3.891455) from LinacRemovable6c2, so I've added comparisons to that on the stats screen.
[DPC] Mr. Aldi
2010-11-16 18:26:01
Do you have the lattice-file Linac900Removable6c2 for me?

I want to see if I can improve it as there seems to have been no search at all in the 3000 Mpts region??

There are a few good results there actually!

Same with Linac900Removable8c2, Linac900Ext8d2 (there is even a 3500 Mpts result!).

If there is absolutely no use for better results, then I just continue on the current lattices of course.
[DPC] Mr. Aldi
2010-11-16 22:57:23
t = 1908.87ns (29/68909 particles) 2918.3 Mpts
Initiating quarantine of score 3.94845
(best rechecked score for Linac900Ext6tc2 is 3.92179)

Just when I thought it was little exhausted
Stephen Brooks
2010-11-17 17:07:23
Is there any pattern in what you're doing that seems to push the %muons higher or does it just seem to be luck?  Some people previously had said that choosing high Mpts results (even if they are not maximal in muon yield) seemed to work well.

The 6tc2 lattice is covering a very similar problem to the old 6c2 but also has a bug fixed where certain long linacs would run into the simulation timeout.  So it's probably best to concentrate on the newer lattice.
[DPC] Mr. Aldi
2010-11-17 18:25:44
I use fuzzy logic

The 3.90 was produced accidently.  I do not remember that I put 0.4% 3050 Mpts results in the sample file.  I just wanted to improve the result Boots posted with an empty sample file using -/10 and afterwards select interesting results to recalculate officialy.

It is clear that letting Muon1 combine any high Mpts result with a high yield result could produce monster designs So feeding the sample-file with only high Mpts designs could help.  Otherwise all not manually managed clients just stay in one Mpts-region (clearly visible on the Mpts vs yield plot).

Before I also tried to improve the 3050 Mpts result alone but it kept being stuck @ 0,4%.

@ old linac, I will continue to work on current lattices then.

(p.s. 3.94845 gave dissapointing final result)
[Edited by [DPC] Mr. Aldi at 2010-11-17 18:27:19]
Stephen Brooks
2010-11-19 17:19:04
It's gone above 4% now - did you do anything special this time?
[DPC] Mr. Aldi
2010-11-19 19:21:08
[DPC] Xanathorn posted a different design with tantalumrodr=000;tantalumrodz=246; @ 3.95 using trialType Extreme.  Not long after that [KWSN] Grizzly delivered his 3.99 result (I now see this is not a "tantalumrodr=000;tantalumrodz=246;" result).  Anyways, to a database of 1700 fast results I added Xanathorn's result on line 3400

I then ran muon1 -/10 with:

TrialType ratios: Extreme=30. All others @ 0

after 50 results I seem to have added Grizzly's result (had probably no influence: the designs (Grizzly's and the first result to cross the 4%) are different on 80% of the parameters).

After another 40 simulations it had a initial score above 4% but the fast running client only found 3.902805 (1369.6 Mpts) after 5 runs.  Because of the 5 runs, I put it in a normal muon1 client and it gave the curreny high

muon1 does not really combine 2 results?  Or at least trialType Extreme doesn't?  Then putting Xanathorn's design into an empty result.dat would have given the same solution within 200 results (not going to test that ) using only Extreme.  I did not do this as I also wanted to check other results with the Extreme (I guess I wanted to, that's the fuzziness of the logic )
[Edited by [DPC] Mr. Aldi at 2010-11-19 19:22:36]
Stephen Brooks
2010-11-19 19:53:31
Crossover, Interpolate and Extrapolate combine two results, the rest take one result and modify it somehow.

[edit] This has given me an idea.  It seems you're able to get ahead of the "herd" by running an accelerated (but less accurate) -/10 switch client and then redoing its better results with a normal client.

I wonder what happens if you run the fast client on (say) half your CPU cores and have a normal one (in another directory) running on the other half, with an hourly scheduled task that copies results.dat from the fast one into the samplefiles folder of the slow one?  Users with that setup could automatically get this sort of boost to yield (though fewer Mpts credited).
[DPC] Mr. Aldi
2010-11-19 20:56:14
Ok, thanks.  That is useful to know.

@edit.  Thought of some larger scale use of this also.  The problem here is the accuracy.  Sometimes good results post a lot larger yields on the first run, while others do the opposite.  This fast client should also not calculate 5 runs when it finds a new high.  It will be rechecked anyways.  If you would select 0,2% under the current high to be rechecked with the normal client you are safe.  Sometimes it can be less.

Also an important feature is that results that have the exact same yield, will also give the exact same result if you would do a full run on both.  So say once you checked a result from the fast client of 3.729666% at normal speed (e.g. giving 3.812039%), you can use this yield for every other 3.729666% result (as it is just a minor edit to the already rechecked configuration, which has no influence at all).  Especially when 3.812039% would be the current high for the lattice and the first seed would give a result higher than the current high, which makes normal clients to go in recheck mode every time, is this an advantage.  You already know it will give you 3.812039% Of course not when just generated by a normal client because this is a mean value and it doesn't know the value of 'seed 0' anymore.

I hope you can follow me


My approach is to copy good solutions from the fast results.dat -> queuecli.txt.  I have already some results.dat files from fast clients with a potential good result in it.  You could try to see how long it takes the normal client to find it.  Otherwise you better just select it and recheck it.

Another problem is that after a certain time a fast client might get stuck as some results that seem to be good to the fast client are in fact not that good at all.  No problem for me yet as I manually monitor them.
[Edited by [DPC] Mr. Aldi at 2010-11-19 21:07:03]
[DPC] Mr. Aldi
2010-11-19 21:36:45
Oh when I created 3.92%, the 'mother design' was created in the fast client with crossover which gave 3.60%. It was crossed with the earlier mentioned 0,4% solution @ 3050 Mpts and Boots' result.
[DPC] Mr. Aldi
2010-11-19 22:05:22
And here an extreme example of first result which almost 0.30% less in a client with -/10

3.719666 (265.0 Mpts) [v4.44d] <Linac900Ext6tc2>


4.007751 (14407.3 Mpts) [v4.44d] <Linac900Ext6tc2> #time=108837; by AETiglathPZ [US-Distributed]
[DPC] Mr. Aldi
2010-11-20 23:07:31
t = 2174.15ns (1/69096 particles) 2845.4 Mpts
Initiating quarantine of score 4.13934
(best rechecked score for Linac900Ext6tc2 is 4.07851)

I saw new design with tantalumrodr=000;tantalumrodz=261;. After running 200 times Extreme on it a new good result with tantalumrodr=000;tantalumrodz=282; and ran the other generators (not the crossing generators) on this result, after 75 times MuOne gave the result above.
Stephen Brooks
2011-01-14 11:15:07
Seeing as Linac900Ext6tc2 has made a new entry at the top of the best linacs in the first post (and it seems to have stopped improving), I'm going to try some variations.  Replacing it with Linac900Ext7tc2 today.
Stephen Brooks
2011-01-19 17:46:01
Didn't take that one very long to overtake Linac900Ext10d2!
2011-01-19 19:19:43
Yeah, this one is moving pretty quick.  Ive got this in the pipeline right now.

3.113581,3.100759 (5427.9 Mpts) [v4.44d] <Linac900Ext7tc2>
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel RSS feed

Site has had 25877045 accesses.