stephenbrooks.orgForumMuon1Bug ReportsPercentage reporting problem in the program
Username: Password:
Search site:
Subscribe to thread via RSS
Jwb52z
2002-09-02 08:48:25
I know for a fact that when my last simulation ended, in the GUI interface the muon percentage said something around 2.7x percent.  When I looked in my results.txt, the result said 2.4x. Something is definitely wrong.  I also had a problem where I restarted the program after all the particles EXITED the chicane and the percentage then was about 2.7x that time too.  The problem then was that after the restart the percentage dropped for no reason that I could see to .363 percent.  I don't know how this problem will be verfied, but I know something is wrong.
Stephen Brooks
2002-09-02 10:51:54
One of the GUI counters says "Beam Retained", whereas the figure in the results file is the number of muons retained, so exculdes pions.
Michal Hajicek
2002-09-03 08:57:13
I also restarted at about 290 ns, and got 0,000000 % (cmdline, about 37-38000 particles total I think).  So my question is whether the autosave file contains number of particles that already hit end of this apparatus, if not-restart will cause muon percentage decrease.
And Stephen, I was also a bit disappointed when your manually created result appeared at the website (like gogomaus).  But I was wrong.  Your situation explanation was good, and now, the main good news is that your manually created result was not the best possible so it has (and had) some sense to participate on your interesting project.
Have a nice day.
Michal Hajicek
Stephen Brooks
2002-09-03 09:02:05
The code says that the autosave file does contain all particles, but it stores less data for the inactive ones, as information like decay times are no longer relevant.  I'll have to check the auto-save late on in the simulation to make sure it doesn't mess things up.  For instance, could it be that having zero active particles is causing the saved files to be wrong?


"As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline"
Jwb52z
2002-09-03 11:54:02
See Stephen, I told you something was wrong.
David Bass
2002-09-03 17:17:11
Does the simulation ignore particles that are still alive when the 300ns is up?

I've just looked at the end of a simulation (started in the background client and finished in the graphical client).  This showed a muon retained figure in the region of 2.6%, but stored 2.43% in the results file.  When the simulation ended there were around 500 "stray" particles - mostly muons, of course - still flying around, either coiled inside the solenoids or escaped round the barriers in the chicane.  500 from a total run of around 59100 looks like 0.8% to me, so the figures still don't add up.
Stephen Brooks
2002-09-04 02:03:30
500 out of 59100 is not 0.8% when the particles have different "weights" associated with them, as is the case here.  The particles that fly off really should have been stopped by some sort of barrier, but there don't seem to be enough of these to warrant doing much about it.  The ones that are stuck inside the solenoids will be well outside the bunch that we want, so are essentially lost.


"As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline"
David Bass
2002-09-05 06:51:08
OK - so the 500 particles remaining alive in the simulation I looked at had low weights - amounting to about 0.17%. I assume, therefore that the answer to the question is that those particles still flying around at the ned of a simulation are in fact ignored in the results - which makes sense.

I think that the 500 strays amounted to less than 8% of the total particles "captured" by the circular target, but it's not easy to tell just by looking.  Whether that is considered a signficant overhead or not is entirely up to you - it amounts to several minutes extra processing after the interesting part of the simulation is completed.
Jwb52z
2002-09-15 19:56:50
The problem showed up again.  The Muons retained line in the program said 3.070 and the end of the simulation that ran after inserting the newest best250. The results.txt file says 2.8 something.  I still think that there's a bug there.  It should display the same percentage on that line as it does in the results.txt.  The only thing I can think of is that some pions are being misread as muons.
Stephen Brooks
2002-09-16 02:04:27
Looking at the source-code, I find:
		for (pn=beam.p;pn<beam.pM;pn++)
if (pn->s==Muon) if (pn<beam.pm || pn->state==Finished) p1+=pn->wt;
sprintf(str,"Muons retained: %.3f%%",p1/ps);


So the "Muons retained" figure is for finished-muons, plus muons still in the accelerator.  Some muons have too little energy and end up whirling around the early parts of the accelerator (going nowhere) and a few others manage to escape from the chicane and try heading off to infinity.  So in your example 2.8% had actually hit the target and another 0.2% were still in the simulation (so 'retained', technically) but had little or no hope of hitting the target.


"As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline"
dudi
2002-09-19 03:25:12
There must be really a problem with the restore or save function.  If I restore at a simulation time later than around 150ns the result always is 0.000000%
For example this happens for this set of parameters:

