GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » R3BRoot » Simulation Issues » Detector ID
Detector ID [message #21158] Wed, 07 June 2017 15:33 Go to next message
Ina Syndikus is currently offline  Ina Syndikus
Messages: 3
Registered: October 2015
occasional visitor
From: *ikp.physik.tu-darmstadt.de
I'm looking at the output file of my simulation and trying to find out which secondary particles my protons produce in the (active) volume of XB. One of the things that I looked at is TrackPoint.fDetectorID. Its value is always 38. Is this XB? How do I find out which detector has which number? Is there a list?
And when we talk about detector IDs: R3BXBallPoint has also a XBCrystalPoint.fDetectorID, which has the values 6,8,10 & 12. I assume the numbers stand for the 4 crystal shapes. Am I right?
Re: Detector ID [message #21189 is a reply to message #21158] Mon, 12 June 2017 08:39 Go to previous messageGo to next message
Dmytro Kresan is currently offline  Dmytro Kresan
Messages: 166
Registered: June 2004
first-grade participant
From: *gsi.de
I was not able to find any match with "TrackPoint" branch in R3BRoot. Did you mean "TraPoint"? In this case, those are the hits from Tracker. Matching of data to a detector is done using the name: R3BXBall (detector) - R3BXBallPoint (hits of particles), the name of the branch has to be changed to "XBallPoint" (XBCrystalPoint is currently used).

There is enum type in r3bdata/R3BDetectorList.h, but it is used for counting how many points in each detector an MC track has, and not for storing together with simulated hits.

fDetectorID is meant to be sub-system internal, and it looks like, in case of XBall, it is the Volume ID. This number changes, depending on the order you add your detectors to the simulation run in the macro. It is better to use R3BXBallPoint.fCrystalType (1,2,3,4) and .fCrystalNb (running index, I suppose).

Best regards,
Dima
Re: Detector ID [message #21203 is a reply to message #21189] Tue, 13 June 2017 21:10 Go to previous messageGo to next message
Ina Syndikus is currently offline  Ina Syndikus
Messages: 3
Registered: October 2015
occasional visitor
From: 144.32.240*
Sorry, my fault. The branch is indeed TraPoint. I assume the tracker is the SSD Detectors surrounding the target (which is called "TRACKER" when I include it in the r3bsim.C file)?

I have another question about the classes "XBallPoint" & "XBallCrystalHitSim". It seems that "XBallPoint" includes all the particles passing XB, including a lot of electrons. But what is with "R3BXBallCrystalHitSim"? It includes much less particles and seems to get rid of all the electrons. How is this done? Is there a cutoff (additional to the one for Geant)? And is the energy of the electrons summed to the energy of the other particles?

Re: Detector ID [message #21213 is a reply to message #21203] Wed, 14 June 2017 10:01 Go to previous message
Dmytro Kresan is currently offline  Dmytro Kresan
Messages: 166
Registered: June 2004
first-grade participant
From: 140.181.8*
Quote:
I assume the tracker is the SSD Detectors surrounding the target (which is called "TRACKER" when I include it in the r3bsim.C file)?


Yes, it is correct.

XBallPoint contains one object for every particle which has hit an active volume of a crystal. Typically many entries per crystal.

XBallCrystalHitSim is supposed to describe a hit in a crystal, which integrates all relevant Points. 1 hit per crystal.
Energy loss is summed up. Optionally you can switch on some uniform smearing, controlled with R3BXBall::SetNonUniformity(....) method.
Details of the algorithm: R3BXBall.cxx lines 258 - 280.

Best regards,
Dima
Previous Topic: TrackID changes
Next Topic: GLAD positioning
Goto Forum:
  


Current Time: Tue Jul 27 20:49:11 CEST 2021

Total time taken to generate the page: 0.02395 seconds