| Module index confusion between GEM and EMC? [message #16293] |
Fri, 11 April 2014 16:03  |
|
|
Hello,
While trying to make radiation length profiles of various subsystems, I noticed something that looks like a indexing interference between the GEM and EMC modules. I simulate geantinos and calculate the total length traversed in each detector subsystem where I identify path within a subsystem by the index returned using the function: FairRadLenPoint::GetDetectorID(). This is just the zero based integer order in which the module of the subsystem was registered in the simulation macro.
What I find is summarized in the attached figure. If I register only modules up to the GEM in the official macro, then the radiation length of the GEM comes out with hits only for theta~<20 degrees and no hits are registered in the EMC (as expected). (Top left panel) However as soon as I add EMC module to the mix in the simulation macro, the GEM radiation length plot transforms dramatically, where a bunch of hits suddenly appear in the ~40 to 85 degrees region in theta. (Top right panel). The EMC radiation length plot also looks very strange with a big hole in the same region where there is an excess of hits in the GEM. (Bottom left panel). Superposing both (EMC and GEM) one sees that the excess seen for GEM fits rather smoothly into the hole in the EMC distribution. (Bottom right panel), which led me to believe that hits that belong to the EMC are being given a detector ID that belongs to the GEM. I'm not sure if this is a global problem or only a bug in the code that fills FairRadLenPoint containers.
I use January 2014 version of pandaroot with April 2013 version of external packages. I've attached the simulation macros (upto gem and upto emc) and the code that was used to generate the histograms in the attached plots.
Best,
Ermias.
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
