Message: Resetting track global time Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Resetting track global time 

Forum: Event and Track Management
Date: 16 Feb, 2011
From: Robert Penny <Robert Penny>

This is a multi-part message in MIME format.

------_=_NextPart_001_01CBCE3B.283C2248
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I'm simulating irradiation from a positron-annihilation radioisotope =
source. =20

I use the particleGun to inject a radioisotope, then let it decay and =
have Geant track all of the daughter products.


  // Sodium-22
  G4ParticleDefinition* ion =3D particleTable->GetIon( 11, 22, 0. );

  // Fluorine-18
  // G4ParticleDefinition* ion =3D particleTable->GetIon( 9, 18, 0. );

  // Barium-133
  // G4ParticleDefinition* ion =3D particleTable->GetIon( 56, 133, 0. );

  // Cesium-137
  // G4ParticleDefinition* ion =3D particleTable->GetIon( 55, 137, 0. );

  particleGun->SetParticleDefinition( ion );
  particleGun->SetParticleEnergy( 0. );
  particleGun->GeneratePrimaryVertex(anEvent);


This all works like a charm, except (quite reasonably) the global time =
of all of the tracks start with the time the radioisotope hangs around =
before decaying.  This could be hours, years or 10^10 years depending on =
the radioisotope.  It makes it hard to read anything sensible out of =
GlobalTime in terms of time-of-flight for the daughter products.

I put a little simple hack in my derived G4UserTrackingAction class to =
reset daughter products of the initial primary track if the daughters =
have a global time of greater than 1 second:

void
GC_TAG_TrackingAction::PreUserTrackingAction (const G4Track * aTrack)
{

....


  // Reset products of radioactive decay to start at time zero.
  // Otherwise every track may start at 10^10 years in the future.
  if( parentID =3D=3D 1 && aTrack->GetGlobalTime() > 1 * second )
    {
      (const_cast<G4Track *>(aTrack))->SetGlobalTime( 0. );
    }
....


This all works just fine.  The one thing that has me nervous is that I =
had to cast away the "const" attribute of the G4Track before this was =
possible.  This makes me think I'm not really meant to be fiddling with =
the track's values and I could be setting off some nasty side effects.

I could, in principle, use the LocalTime of each track to derive the =
same information.  However, this means I'd have to keep track of the =
progressive chain of elapsed local times through any subsequent daughter =
particles to know the elapsed time from decay to detection.

I'd appreciate any suggestions for the Geant "sanctioned" approach, or a =
simple "oh that's fine... don't worry about it".

Thanks,

-Rob

------_=_NextPart_001_01CBCE3B.283C2248
Content-Type: text/html;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7655.4">
<TITLE>Resetting track global time</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi,<BR>
<BR>
I'm simulating irradiation from a positron-annihilation radioisotope =
source.&nbsp;<BR>
<BR>
I use the particleGun to inject a radioisotope, then let it decay and =
have Geant track all of the daughter products.<BR>
<BR>
<BR>
&nbsp; // Sodium-22<BR>
&nbsp; G4ParticleDefinition* ion =3D particleTable-&gt;GetIon( 11, 22, =
0. );<BR>
<BR>
&nbsp; // Fluorine-18<BR>
&nbsp; // G4ParticleDefinition* ion =3D particleTable-&gt;GetIon( 9, 18, =
0. );<BR>
<BR>
&nbsp; // Barium-133<BR>
&nbsp; // G4ParticleDefinition* ion =3D particleTable-&gt;GetIon( 56, =
133, 0. );<BR>
<BR>
&nbsp; // Cesium-137<BR>
&nbsp; // G4ParticleDefinition* ion =3D particleTable-&gt;GetIon( 55, =
137, 0. );<BR>
<BR>
&nbsp; particleGun-&gt;SetParticleDefinition( ion );<BR>
&nbsp; particleGun-&gt;SetParticleEnergy( 0. );<BR>
&nbsp; particleGun-&gt;GeneratePrimaryVertex(anEvent);<BR>
<BR>
<BR>
This all works like a charm, except (quite reasonably) the global time =
of all of the tracks start with the time the radioisotope hangs around =
before decaying.&nbsp; This could be hours, years or 10^10 years =
depending on the radioisotope.&nbsp; It makes it hard to read anything =
sensible out of GlobalTime in terms of time-of-flight for the daughter =
products.<BR>
<BR>
I put a little simple hack in my derived G4UserTrackingAction class to =
reset daughter products of the initial primary track if the daughters =
have a global time of greater than 1 second:<BR>
<BR>
void<BR>
GC_TAG_TrackingAction::PreUserTrackingAction (const G4Track * =
aTrack)<BR>
{<BR>
<BR>
....<BR>
<BR>
<BR>
&nbsp; // Reset products of radioactive decay to start at time zero.<BR>
&nbsp; // Otherwise every track may start at 10^10 years in the =
future.<BR>
&nbsp; if( parentID =3D=3D 1 &amp;&amp; aTrack-&gt;GetGlobalTime() &gt; =
1 * second )<BR>
&nbsp;&nbsp;&nbsp; {<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (const_cast&lt;G4Track =
*&gt;(aTrack))-&gt;SetGlobalTime( 0. );<BR>
&nbsp;&nbsp;&nbsp; }<BR>
....<BR>
<BR>
<BR>
This all works just fine.&nbsp; The one thing that has me nervous is =
that I had to cast away the &quot;const&quot; attribute of the G4Track =
before this was possible.&nbsp; This makes me think I'm not really meant =
to be fiddling with the track's values and I could be setting off some =
nasty side effects.<BR>
<BR>
I could, in principle, use the LocalTime of each track to derive the =
same information.&nbsp; However, this means I'd have to keep track of =
the progressive chain of elapsed local times through any subsequent =
daughter particles to know the elapsed time from decay to detection.<BR>
<BR>
I'd appreciate any suggestions for the Geant &quot;sanctioned&quot; =
approach, or a simple &quot;oh that's fine... don't worry about =
it&quot;.<BR>
<BR>
Thanks,<BR>
<BR>
-Rob</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01CBCE3B.283C2248--

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

1 Agree: Re: Resetting track global time   (Gumplinger Peter - 16 Feb, 2011)
 Add Message Add Message
to: "Resetting track global time"

 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 ]