Problem 1783

Summary:	Decay channel prepared incorrectly in G4DecayWithSpin
Product:	Geant4	Reporter:	Aaron Fienberg <atfienberg>
Component:	processes/decay	Assignee:	gum
Status:	RESOLVED FIXED
Severity:	normal	CC:	krlynch, kurasige, resnegfk
Priority:	P5
Version:	10.1
Hardware:	All
OS:	All

Description Aaron Fienberg 2015-09-18 20:59:29 CEST

There are two issues with decay channel preparation in G4DecayWithSpin.

1) G4DecayWithSpin::DecayIt samples the decay table using SelectADecayChannel, sets the selected decay channel's parent polarization, and then calls G4Decay::DecayIt. G4Decay::DecayIt proceeds to sample the decay table again before actually calling the decay channel's DecayIt function. If there is more than one decay channel in the decay table, it is possible for G4Decay::DecayIt to pick a different channel than G4DecayWithSpin::DecayIt did, effecting an incorrect parent polarization in the ultimately selected channel.

2) The parent polarization passed to the decay channel in G4DecayWithSpin::DecayIt is incorrect for in flight decays in a magnetic field. The Spin_Precession() function called on line 122 of G4DecayWithSpin.cc uses fRemainderLifeTime to rotate the parent polarization before passing it to the decay channel. This variable must be 0 for in flight decays, but I have confirmed that it is not. It is set in the PostStepGetPhysicalInteractionLength function to be theNumberOfInteractionLengthLeft*PDGLifetime, and it is still that value when G4DecayWithSpin::DecayIt is called. 

I tested this with the muon decay channels.

Comment 1 Krzysztof Genser 2015-09-18 21:19:57 CEST

Based on my tests I can confirm that for the in flight decays, the
parent polarization set by the transportation at the decay point is
different from the polarization passed to the decay channel by
G4DecayWithSpin

Comment 2 gum 2015-09-25 01:42:53 CEST

Thanks for reporting this problem/bug.

To avoid the resampling of the decay channel in G4Decay::DecayIt perhaps the needed/relevant code in that method has to be copied into G4DecayWithSpin::DecayIt and no call to G4Decay::DecayIt be made. Or invent some other mechanism to avoid the resampling.

What I don't understand is that fRemainderLifeTime is not zero for decays-in-flight.

I welcome help in addressing this report.

Peter

Comment 3 Aaron Fienberg 2015-09-25 19:57:18 CEST

In the interest of avoiding code duplication, one possible solution to the decay table resampling would be setting the parent polarization for all channels, using the G4DecayTable::entries() method and operator[] to iterate through. 

For decays-in-flight, fRemainderLifeTime is set during G4Decay::PostStepGetPhysicalInteractionLength, line 392, to be theNumberOfInteractionLengthsLeft*PDGLifeTime. In the step where the particle decays, G4Decay::PostStepDoIt is called, which does nothing but call G4DecayWithSpin::DecayIt. So, when DecayIt is called, fRemainderLifeTime will be equal to that final step length * lifetime / currentinteractionlength, which is nonzero. Keep in mind that the spin should already have been rotated according to that final step length by the transportation process.

I made a very simple simulation to demonstrate this. You can find it here:

https://github.com/atfienberg/decayWithSpinBug

If you look in debuggingOutput.txt, I ran this simulation in debugging mode with a breakpoint in G4DecayWithSpin::DecayIt to directly check the value of fRemainderLifeTime.

Thank you for looking in to this,

Aaron

Comment 4 gum 2015-09-25 20:47:37 CEST

Thanks Aaron,

Not sampling the decay channel in G4DecayWithSpin and setting the polarization for all decay channels is a good idea!

Hisaya Kurashige thinks the issue with fRemainderLifeTime is caused by a bug in G4ParticleChangeForDecay. (G4ParticleChangeForDecay.cc#L146). The polarization should be updated in UpdateStepForPostStep() same as UpdateStepForAtRest.

Can you please try track-V10-01-09 tag? (but I don't see the connection...)

Something changed. Why did I claim (and presumably verified in 2009) that fRemainderLifeTime is zero for decays in flight while you find that it is now one step behind.

Peter

Comment 5 kurasige 2015-10-02 23:28:47 CEST

I've created a new tag of decay-V10-01-04 which require particles-V10-01-11 and track-V10-01-10.

In these tag, G4DecayWithSpin have both PostStepDoIt and AtRestDoIt.
In AtRestDoIt, the spin of parent particle is updated by using Spin_Precession method and then is passed to 'all' decay channel in the decay table. Then the parent particle decays by using G4Decay::DecayIt method.
In PostStepDoIt, the spin of parent particle is not updated.

Set/GetPolarization methods are moved to G4VDecayChannel. In G4DecayWithSpin, polarization information is passed all decay channels in the decay tabale.

Comment 6 gum 2015-10-14 01:26:12 CEST

These changes resolve the bug report - to be confirmed by muon g-2