GSI Forum - RDF feed
type: channel
description: GSI Helmholtzzentrum für Schwerionenforschung
items: Module index confusion between GEM and EMC?
items: Re: Module index confusion between GEM and EMC?

Module index confusion between GEM and EMC?
type: item
description: 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.
creator: Ermias
date: 2014-04-11T14:03:17-00:00

Re: Module index confusion between GEM and EMC?
type: item
description: Hi, If you look closely, what you were considering as GEM only, included also big part of MVD (check the fZ of RadLen points). There is some problem with the MVD, that I will look at during the weekend. For now, as a fast solution, please implement the MVD detector as the last detector in all your simulation macros. yours radek
creator: Radoslaw Karabowicz
date: 2014-04-11T15:42:20-00:00

Re: Module index confusion between GEM and EMC?
type: item
description: Hi Radek, Thanks for the hint. I was able to confirm your statement that the symptoms that I see can be fixed by either adding the MVD module after everybody else or by not adding it at all (Attached plots, with the list of modules in the legend added in that order they appear.) I'm surprised that the problem had anything to do with the MVD because the indexes seemed to have been swapped between the EMC and GEM. Anyways, when you find the bug, please let me know, I can help to cross checking your fix. Cheers, Ermias.
creator: Ermias
date: 2014-04-14T12:25:15-00:00

Re: Module index confusion between GEM and EMC?
type: item
description: Dear Ermias, Your simple problem helped us to find two bugs. 1. FairMCApplication was not correctly inserting volumes to the internal map. This will have a minor effect, but still it should be done correctly. Since the SVN for fair base is blocked, please fix it yourself. Edit base/sim/FairMCApplication.cxx and change line 623 from: for (Int_t n=NoOfVolumesBefore; n <= NoOfVolumes; n++) { to for (Int_t n=NoOfVolumesBefore+1; n <= NoOfVolumes; n++) { 2. The MVD geometry, that you have used, and that is the most accurate (Mvd-2.1_FullVersion.root), have few volumes with duplicate names. Tobias and Ralf have been contacted. I think that the problem is minor one, and imho influence only the calculation of the radiation length. Nevertheless, I would argue that it should be fixed. For the moment, the best solution is to add MVD as the last detector, when one make RadLen map. yours radek PS. One more thing. It is always got to verify your results. Your simulation is creating file sim_complete_20k_upto_emc.root. Inside you will find the branch RadLen which stores all the points for the Radiation Length calculation. If you plot cbmsim->Draw("RadLen.fZ:RadLen.fY:RadLen.fX"), you will get the picture of your detector. The points have a unique identifier for each detector, RadLen.fDetectorID. For the points in MVD it should be set to 5, for GEM points to 6, for EMC to 7 (because in your simulation macro, MVD, GEM and EMC where the 6,7 and 8 module added). You can f.e. plot all the points left in STT (RadLen.fDetectorID==4): root [1] cbmsim->Draw("RadLen.fZ:RadLen.fY:RadLen.fX","RadLen.fDetectorID==4", "") It looks OK. You can also draw MVD points, this time only Z coordinate: root [1] cbmsim->Draw("RadLen.fZ","RadLen.fDetectorID==5","") You see three peaks where GEMs are. It shows that MVD and GEM are mixed. Plotting the GEM, root [1] cbmsim->Draw("RadLen.fZ","RadLen.fDetectorID==6","") you see last GEM station and the central EMC barrel.
creator: Radoslaw Karabowicz
date: 2014-04-15T10:45:03-00:00