zsrc=550;rotsrc=034;s1f=995;s1l=723;d1l=005;s2f=997;s2r=684;s2l=988;d2l=422;s3f\
=996;s3r=983;s3l=499;d3l=007;s4f=993;s4r=972;s4l=640;d4l=007;s5f=995;s5r=962;s5\
l=640;d5l=007;s6f=997;s6r=486;s6l=632;d6l=393;s7f=996;s7r=941;s7l=642;d7l=390;s\
8f=994;s8r=931;s8l=634;d8l=007;s9f=998;s9r=923;s9l=642;d9l=388;s10f=993;s10r=69\
8;s10l=499;d10l=367;s11f=993;s11r=899;s11l=643;d11l=007;s12f=993;s12r=888;s12l=\
652;d12l=386;s13f=992;s13r=880;s13l=642;d13l=000;s14f=993;s14r=871;s14l=649;d14\
l=007;s15f=992;s15r=857;s15l=650;d15l=383;s16f=993;s16r=842;s16l=642;d16l=005;s\
17f=993;s17r=836;s17l=642;d17l=006;s18f=992;s18r=831;s18l=641;d18l=006;s19f=993\
;s19r=814;s19l=642;d19l=002;s20f=992;s20r=611;s20l=497;d20l=377;s21f=992;s21r=7\
95;s21l=642;d21l=007;s22f=990;s22r=783;s22l=650;d22l=000;s23f=992;s23r=772;s23l\
=642;d23l=007;s24f=826;s24r=761;s24l=642;d24l=006;s25f=987;s25r=547;s25l=642;d2\
5l=005;s26f=968;s26r=739;s26l=642;d26l=408;s27f=994;s27r=729;s27l=499;d27l=397;\
s28f=981;s28r=719;s28l=640;d28l=006;s29f=993;s29r=710;s29l=643;d29l=398;s30f=59\
8;s30r=691;s30l=498;d30l=000;s31f=451;s31r=682;s31l=642;d31l=007;s32f=990;s32r=\
677;s32l=642;d32l=007;s33f=989;s33r=666;s33l=645;d33l=007;s34f=992;s34r=655;s34\
l=642;d34l=378;
0.000000 (55127 particles) [v4.21b] {B75C17BC}

My PC was working for at least two hours on this simulation before I turned it off.  After restarting the simulation time was 250ns and less than one minute later ist was completed with a score of 0.000000%, but normally 2-hours-calculations result in 1.xxxxxx or 2.xxxxxx -results

Yours sincerely
Jürgen

[This message was edited by Stephen Brooks on 2002-Oct-12 at 20:24.]
Stephen Brooks
2002-09-19 07:20:00
The late save/restore is now a known issue
AySz88
2002-09-19 16:25:00
Um...ducks?
wirthi [Free-DC]
2002-10-11 12:11:22
Hi,

exactly this problem still seems to exist - in the Linux Client!  I am not using the "final", but the Beta 3. Nevertheless, according to http://www.project4009.de/ehome.htm, the final doesn't fix that bug!
[Muon.FG]7F4
2002-10-11 15:27:27
@wirthi

Of course I didn't fix this bug. 

Just follow the link on my hp/take a look in my announcement of the final version in this forum - I only fixed the bug described in thread

Minor (?) De-sync of numbers

of this messageboard
Ronny
wirthi [Free-DC]
2002-10-12 00:04:36
quote:
Originally posted by [Muon.FG]7F4:
@wirthi

Of course I didn't fix this bug. 

Just follow the link on my hp/take a look in my announcement of the final version in this forum - I only fixed the bug described in thread

Minor (?) De-sync of numbers

of this messageboard
Ronny


yes, that was exactly what I critisiced (that you didn't fix that bug).  But I'm sorry I missed the fact that Stephen knows about that issue, so I guess it is ok for now ...
Stephen Brooks
2002-10-12 13:23:18
It appears that the restore-near-end-of-simulation issue is fixed if I use the non-compressed autosave format I had prior to version 4.21a. Ronny might decide to use that mode for his Linux client for now.  I'll look to see if I can work out what's wrong with the compressed format.  Meanwhile, this issue is probably most serious for those of you who start and stop your simulation a lot.  On the bright side, it never reports an erroneously _high_ value, so does not disrupt the project as a whole.


"As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline"
[Muon.FG]7F4
2002-10-13 04:14:59
Ok, I use the non-compressed autosave format in the new linuxclient version.  Of course, this leads to a larger autosave-file (12-13Mb for 60000 Particles) and the new autosave files are incompatible with older ones.  It is necessary to delete the existing autosave file when replacing the linuxclient version.

Ronny
Stephen Brooks
2002-10-14 13:37:17
Stephan Hermens just worked out how to fix that.  The pn->state variable is sometimes -1 because I defined it to have that value in an enum.  So fputc saves it as 0xFF and fgetc retrieves it as +255 not -1 because fgetc returns an int form of the unsigned char version.  Insert
inline int fgetsc(const FILE *in)
{ // fgetc but returns the value of the SIGNED char
int ret=fgetc(in);
if (ret&128) return ret-256;
else return ret;
}
Into rnd.c and replace the two instances of fgetc in beamops.c function readbeam with fgetsc instead.


"As every 11-year-old kid knows, if you concentrate enough Van-der-Graff generators and expensive special effects in one place, you create a spiral space-time whirly thing, AND an interesting plotline"
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io RSS feed

Site has had 25159403 accesses.