Message: Spin tracking of muons at rest Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Question Spin tracking of muons at rest 

Forum: Fields: Magnetic and Otherwise
Date: 18 Feb, 2009
From: Kevin Lynch <Kevin Lynch>

As a follow-up to my previous question on muon spin tracking of moving muons (post 155, http://hypernews.slac.stanford.edu/HyperNews/geant4/get/emfields/155.html), I have a new question about hybrid systems where moving muons come to rest in a target. To help myself and others in future, I'm going to start with a few observations that aren't handled in much detail in the documentation, and then get to my question:

1) To decay a muon, you need to instantiate a "Decay" process, and Geant4 provides 2: G4Decay, and G4DecayWithSpin. The Decay processes can be attached to both moving and resting particles by appropriate calls to G4ProcessManager::SetProcessOrdering, with the ProcessManager of the given particle type.

2) These processes permit decay, but somewhat confusingly (at least to me!) have nothing to do with whether or not the daughter products are produced in correlation with the spin; that determination is made by the selection of DecayChannels that are attached to the G4Muon{Plus,Minus} class. Geant4 provides a number of choices, depending on your needs: G4MuonDecayChannel, G4MuonDecayChannelWithSpin, and G4MuonRadiativeDecayChannelWithSpin.

3) This (well, and the code) leads me to conclude that the only real difference between the two Decay processes is whether the muon spin is evolved. The G4Decay class provides no evolution, while the G4DecayWithSpin class provides the static BMT \vec{s} \cross \vec{B} component. My experiments confirm that this does something to the spin of at rest muons, although I haven't tested the precession in detail.

4) For muons in motion, the spin is evolved differently, by the G4Transportation processes. In particular, the partial (full) BMT spin evolution equations given in the G4Mag_SpinEqRhs (G4EqEMFieldWithSpin) class.

I hope my understanding is correct. Assuming it is, here's my question:

For muons at rest, I clearly need to attach the G4DecayWithSpin class, via a call equivalent to G4MuonPlus::MuonPlus()->SetProcessOrdering(new G4DecayWithSpin(), idxAtRest), to get at rest spin evolution. But if I attach G4DecayWithSpin to idxPostStep, do I simultaneously get BOTH G4Mag_EqRhs BMT evolution, AND the G4DecayWithSpin evolution? In other words, do I double count the spin rotation for muons in motion? Should I attach G4Decay to idxPostStep instead of G4DecayWithSpin? The only example in the 4.9.2 distribution that uses G4DecayWithSpin is extended/field04, which attaches G4DecayWithSpin in both cases. Assuming I'm wrong, can you point out how the code in the distribution ensures the G4DecayWithSpin terms don't come in to play for moving muons?

Setting up a test environment to figure this out in detail is somewhat onerous, hence my hope that someone can quickly set me straight. Thanks in advance for you comments!

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 Agree: Re: Spin tracking of muons at rest   (Gumplinger Peter - 18 Feb, 2009)
(_ None: Re: Spin tracking of muons at rest   (Kevin Lynch - 18 Feb, 2009)
 Add Message Add Message
to: "Spin tracking of muons at rest"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]