Checking muPC Input Mode

[AndrewEdmonds11]

One of the tasks in issue #46 is to check the "muPC" input mode of g4sim.

The first thing I have realised is that I was calculating the fraction of stopped muons like so:

fraction stop = (n_stopped_muons_in_target) / (n_input_muons)

when the data calculates it with n_muons_in_muSc instead of n_input_muons. In a short 500k run these were 392000 and 500000 respectively (approx 20% difference) which does invalidate my validation.

Anyway, I've set some of the volumes in the beamline to be monitors and added a few more monitor planes.

Here is a plot of the z-position (y-axis) vs the volume name (x-axis):

Here the z-axis is the number of muons in that volume, so projecting down to the x-axis we can see how many muons are in each volume:

(MuSCA has a hole in it so that explains why it has so many fewer muons in it)

Something I'm unsure of is that it looks like the number of muons lost at MuSC is the same as in MuSCA (the numbers don't match up exactly). I've been thinking that the MuSC and MuSCA are the same size but MuSCA has a hole in (this is what's in the simulation). Looking at the verbose output of a very short run, it seems that muons go through either the MuSC or MuSCA.

Now, plotting the momentum against the volume name we have the following (NB log scale):

Here we can see we got a small (~5 MeV/c) drop going through the MuSC and as we travel down the beam port we see a gradual spread downwards, presumably from muons scattering around the walls of the port. Does this make sense to others? Are the drops too large?

Next Steps

• check what's going on with MuSC and MuSCA
• check that the drops in momentum aren't too high

[jrquirk]

I've been thinking that the MuSC and MuSCA are the same size but MuSCA has a hole in (this is what's in the simulation).

I believe the muSc is supposed to be thinner than the muScA, though the X/Y dimensions I think are the same. I don't know if the thickness is what you meant by size.

Looking at the verbose output of a very short run, it seems that muons go through either the MuSC or MuSCA.

Does this mean most that go through the muScA do not go through muSc?

[AndrewEdmonds11]

I don't know if the thickness is what you meant by size.

By size I meant height/width. The thicknesses are different in the simulation.

Does this mean most that go through the muScA do not go through muSc?

Yes, so I think there's something funny going on

[AndrewEdmonds11]

Yes, so I think there's something funny going on

Looking at the verbose output a bit more, I'm not so worried now because any muon going through the muScA is stopping there.

This probably makes sense since it is thicker than the muSc and would make sense from an experimental point of view (you would try to stop anything hitting the muScA).

[AndrewEdmonds11]

So one of the reasons to check this mode was because of the different shapes of the stopping depths in Al100:

Nam's

and mine:

However, running today, this difference has disappeared (500k input mu- and SF-1.12):

I guess this is because of reducing the step size.

However, there is still the normalisation differences. Running a 500k event run (Al50, SF-1.07) shows that the original generator gives far fewer muons in the muScA (NB the volumes are not ordered in z but by their first occurance in the tree):

Looking at the numbers for these Al50 runs:

N	Original Mode (Nam)	MuPC Mode (Andy)	Data
input muons	500000	500000	N/A
muons in MuSC	475421	391666	N/A
muons in target	102668	68015	N/A
muons stopped in target	63787	35008	N/A
fraction stopped	0.134	0.089	0.06

So neither of them are correct... I'll look into the assumptions that we made for the muPC mode and see if I see any errors.

[AndrewEdmonds11]

So I've looked into a couple of things that didn't end up being helpful:

• checked that we are generating negative px and py (may have been a stupid coding problem)
  • we are
• made sure that we rescale total momentum
  • Before, I was generating pz based on the MomAmp and MomSpread, calculating px and py by multiplying pz by 0.033 or 0.11 (see my presentation at the collaboration meeting) which would make the final momentum slightly higher than it should be)
  • This was a 1% effect.

One thing I've found which does change things quite a bit is that we seem to think that the 3% momentum spread is the FWHM (see issue #42). Why do we think this? I've tried Googling but can't seem to find any information.

Anyway, I decided to see whether this would make things better in muPC mode so I set MomSpread to 29.96*0,03 = 0.8988 and did a 500k run on Al50 (NB this table can be compared to the one in the previous comment):

N	MuPC Mode (with 3% = 1 sigma)	Data
input muons	500000	N/A
muons in MuSC	392178	N/A
muons in target	60548	N/A
muons stopped in target	21705	N/A
fraction stopped	0.055	0.06

which is closer than it was before. Just throwing it out there....

[AndrewEdmonds11]

Any views on this? In particular I'd like to know why we think the 3% momentum spread is FWHM. Is this a standard definition?

[jrquirk]

This has an example of when FWHM is expressed in %, but the numbers don't match up I think because the site hasn't been updated. Also it is standard because the FWHM works on many types of distributions. Sigma only works on ~Gaussian ones.

[AndrewEdmonds11]

Thanks, John. I'll look for something else that might explain the discrepancy then.

[AndrewEdmonds11]

Ok, I've made some progress with this and managed to tune this input mode to match the percentage of muons stopping in the Al50 target by changing the thickness of the MuFoil volume from 0.075 mm to 0.02 mm.

This volume is placed in the MuTrigger volume (the volume that contains all the muSc/muPC etc.) 43.8875 mm upstream of the centre before the muSc and muPC.

I'm not sure if the MuFoil was ever measured or if the 0.075 was just a rough guess. Let me know if this is not the case.

For Al50, I got the percentage of stopped muons being (6.47 +- 0.04)% and in the data it's (6.4 +- 0.1)% Unfortunately, the Al100 run I did gave me 13.7% stopped muons when the data says that we had 11.3% so there may be a few more tweaks to make.

Anyway, here's some more details of the runs I did with some comments from me. They were all 500k muon runs in Al50.

commit	Initial Muon Position (relative to centre of MuTrigger) [mm]	No. of Stopped Muons	No. of Muons in MuSC	% of stopped muons	Comment
59a14d7	-31	17297	499992	3.46	location of the MuSC
34b0d67	-32	18088	499993	3.62	just before the muSc
b542625	-40	17382	404310	4.30
be5c82f	-45	47656	403675	11.58
37fbe1b	-43	18070	404015	4.47	just after MuFoil
a7c4a30	-44	47730	403777	11.82	just before MuFoil

At this point, I thought that the thickness of the MuFoil meant that the muons were losing too much energy as they passed through it and so were more likely to stop in the target so I started changing its thickness (all positions are 44 mm behind the centre of the MuTrigger):

commit	Thickness of MuFoil (made of mylar) [mm]	No. of Stopped Muons	No. of Muons in MuSC	% of stopped muons	Comment
a7c4a30	0.075	47730	403777	11.82	same as last entry in the table above
8fe3956	0.05	39103	403946	9.68
aa651ec	0.025	282720	403999	7.11
1c724f1	0.01	22247	404165	5.50
51e24e2	0.02	26164	404210	6.47	matches the data value of (6.4 +- 0.1)%

[jrquirk]

The MuFoil is the Al wrapping on the upstream scints? If so I can ask a person who works on MuSun sims.

[AndrewEdmonds11]

I don't think so. It's just a 100x100x0.075mm^3 sheet of Mylar placed before the MuSC. Regardless, if you can get some more information from the MuSun people that would be very useful :)

[jrquirk]

So it's a fictitious degrader inserted there to help reproduce the data in the simulations as far as we know?

[AndrewEdmonds11]

Don't know. I assumed it exists in reality but that we may be a bit uncertain of the thickness.