Dear Maarten and Fluka users
just to clarify that indeed muons (and other "heavy" charged particles)
produce e+e- pairs *directly* and not by emitting a real (bremsstrahlung)
photon which then converts into an e+e- pair.
This process exists for electron and positron beams as well, but in their
case it is suppressed wrt bremsstrahlung by a factor ~alpha (1/137)
so it is customarily ignored. For heavier charged particles it becomes
more and more important wrt bremsstrahlung (and both are much less
important than for electron and positron beams). For muons direct pair
production is roughly equal to bremsstrahlung in terms of energy loss
and both dominate over "normal" ionization losses for high energy muons
(how much "high" depends on the Z of the target material).
There is plenty of literature about these processes, but
if you are interested in more details, an old, but good starting
point with useful tables could be CERN Yellow report 85-03 "Energy loss of
muons in the energy range 1-10000 eV" available at:
https://cds.cern.ch/record/158706?ln=en
So, when USDRAW reports an e+e- creation event by muons it is exactly
that, an interaction where the muon has produced an e+e- pair.
You should also sometimes find bremsstrahlung events by muons logged
by USDRAW.
Ciao
Alfredo
+----------------------------------------------------------------------+
| Alfredo Ferrari || Tel.: +41.22.76.76119 |
| CERN-EN/STI || Fax.: +41.22.76.69474 |
| 1211 Geneva 23 || e-mail: Alfredo.Ferrari_at_cern.ch |
| Switzerland || |
+----------------------------------------------------------------------+
On Mon, 24 Sep 2018, Maarten Van Dijk wrote:
> Dear Luigi,
> Thank you for your answer; I have taken some time to think about it, and it
> makes sense. I do have some (small) remaining followup questions.
>
> The thing that was confusing me, mostly, is that the particle setting in
> motion the USDRAW entry is itself also tagged with that ICODE, meaning that
> the muon which is interacting is labelled with ICODE 104: it has just kicked
> off the production of an e+/e- pair.
>
> The missing entry you pointed out in my table was not logged on purpose; I
> limited the ICODEs for which I dump information (since there is always a lot
> happening, and processing the files is difficult). This has since been
> fixed.
>
> There are a few implications; the main one being that I was confused about
> the meaning of USDRAW. It does not give the creation process for a particle,
> it merely tags the LAST interaction in which it was last involved.
>
> My remaining question is this - it has been my impression that the process
> for pair creation would be the muon giving off a gamma, and this gamma
> turning into an e+/e- pair. Am I correct in deriving from the above that
> FLUKA directly produces the pair (which is then, most likely, lost because
> of the energy limit) from the muon?
>
> Thanks in advance for your help,
>
> Kind regards,
>
> Maarten
>
>
> ____________________________________________________________________________
> From: Luigi Salvatore Esposito
> Sent: 16 September 2018 22:54
> To: Maarten Van Dijk
> Cc: Fluka Discuss
> Subject: Re: [fluka-discuss]: USDRAW logging - meaning of ICODE?
>
> Dear Maarten,
> USDRAW is called with the ICODE = 104 after the direct production of a pair
> e+/e- in a Coulomb field by any heavy charged particle at high energy.
>
> The ISPUSR / SPAUSR are at user’s disposal. They are not internally
> manipulated by FLUKA.
>
> It’s difficult to comment more on your table without your input and user
> routines.
> However, in your table the ICODE = 103 (delta ray production) does not
> appear in the column “creation”, but only in the column “parent creation”.
> As consequence, there is a jump in the momentum and in the z-position. I’m
> wondering if this could suggest a problem in your logging procedure…
>
> Best, luigi
>
>
> On 13 Sep 2018, at 10:47, Maarten Van Dijk
> <maarten.van.dijk_at_cern.ch> wrote:
>
> Dear Fluka discuss, Fluka experts,
>
> I have been trying to track the production of high energy muons
> through a 250m long beamline section; and want to ask about the ICODE
> variable as given by the USDRAW entry of the mgdraw.f user routine.
>
> I have set up logging for the parents of muons by dumping information
> (under certain conditions) in the USDRAW routine. By means of the
> stupre.f and stuprf.f user routines, after writing the information at
> a given USDRAW event I then propagate it as parent information for the
> next generation of particles. The beamline I have constructed contains
> several magnets and other material regions.
>
> In the yoke of the magnets, where a return field is present, the muons
> lose energy (as expected). What is unexpected however, is that this is
> logged under ICODE 104 (pair production, as indicated
> byhttp://www.fluka.org/fluka.php?id=man_onl&sub=99 ). I should add
> that I have limited the transport energy of particles at 1 GeV (1
> GeV/c) because I am mainly interested in the higher energy part.
>
> After some post processing of the userdump information, I extract (for
> one event, there are many more) the following chain of information:
>
> mu- found in shashlik
> fluka file, event: 1005 628896
> particle history:
> track ID, (pa track ID), PID, (pa PID), creation, (pa creation),
> momentum, (pa momentum), z_pos, (pa zpos):
> 8 (1) PION- (PROTON ) 102
> (101) 181.345 (399.985)
> 145.342 (-15.26)
> 14 (8) MUON- (PION- )
> 104 (102) 169.634 (181.345)
> 565.079 (145.342)
> 14 (14) MUON- (MUON- )
> 104 (104) 168.221 (169.634)
> 650.757 (565.079)
> 14 (14) MUON- (MUON- )
> 104 (104) 167.316 (168.221)
> 668.168 (650.757)
> 14 (14) MUON- (MUON- )
> 104 (104) 166.076 (167.316)
> 746.069 (668.168)
> 14 (14) MUON- (MUON- )
> 104 (104) 163.459 (166.076)
> 839.058 (746.069)
> 14 (14) MUON- (MUON- )
> 104 (104) 162.431 (163.459)
> 937.07 (839.058)
> 14 (14) MUON- (MUON- )
> 104 (103) 157.557 (162.214)
> 975.983 (941.479)
> 14 (14) MUON- (MUON- )
> 104 (104) 157.531 (157.557)
> 977.15 (975.983)
> 14 (14) MUON- (MUON- )
> 104 (104) 156.499 (157.531)
> 1042.26 (977.15)
> 14 (14) MUON- (MUON- )
> 104 (104) 156.05 (156.499)
> 1069.45 (1042.26)
> 14 (14) MUON- (MUON- )
> 104 (104) 155.343 (156.05)
> 1106.1 (1069.45)
> 14 (14) MUON- (MUON- )
> 104 (104) 151.37 (155.343)
> 1246.31 (1106.1)
> 14 (14) MUON- (MUON- )
> 104 (104) 149.78 (151.37)
> 4203.01 (1246.31)
> 14 (14) MUON- (MUON- )
> 104 (104) 149.258 (149.78)
> 4241.91 (4203.01)
> 14 (14) MUON- (MUON- )
> 104 (104) 148.529 (149.258)
> 4296.8 (4241.91)
> 14 (14) MUON- (MUON- )
> 104 (104) 147.935 (148.529)
> 4325 (4296.8)
> 14 (14) MUON- (MUON- )
> 104 (103) 144.4 (146.379)
> 4460.79 (4403.42)
> 14 (14) MUON- (MUON- )
> 104 (104) 143.978 (144.4)
> 4492.37 (4460.79)
> 14 (14) MUON- (MUON- )
> 104 (104) 140.951 (143.978)
> 8195.04 (4492.37)
> 14 (14) MUON- (MUON- )
> 104 (104) 140.14 (140.951)
> 8250.41 (8195.04)
> 14 (14) MUON- (MUON- )
> 104 (104) 139.653 (140.14)
> 8260.5 (8250.41)
> 14 (14) MUON- (MUON- )
> 104 (104) 135.677 (139.653)
> 8500.22 (8260.5)
> 14 (14) MUON- (MUON- )
> 104 (104) 134.944 (135.677)
> 8549.98 (8500.22)
> State when crossing detector volume:
> 14 (14) MUON- (MUON- )
> 19 (104) 133.189 (134.944)
> 11920 (8549.98)
> Reached end of particle history loop
>
> The final iteration is when it crosses into the detector volume and is
> logged by BXDRAW with icode 19. As you can see, the particle was
> generated in by a primary (400 GeV/c) proton, which generated a pi-,
> which then produced the muon that was followed.
>
> The magnetic regions are from z=184.8 to 544.8 , z=916.6 to 1276.6,
> z=4139.4 to 4499.4, z=8156.5 to 8356.5 and z=8429.5-8629.5 and are
> implemented by means of a custom magfld.f routine.
>
> What is the meaning of the ICODE = 104 for these muons?
>
> Are the ISPUSR / SPAUSR variables (and their related variables in
> stupre.f and stuprf.f) also modified internally in FLUKA outside of
> the stupre.f and stuprf.f user routines – this question observed by
> the ISPUSR variable seemingly changing to 103 (eighth line along the
> history)?
>
> I understand this is a highly complicated question, especially since
> it relates to the simultaneous use of five user routines. If the
> problem is not clear like this, or requires further demonstration; I
> can produce a self-contained (relatively) simple example of the
> behaviour described here.
>
> Thank you in advance for your advice and help, it is much appreciated.
>
> Kind regards,
>
> Maarten van Dijk
>
>
>
>
__________________________________________________________________________
You can manage unsubscription from this mailing list at
https://www.fluka.org/fluka.php?id=acc_info
Received on Mon Sep 24 2018 - 19:43:45 CEST