GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Bugs, Fixes, Releases » Module index confusion between GEM and EMC?
Module index confusion between GEM and EMC? [message #16293] Fri, 11 April 2014 16:03 Go to next message
Ermias is currently offline  Ermias
Messages: 8
Registered: November 2013
Location: IPN, Orsay
occasional visitor

From: 134.158.197*
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.

index.php?t=getfile&id=7798&private=0

Best,

Ermias.
Re: Module index confusion between GEM and EMC? [message #16294 is a reply to message #16293] Fri, 11 April 2014 17:42 Go to previous messageGo to next message
Radoslaw Karabowicz is currently offline  Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
continuous participant
From: *gsi.de
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
Re: Module index confusion between GEM and EMC? [message #16302 is a reply to message #16294] Mon, 14 April 2014 14:25 Go to previous messageGo to next message
Ermias is currently offline  Ermias
Messages: 8
Registered: November 2013
Location: IPN, Orsay
occasional visitor

From: 134.158.197*
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.

index.php?t=getfile&id=7803&private=0
Re: Module index confusion between GEM and EMC? [message #16311 is a reply to message #16302] Tue, 15 April 2014 12:45 Go to previous message
Radoslaw Karabowicz is currently offline  Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
continuous participant
From: 140.181.9*
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", "")
index.php?t=getfile&id=7807&private=0
It looks OK.
You can also draw MVD points, this time only Z coordinate:
root [1] cbmsim->Draw("RadLen.fZ","RadLen.fDetectorID==5","")
index.php?t=getfile&id=7806&private=0
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","")
index.php?t=getfile&id=7805&private=0
you see last GEM station and the central EMC barrel.
  • Attachment: gem.gif
    (Size: 7.76KB, Downloaded 333 times)
  • Attachment: mvd.gif
    (Size: 9.04KB, Downloaded 342 times)
  • Attachment: stt.gif
    (Size: 15.73KB, Downloaded 327 times)
Previous Topic: New PandaRoot release scrut14
Next Topic: [FIXED] error in running tut_sim.C
Goto Forum:
  


Current Time: Sat Jul 02 01:47:03 CEST 2022

Total time taken to generate the page: 0.00880 seconds