|Message: Results of a system profiler(callgrind) run for Gate--continued with question No.668||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
As suggested (context below) by expert weeks ago, we run the Gate simulation for the geometry of fanbeam collimator with the profiler callgrind to test whether the enormous slowdown of our simulation is caused by the Geant4 kernel or the Gate parameterisation itself. The results are as follows:
It seems the function G4Trap::MakePlane spent half of the CPU time (49.65%) to implement hundreds of thousands of collimator holes (trapezoid shape). The number of the holes are already reduced by 100 times in this test because of the slowness of the simulation. However, the GateHoleParameterisation itself did not consume much time. (The picture of the kcachegrind is in the attachment.) We think the solution may be to avoid implementing so many holes each time, only focus on a limited area. We hope to get some opinions on how to solve or avoid such a slowdown in the simulation. Thanks!!!
Context of the question: GATE for system design in SPECT
problem: enormous slowdown in the simulation of geometry of fanbeam collimator
> In SPECT a detector is typically made of a scintillator > capturing gammas emitted from a patient tracer. In front of > such a detector is a lead block with circa 150.000 air holes. > In parallel beam applications all these holes have an > identical form and are aligned along a rectangular grid. We > can model such a parallel beam collimator using arrays > (repeaters) or using G4 replicas. Both options are available > in GATE but for distributed computing only replicas are used > since building the geometry goes fast (almost no overhead on > a cluster). > > However, next to parallel beam applications, we are also > applying fan and cone beam collimators; respectively oriented > towards a focal line and a focal spot. > Hence, every individual hole has another form/orientation > which can be precalculated and described in a closed > analytical expression. To model such collimators we use G4 > parametrised volumes. Building the geometry goes fast and > flawless. The tracking however is multiple orders slower, > probably because every time a particle hits the collimator > every form and distance is recalculated. > > Temporary solution (not implemented yet): > > We are designing a "flying hole array" which only takes the > 20 neighbouring holes around the interaction site into > account. This is however a limitation if the energy of the > gammas increases which allows them to travel through many of > the lead lamella, crossing over multiple holes (not known > before how many holes).
|Inline Depth:||Outline Depth:||Add message:|