GSI Forum: General » Detector ID.

Home » PANDA » PandaRoot » General » Detector ID.

Show: Today's Messages :: Polls :: Message Navigator

Detector ID. [message #7124]

Fri, 25 July 2008 16:33

Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino

first-grade participant

From: *pv.infn.it

Hi all,
for the STT we need to set the detectorID by hand in PndStt::ProcessHits instead of taking it from the MonteCarlo id of the volume via fVolumeID = vol->getMCid() (fVolumeID --> detID, as it is now), to have
the same detID for all the tubes (both skewed and not) and indicate univocally the detector: is there some criterion we have to follow to assign the detID or can we choose any number?
...just not to set the same detID to two different detectors, which maybe could cause problems...

Thank you and ciao,
Lia.

Report message to a moderator

Re: Detector ID. [message #7126 is a reply to message #7124]

Fri, 25 July 2008 16:47

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *physik.uni-giessen.de

Hi,
in general the fDetectorID has an internal use, so at the moment almost all the detectors are using an internal rule (or at least emc drc and muon chambers).
In this sense I think you can put there whatever you like.

Report message to a moderator

Re: Detector ID. [message #7128 is a reply to message #7124]

Mon, 28 July 2008 08:45

Tobias Stockmanns
Messages: 489
Registered: May 2007

first-grade participant

From: *ikp.kfa-juelich.de

Hi Lia, hi all other pandaRooters,

in my opinion the DetID is a unique identifier for the subdetector which has generated the data. This unique number is necessary to decide inside e.g. the TrackCand to which subdetector a certain hit belongs to and how to cast it.

We once agreed on a numbering scheme starting from the inside of the Panda detector, but we never really specified which number stands for the MVD, STT and so on. To make it more complicated the MVD e.g. needs two numbers for the strip and the pixel part.

I think this is an important point and should be addressed at the next EVO meeting.

Ciao,

Tobias

Report message to a moderator

Re: Detector ID. [message #7131 is a reply to message #7128]

Mon, 28 July 2008 12:46

Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino

first-grade participant

From: *pv.infn.it

Hi Tobias,
ok, in this case I will wait before giving a detID to the STT.
I will not be able to attend the next EVO meeting, but Pablo will be present for Pavia, if you decide to discuss about this.

A solution to the problem of the subdetectors with more than one part/option could be for example:
11 = MVD pixel (to be read "one-one")
12 = MVD strip (to be read "one-two")
where the first "1" stands for MVD and the choice pixel/strip is made by the second number ("1" or "2").

The same for the Central Tracker, with the choice STT and TPC: 21 and 22 (first number which indicates the CT and the second which indicates the option...)

I don' t know if this could be a solution, we can also decide to simply assign one different number to every part of detector: maybe it' s more simple...

Ciao,
Lia.

Report message to a moderator

Re: Detector ID. [message #7132 is a reply to message #7131]

Mon, 28 July 2008 13:03

StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino

first-grade participant

From: *physik.uni-giessen.de

In the case of EMC we have almost 20000 crystals, and we use 4 different numbers to identify our element:

module (barrel endaps)
row
crystal
copy number

Everything is coded inside fDetectorID.

Report message to a moderator

Re: Detector ID. [message #7153 is a reply to message #7132]

Mon, 04 August 2008 13:31

Mohammad Al-Turany
Messages: 518
Registered: April 2004
Location: GSI, Germany

first-grade participant

From: *gsi.de

Hi,

I think it is useful to summarize what kind of Id's are there and how they are used tell now:

1. CbmModule has a protected member fModId which is used internally in the framework!

2. CbmDetector has a member fDetId which can be set from the detector constructor as detector identifier. e.g. In CBM there is an enum:

enum  DetectorId {kREF, kMVD, kSTS, kRICH, kMUCH, kTRD, kTOF, kECAL, kZDC, kSTT,kTutDet};

these values are hardcoded in the detector constructors. e.g:

CbmRich::CbmRich() : CbmDetector("RICH", kTRUE, kRICH)

These id's are also used for the stack filtering!

3. in CbmVolume:

Int_t fVolumeId; /**Volume Id in GeoManager*/
Int_t fMCid; /**Volume Id in MC*/

these two are usually identical if you use the TGeoManager as geometry description and navigation! otherwise they could differ! they are simply the unique identifier of a volume in the geometry.

So I think we need an enum to identify the detector generally and for those detectors who need more than an integer I would do it like in the emc! so that one can find out from a point in which volume, sector, ..etc it was registered!

regards

Mohammad

Report message to a moderator

Previous Topic:	Nice plots.
Next Topic:	all code open to public?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Dec 01 05:22:02 CET 2024

Total time taken to generate the page: 0.00792 seconds