Project

General

Profile

Actions

Bug #2286

open

Order of TRD stations in the mCBM setup 2021_07 + more issues

Added by Valentina Akishina 8 months ago. Updated 6 months ago.

Status:
New
Priority:
High
Target version:
-
Start date:
10/01/2021
Due date:
% Done:

100%

Estimated time:

Description

Dear Pascal,

I try to use setup 2021_07 for L1 tracking and I have noticed that the stations in the TRD geometry are not ordered according to z-position.
Our tracking expects them to be ordered. Is it possible to change it accordingly?

Thank you!

Best regards,
Valentina


Files

hits.png (41.6 KB) hits.png Valentina Akishina, 10/01/2021 03:32 PM
points.png (40.8 KB) points.png Valentina Akishina, 10/01/2021 03:32 PM
trd hits.png (39.1 KB) trd hits.png Valentina Akishina, 10/20/2021 09:03 AM
trd points.png (42 KB) trd points.png Valentina Akishina, 10/20/2021 09:03 AM
Bildschirmfoto 2021-10-26 um 16.34.49.png (32 KB) Bildschirmfoto 2021-10-26 um 16.34.49.png Pascal Raisig, 10/26/2021 04:37 PM
Actions #1

Updated by Valentina Akishina 8 months ago

  • File hits.png hits.png added
  • File points.png points.png added
  • Subject changed from Order of TRD stations in the mCBM setup 2021_07 to Order of TRD stations in the mCBM setup 2021_07 + more issues

I continue to investigate the usage of TRD information with the latest setup and new issues appear, so I add it here.

2) In L1 we read z-positions of stations as follows:

int ModuleId = fTrdDigiPar->GetModuleId(st);
CbmTrdParModDigi* module = (CbmTrdParModDigi*) fTrdDigiPar->GetModulePar(ModuleId);
float z = module->GetZ();

Now the positions which I get are:
145
156.6
178.6
200.6

They do not correspond to the positions of hits and mc points (pics attached). Why? How can I read out the correct positions of the stations?

3) Comparing pictures with mc points and hits, one can see that on the first station there are many MC points that do not produce hits, is it normal? Also on the second station there are too less both points and hits. Is it expected?

Thank you!

Best regards,
Valentina

Actions #2

Updated by Pascal Raisig 8 months ago

Hi Valentina,
I will take a look and try to fix it. But it might take me some minutes, since, I have to go through the geometry that Alex created ( I added him as watcher, but I guess he is still recovering ). I will also try to understand where the difference in the Z-positions comes from. A naive idea is that one of the positions is connected to the z-plane and the other one to the middle of the gas, but, to be honest, for this case I would expect the position differences to be vise-versa, i.e. the point placed in the gas (smaller z) and the hit on the padplane (larger z). However, we do nothing different in the reconstruction for mCBM and CBM so I guess the offset is introduced by the parameter files/geometry.
I will post updates here as soon as I have some.

Cheers,
Pascal

Actions #3

Updated by Pascal Raisig 7 months ago

  • Assignee changed from Pascal Raisig to Valentina Akishina
  • % Done changed from 0 to 90

Hi Valentina,
as just discussed in the mCBM analysis meeting the order and the positions should be fixed with https://git.cbm.gsi.de/computing/cbmroot/-/merge_requests/532 thanks a lot to Alex. Could you please confirm?

Cheers,
Pascal

Actions #4

Updated by Valentina Akishina 7 months ago

Dear Pascal,

yes, I confirm: now the station order and positions are ok.

This is that I get without my internal corrections:

139.1
157.6
181.6
208.6

Many thanks!

Also as I reported at the meeting I still observe strange number of hits at the 4th TRD station (picture attached).

Do you have ideas what can be the reason?

Best regards,
Valentina

Actions #5

Updated by Pascal Raisig 7 months ago

Hi Valentina,
what input did you use for your tests? I think the issue is related to a high amount of multihits when a to large input energy is used. The mCBM setup has large pads and pushes the rates per pad for the TRD 1D to its limits and since, we still do not have a valid multi-hit reconstruction points causing a multi-hit are kind of lost in the reconstruction currently.
I did some checks with "/input/urqmd.agag.1.65gev.centr.00001.root" here we still get 1719 multi-hits in 10 events. I attached the resulting comparison between hits (red) and points (blue), as remark I turned off the 2D modules in the reconstruction here, since they seemed unproblematic in terms of the point to hit ratio.

Actions #7

Updated by Valentina Akishina 7 months ago

Hi Pascal,
I used standart input: input/urqmd.agag.1.65gev.centr.00001.root

Actions #8

Updated by Alexandru Bercuci 6 months ago

  • % Done changed from 90 to 100

Hi,
Please if there is nothing else to be added to this issue pls close it.
Best
Alex

Actions

Also available in: Atom PDF