stephenbrooks.orgForumMuon1Generalkilling off useless particals
Username: Password:
Search site:
Subscribe to thread via RSS
Hydrox
2007-12-12 19:14:27
i just ran muon in grafic mode.  What i saw was lots of wasted CPU time.  At the near end of the simulation there where about 2200 particals left.  But only 1 (in words "one" partical was in the tunnel on the way to the goal.  The rest of the particals where flying useless at the beginning of the tunnel.  I uploaded 2 screenshots and the autogfx.sav so you can see for yourself.  I believe these particals can be killed without any harm done and so speedup the simulations.

http://www.schnuckland.de/muon/muon1_1.JPG
http://www.schnuckland.de/muon/muon1_2.JPG
http://www.schnuckland.de/muon/autogfx.sav

[RKN]Hydrox
Hydrox
2007-12-12 19:15:02
I forgot, I ran muon 4.44
Stephen Brooks
2007-12-12 19:31:09
Hmm, they shouldn't be escaping into space like that.  I'll see if I can fix this tomorrow.
Zerberus
2007-12-13 04:42:53
Yeah moun1 4.43d was leaking also, I guess I should have reported that.
Stephen Brooks
2007-12-13 09:44:45
I don't get leaks on the simulations I've run in graphical mode.  Is it only some genomes or locations of the rod that do it?

If this is the case, can you e-mail me the results from the leaking simulations so I can try and run them myself.  It may be that that orange collar/annulus I've been using to conditionally block particles that leave the channel around the back behind S1 needs to be lengthened.
Zerberus
2007-12-13 10:11:34
Well, muon 4.43 leaked a few particles, but 4.44 is much worse.  The particles go right through the Backend component.  The screenshots above don't show it clearly.  Maybe there is something wrong concerning proximity data again (there was a similar problem with 4.43 but only after loading).

Not all simulations leak so bad, but there are always particles escaping.

I'll post the setup of a simulation triggering this behavior as soon as I encounter one.  Did you get the autogfx.sav Hydrox posted?  Doesn't it contain the setup?
Zerberus
2007-12-13 10:31:13
tantalumrodr=000;tantalumrodz=000;d1l=000;d2l=000;d3l=000;d4l=000;d5l=000;d6l=000;d7l=000;d8l=000;d9l=000;db1l=000;decaycells=999;pd1=000;phaserotcells=009;prf1p=999;prf1v=999;ps1f=999;ps1l=999;s1f=999;s1l=999;s2f=999;s2l=999;s2r=000;s3f=999;s3l=999;s3r=999;s4f=000;s4l=355;s4r=000;s5f=000;s5l=999;s5r=000;s6f=000;s6l=000;s6r=957;s7f=000;s7l=000;s7r=999;s8f=999;s8l=000;s8r=000;s9f=999;s9l=999;s9r=000;sb1f=999;sb1l=000;sb1r=000;#gen=8;
-0.543434 (330.0 Mpts) [v4.44] <PhaseRotEb1> {D1612CB2D6A61D4EB19B8ECE}

Is that what you need?
Stephen Brooks
2007-12-13 12:36:20
I changed the collision detection in this version, it's meant to be more accurate, but as I've been fiddling with the code for a year between releases there's probably something that's got broken.  I'll investigate that.
Stephen Brooks
2007-12-13 15:04:10
Ah, think I've got it.  It was a bug in the lattices not the current version: the (orange/brown) back cylinder was solid, but not the annulus!  So I've replaced all the lattices with -a versions, which I'm also requiring be pure v4.44 results as there have been slight changes in the yield due to the new collision detection.  I've left one 4.43-compatible lattice in there for people who haven't upgraded.
RGtx
2007-12-13 15:49:43
Would you prefer that we start from the beginning?  or, can we seed from earlier results?
Stephen Brooks
2007-12-13 15:56:38
I've seeded the samplefiles with the best of the previous optimisations (just one result), but you can apply whatever seeding you want as well.  The parameters between the corresponding lattices got by adding "-a" should be the same.
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io RSS feed

Site has had 25162902 accesses.