[Gate-users] Simulate a beam with spaced bunches in GATE

David Sarrut David.Sarrut at creatis.insa-lyon.fr
Fri May 10 09:13:00 CEST 2013


Hello Irene and Salvatore,

the enhanced phase space actor is in the develop part of the current gate
repository and you will be able to access to this current development
version (without guarantee) in some times, but we still need to setup
correctly the system, so please be patient. In the meantime, you can look
at the code and try to modify the classes GatePhaseSpaceActor.

Sincerely,
David


On Mon, Apr 29, 2013 at 9:08 PM, Irene Torres <ireneta at ific.uv.es> wrote:

> **
> Hello David,
>
> Thank you for your help!
>
> I have tried the last option you suggested and I got an error during GATE
> compilation:
>
> ./tmp/Linux-g++/Gate/libGate.so: undefined reference to
> `GatePhaseSpaceActor::GatePhaseSpaceActor(G4String, int)'
> collect2: ld returned 1 exit status
> make: *** [bin/Linux-g++/Gate] Error 1
> root at cormorant:/opt/OpenGate6/gate_v6.1# exit
>
> Any idea where I should start searching??
> Thanks again!
>
> Cheers,
>
> Irene
>
>
> On 04/29/2013 08:00 AM, David Sarrut wrote:
>
> Hello Salvatore,
>
>  I haven't got the time to look at in detail, but this is true that
> phase-space dose not store runID, eventID, and that, in that case, the time
> is no taken into account with the source.
>
>  I think the best solution for your problem is to write a new type of
> source. That should not be too difficult (even if it requires some times),
> starting from a new class inheriting from GateVSource. You will need also
> to slightly modify GateSourceMgr (in function AddSource) to enable your new
> source type. Maybe instead of a new source type, you can alternatively add
> timing option to the GPS source type. I am convinced that it could be
> useful to other too.
>
>  Another alternative option, simpler but maybe not as useful, could be to
> add RunID and EvenID branch in the phase space. I attached to this mail a
> new version of the PhaseSpaceActor that store eventID and runID. You can
> try it (without any guarantee) by adding the files in the src/include
> folders of the digits_hits folder.
>
>  Sincerely,
> David
>
>
> On Mon, Apr 22, 2013 at 5:58 PM, Salvatore Di Guida <
> salvatore.di.guida at cern.ch> wrote:
>
>> Dear GATE users and developers,
>> since I have been using the framework for few weeks, I apologize for my
>> misunderstandings and mistakes.
>> I have simulated the detector I am working on as two water boxes
>> (equivalent to gas detectors), two plastic scintillator boxes plus a
>> scanner system made up of 30 plastic scintillators. I have attached one
>> phase space to each water box (in order to describe the incoming particles
>> from the source and from the first box, respectively), to the air box
>> between the water boxes (in order to look at the particles outgoing the
>> first water box) and to the air box between the second water fox and the
>> first scintillator (in order to look at the particles outgoing the second
>> water box). Moreover, I have defined a proton pencil beam source: I have
>> implemented it both via G4 GeneralParticleSource and using the PencilBeam
>> template in GATE.
>> If you like, you can check the geometry and the sources in details in the
>> archive I am attaching to this mail: there you can find the macros I am
>> using. I am working with GATE 6.1 on vGATE 2.0.
>> The output I want to retrieve is, for each proton, the x and y position
>> in each water box, and the energy deposition in each level of the scanner
>> system.
>> In my first attempt, I simply created the geometry, the source, and the
>> digitizer system, and launched the simulation with 1000 primaries,
>> producing ROOT files as output. My idea was to distinguish the incoming
>> protons by the (runID, eventID) pair: unfortunately, the phase space does
>> not store this piece of information [1].
>> Then, since both the phase space and the scanner keep time information,
>> my next attempt was to calculate the coincidences of each proton in the
>> water boxes and in the first scintillator: in this way, I could mark the
>> protons propagating outside the scanner with the same (runID, eventID) pair
>> established inside it. Unfortunately, both sources generate all the protons
>> at t = 0, so it is impossible to get an adequate result via coincidence
>> computations [2].
>> Next, I tried to overcome this issue using time slices in Data
>> Acquisition: I defined 1000 time slices, where each slice has a time
>> duration larger than the time of flight of the proton, so that I had one
>> primary per slice, and the association between data in water and data in
>> the scanner could be quite easy. Unfortunately, when the second time slice
>> starts, GATE crashes with a segmentation violation with both the PencilBeam
>> source and with GPS source (even when I tried to set
>> GeneralParticleSource::number or setActivity in GATE). Debugging with gdb
>> did not help.
>>
>> My question is: is there a way in GATE to produce a beam source where a
>> given number of protons are grouped in bunches spaced by a given time
>> interval (say: 100 protons-per-bunch, bunches spaced by 100 ms).
>>
>> Thanks in advance for your help!
>>
>> Salvatore
>>
>> [1]
>> $ root -l
>> root [] TFile* gem0RootFile =
>> TFile::Open("GEM0PHS_1000primaries_perfectPBS.root")
>> root [] TTree* gem0PhaseSpaceTree = (TTree*) gem0RootFile->Get(
>> "PhaseSpace" )
>> root [] phaseSpaceTree->Print()
>>
>> [2] the source is 0.05 mm far from the phase space, which is at the
>> origin of the world; so, all protons enter the water box associated to the
>> phase space at t > 0:
>> root [] TFile* gem0RootFile =
>> TFile::Open("GEM0PHS_1000primaries_perfectPBS.root")
>> root [] TTree* gem0PhaseSpaceTree = (TTree*) gem0RootFile->Get(
>> "PhaseSpace" )
>> root [] gem0PhaseSpaceTree->Scan(
>> "ParticleName:Time:X:Y:Z:dX:dY:dZ:Ekine" )
>>
>> ************************************************************************************************************************
>> *    Row   * ParticleN *      Time *         X *         Y *         Z *
>>        dX *        dY *        dZ *     Ekine *
>>
>> ************************************************************************************************************************
>> *        0 *    proton * 0.0003519 *         0 *         0 *         0 *
>> -2.63e-08 * 2.610e-08 *         1 *       100 *
>> *        1 *    proton * 0.0003519 *         0 *         0 *         0 *
>> 2.421e-08 * 9.183e-11 *         1 *       100 *
>> *        2 *    proton * 0.0003519 *         0 *         0 *         0 *
>> 1.011e-09 * 2.843e-09 *         1 *       100 *
>> *        3 *    proton * 0.0003519 *         0 *         0 *         0 *
>> -5.11e-09 * 7.478e-10 *         1 *       100 *
>> *        4 *    proton * 0.0003519 *         0 *         0 *         0 *
>> 2.031e-08 * -2.61e-08 *         1 *       100 *
>> *        5 *    proton * 0.0003519 *         0 *         0 *         0 *
>> 2.153e-08 * 9.473e-09 *         1 *       100 *
>> ...
>> And here it is how the ROOT file for the phase space between the two
>> water boxes look like: there is a very slight difference in timing between
>> protons...
>> root [] TFile* gemSpacingRootFile =
>> TFile::Open("GEMSpacingPHS_1000primaries_perfectPBS.root")
>> root [] TTree* gemSpacingPhaseSpaceTree = (TTree*)
>> gemSpacingRootFile->Get( "PhaseSpace" )
>> root [] gemSpacingPhaseSpaceTree->Scan(
>> "ParticleName:Time:X:Y:Z:dX:dY:dZ:Ekine" )
>>
>> ************************************************************************************************************************
>> *    Row   * ParticleN *      Time *         X *         Y *         Z *
>>        dX *        dY *        dZ *     Ekine *
>>
>> ************************************************************************************************************************
>> *        0 *    proton * 0.0194233 * 0.0030443 * -0.001321 * 2.7000000 *
>> 0.0042755 * -0.001657 * 0.9999895 * 98.147529 *
>> *        1 *    proton * 0.0194286 * -0.002575 * 0.0078605 * 2.7000000 *
>> -0.002732 * 0.0060394 * 0.9999780 * 97.927230 *
>> *        2 *    proton * 0.0194189 * 0.0081350 * -0.003375 * 2.7000000 *
>> 0.0061967 * -0.000981 * 0.9999803 * 98.123619 *
>> *        3 *    proton * 0.0194209 * 0.0102742 * -0.006316 * 2.7000000 *
>> -0.002067 * -0.004013 * 0.9999898 * 97.984443 *
>> *        4 *    proton * 0.0194191 * -0.007278 * 0.0019697 * 2.7000000 *
>> -0.005616 * 0.0024906 * 0.9999811 * 98.163551 *
>> ...
>>
>> _______________________________________________
>> Gate-users mailing list
>> Gate-users at lists.opengatecollaboration.org
>> http://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>>
>
>
>
>  --
> David Sarrut, Phd
> Chargé de recherche CNRS
> CREATIS, UMR CNRS 5220, Inserm U 1044
> Centre de lutte contre le cancer Léon Bérard
> 28 rue Laënnec, 69373 Lyon cedex 08
> Tel : 04 78 78 51 51 / 06 74 72 05 42
> http://www.creatis.insa-lyon.fr/~dsarrut
> _________________________________
>  "2 + 2 = 5,  for extremely large values of 2"
> _________________________________
>
>
> _______________________________________________
> Gate-users mailing listGate-users at lists.opengatecollaboration.orghttp://lists.opengatecollaboration.org/mailman/listinfo/gate-users
>
>
>


-- 
David Sarrut, Phd
Chargé de recherche CNRS
CREATIS, UMR CNRS 5220, Inserm U 1044
Centre de lutte contre le cancer Léon Bérard
28 rue Laënnec, 69373 Lyon cedex 08
Tel : 04 78 78 51 51 / 06 74 72 05 42
http://www.creatis.insa-lyon.fr/~dsarrut
_________________________________
 "2 + 2 = 5,  for extremely large values of 2"
_________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengatecollaboration.org/mailman/private/gate-users/attachments/20130510/137ee412/attachment-0001.html>


More information about the Gate-users mailing list