[gate-users] Photons ID's from decay sources

[Dirk Kruecker]

Hi Ross,

Unfortunately the origin of the photon is not registered.
The primaryID is always 1 because it is always the decaying nucleus.
Not very useful to record this. 
The parentID is not useful, either. It may be everything, It is just what the 
name says: the ID of the parent track of the track that caused the hit.
The photonID contains some info: (0 -> cascade ) but not (cascade -> 0).

I use my own extension to the root files. I have include the code I use to 
identify the gammas, look for //dk in the code to find my modifications.
I did not include the changes to modify the root output  since I changed a lot 
in my code. But it is straightforward work to add an additional entry to the 
root file.

Please, verify the code if you want to use it!

Dirk



> Hi Dirk and Dimitris,
>
> I figure you both are the most likely to know the answer to this
> question but if anyone else knows please speak up ;).
>
> I have been looking at the root output for Hits, Singles, and
> Coincidences and am trying to determine the source particle's identity
> be it positron or cascade photon?  Inside the Hit's Branch I am looking
> into ParentID, PhotonID, and PrimaryID.  So far ParentID looks the most
> likely but I don't know how to interpret this.
>
> Thanks,
>
> ross
>
> -----Original Message-----
> From: gate-users-bounces at lphe1pet1.epfl.ch
> [mailto:gate-users-bounces at lphe1pet1.epfl.ch] On Behalf Of Dirk Kruecker
> Sent: Tuesday, June 14, 2005 5:52 AM
> To: GATE feedback and helpline for Users
> Subject: Re: [gate-users] source of germanium68
>
>
> Hello everybody,
>
> Let me summarise the present status on the beta decay module in GEANT4:
>
> There is a beta decay module in GEANT4 that works quiet nice. It allows
> you to
> simulate the decay of all kinds of nuclei using the ENSDF
> (http://www.nndc.bnl.gov/ensdf/).
> It simulates any possible decay, taking into account the latest
> knowledge on
> branching ratios and creates all possible gammas from the de-excitation
> of
> the daughter-nucleus.
> So you get the right ratio between beta+ and EC, and for each possible
> decay
> channel the appropriate gamma spectrum in coincidence with the positron.
>
> In GATE the commands to implement e.g. Y86 looks like:
> /gate/source/addSource ytt86
> /gate/source/ytt86/setActivity 500000000. becquerel
> /gate/source/ytt86/gps/particle ion /gate/source/ytt86/gps/ion 39 86 0 0
> /gate/source/ytt86/gps/energytype Mono /gate/source/ytt86/gps/monoenergy
> 0. MeV /gate/source/ytt86/gps/angtype iso /gate/source/ytt86/gps/number
> 1 /gate/source/ytt86/gps/centre 0. 0. 0. cm /gate/source/ytt86/gps/type
> Volume /gate/source/ytt86/gps/shape Sphere /gate/source/ytt86/gps/radius
> 0.1 mm
> /gate/source/ytt86/gps/mintheta    0. deg
> /gate/source/ytt86/gps/maxtheta  180. deg
> /gate/source/ytt86/gps/minphi      0. deg
> /gate/source/ytt86/gps/maxphi    360. deg
>
> The important part here is the /gate/source/ytt86/gps/ion 39 86 0 0
> command where Z and A are defined. You can define all kinds of isotops
> here.
>
> Unfortunately there had been several bugs in the GEANT4 code for the
> beta
> decay and even the latest version  does not run absolutely stable. In
> addition the original implementation is astonishing inefficient (i.e.
> slow)
> but there is a fast mode sufficient for our purposes.
>
> For GEANT4 version 4.52-4.62 you need patches in
> GateRadioactiveDecay5.cc and G4NuclearDecayChannel.cc which I can
> provide but I would rather use gate
> 1.2 with GEANT 4.7. For this version of GEANT I have provided an
> improved
> algorithm for simulating the beta energy spectra.
>
> To my knowledge the version GEANT 4.7 will give you correct physical
> results
> but it still contains some bugs which affect the stability of the
> program.
> There are at least 2 memory leaks. One I already fixed
> http://geant4.cern.ch/asdcgi/geant4/problemreport/show_bug.cgi?id=711
> but this is not yet part of any GEANT4 patch. Presently you have to
> include it
> by hand.
>
> I am still hunting for the second memory leak. Usually it only show up
> after
> simulating several millions of decays. On average my jobs run for 24h/12
>
> million events and about 1 of 8 jobs crashes. If you can live with this
> I
> would give it a try.
>
> I hope the helps. Let me know if you really want to work with the older
> GEANT4
> version.
>
> Best Regards,
> Dirk
>
>
>
>
>
>
>
>
> _______________________________________________
> gate-users mailing list
> gate-users at lphe1pet1.epfl.ch
> http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
>
>
>
> _______________________________________________
> gate-users mailing list
> gate-users at lphe1pet1.epfl.ch
> http://lphe1pet1.epfl.ch/mailman/listinfo/gate-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GateAnalysis.cc
Type: text/x-c++src
Size: 18398 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20050620/5a67444f/attachment.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GateTrajectoryNavigator.cc
Type: text/x-c++src
Size: 15088 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20050620/5a67444f/attachment-0001.cc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GateAnalysis.hh
Type: text/x-c++hdr
Size: 3764 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20050620/5a67444f/attachment.hh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GateTrajectoryNavigator.hh
Type: text/x-c++hdr
Size: 2598 bytes
Desc: not available
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20050620/5a67444f/attachment-0001.hh>