Project

General

Profile

Actions

Bug #1799

open

Hit and MC point z-position for mCBM

Added by Valentina Akishina about 2 years ago. Updated 12 months ago.

Status:
New
Priority:
High
Assignee:
Target version:
-
Start date:
08/31/2020
Due date:
% Done:

0%

Estimated time:

Description

Dear Vikas,

as discussed in mCBM meeting, I observe a shift in reconstructed hit y-position when comparing with MC point position (1st pic attached).

After investigation I have found out that this is presumably due to wrong z-position of the MC points (2nd pic attached).

Is it possible to fix it, so that MC-point, hit and station position coincide?

Many thanks!

Best regards,
Valentina


Files

InputInfoMuch.pdf (22.7 KB) InputInfoMuch.pdf Valentina Akishina, 08/31/2020 11:50 AM
mcbm_set20_03_much_zpos.pdf (14.1 KB) mcbm_set20_03_much_zpos.pdf Valentina Akishina, 08/31/2020 11:50 AM
much_v20a_mcbm_digi_sector.root (6.04 KB) much_v20a_mcbm_digi_sector.root New parameter file Ajit Kumar, 09/02/2020 05:57 AM
MuchHitPoint_zpos.pdf (14.1 KB) MuchHitPoint_zpos.pdf Valentina Akishina, 09/08/2020 01:19 PM
InputInfoMuch.pdf (22.6 KB) InputInfoMuch.pdf Valentina Akishina, 09/08/2020 01:27 PM
pull_residual_much_v20a_mcbm.pdf (352 KB) pull_residual_much_v20a_mcbm.pdf Anonymous, 05/21/2021 02:39 PM
Actions #1

Updated by Vikas Singhal about 2 years ago

  • Assignee changed from Vikas Singhal to Partha Pratim Bhaduri

Dear Partha,

Last week during MUCH Weekly Meeting we discussed about the shift in residual distribution of Y of mMUCH in mCBM setup.
Can you discuss with Omveer and correct the error.

Thanks and Regards
Vikas

Actions #2

Updated by Pierre-Alain Loizeau about 2 years ago

Ajit mentioned during today mCBM meeting that maybe it is due to a mismatch between the geometry and the sector file.

Currently the sector file for v20a is a link to the one of v19a, introduced by David on 23 May

https://git.cbm.gsi.de/CbmSoft/cbmroot_parameter/-/commit/5b69bc7b48148f3699a047c6c10653742fa0cbde
https://git.cbm.gsi.de/CbmSoft/cbmroot_parameter/-/tree/master/much
https://git.cbm.gsi.de/CbmSoft/cbmroot_geometry/-/tree/master/much

Actions #3

Updated by Ajit Kumar about 2 years ago

Dear Valentina,

Find the new parameter file for v20a geometry setup. Please convey if the problem solves.

One more thing you have to do is to use new translation value for Much in X. This will be needed in CbmMuchDigitizeGem.cxx and CbmMuchFindHitsGem.cxx. The new translation value in X is = 12.8.Y remains the same.

You will find these settings at line bumbers...
for CbmMuchDigitizeGem.cxx ---- > around line 921
and for CbmMuchFindHitsGem.cxx ----> around line number 581

Please let me know for ay confusion.

Thanks and Regards
Ajit

Actions #4

Updated by Florian Uhlig about 2 years ago

  • Assignee changed from Partha Pratim Bhaduri to Ajit Kumar

Hi Ajit,

thanks for providing the proper parameter file.

One more thing you have to do is to use new translation value for Much in X. This will be needed in CbmMuchDigitizeGem.cxx and CbmMuchFindHitsGem.cxx. The new translation value in X is = 12.8.Y remains the same.

You will find these settings at line bumbers...
for CbmMuchDigitizeGem.cxx ---- > around line 921
and for CbmMuchFindHitsGem.cxx ----> around line number 581

Can you explain why this parameter is needed and why it changes when you have a new geometry? How does the change of the value affects the digitization of cbm geometries?

If this is a parameter which depend on the geometry the parameter should go into the corresponding parameter file and should not be hard coded.

Actions #5

Updated by Ajit Kumar about 2 years ago

Dear Florian,

---> Can you explain why this parameter is needed and why it changes when you have a new geometry? How does the change of the value affects the digitization of cbm geometries?
===> It is needed because of the detector orientation in mCBM. We are using sis100 parameter file for mMUCH setup which needs to be adjusted accordingly. It does not affect our main cbm digitization and recosntruction.

---> If this is a parameter which depend on the geometry the parameter should go into the corresponding parameter file and should not be hard coded.
===> Yes I agree. I don't know how to do that. This translation and rotation thing was done by Omveer.

Ajit

Actions #6

Updated by Valentina Akishina about 2 years ago

Dear Ajit,

I get the following problem when I run digitisation with the parameter file you sent:

[INFO] MuchDigitizeGem: MUCH geometry tag is v20a_mcbm
[INFO] MuchDigitizeGem: Using parameter file /u/akishina/cbmgit/parameters/much/much_v20a_mcbm_digi_sector.root
[INFO] MuchDigitizeGem: Using flag 1 (mcbm)
Error in <TFile::ReadBuffer>: error reading all requested bytes from file /u/akishina/cbmgit/parameters/much/much_v20a_mcbm_digi_sector.root, got 31 of 300
Error in <TFile::Init>: /u/akishina/cbmgit/parameters/much/much_v20a_mcbm_digi_sector.root failed to read the file type data.
Fatal in <CbmMuchGeoScheme::InitModules>: No input array of stations.
aborting

Do you have an idea why it can happen?

Thank you!

Best regards,
Valentina

Actions #7

Updated by Anonymous about 2 years ago

Dear Valentina,
I think this error comes because of the wrong/corrupted par file(generated after transport. Could you please run transport again for a single event and use a par file of that?

Best Regards
Om

Actions #8

Updated by Valentina Akishina about 2 years ago

Dear Omveer,

thank you! Indeed somehow the downloaded parameter file was corrupted.

After I fixed it and run it again, I got updated z-positions (Please see pic attached).

Now they correspond for hit and mc point. However, the resulting residuals are still shifted (please see 2nd pic attached).

Best regards,
Valentina

Actions #9

Updated by Anonymous about 2 years ago

Dear Valentina,
Maybe this residual shift is because of our segmented file(Z position). Actually, what we are doing I am trying to explain it.

As we know the segmentation of the GEM module is according to sis100, where we are doing radial segmentation in a progressive manner. So first we are doing segmentation as sis100(around beam axis) then translate it to the detector axis(25 deg downstream from the beam axis) in case of mcbm. So, the Z position in the segmented file must be different of the MC points which are on the detector axis. I think we need to do some rotation too for removing these shifts.

Best regards,
Om

Actions #10

Updated by Vikas Singhal over 1 year ago

  • Assignee changed from Ajit Kumar to Partha Pratim Bhaduri
  • Priority changed from Normal to High

Dear Partha and Omveer,

I thought that MUCH Hit shift in residual for mCBM simulation has been fixed. But It is not as today Valentina reported the same during the mCBM Data Analysis meeting [[https://indico.gsi.de/event/12376/contributions/52756/attachments/35421/46645/mCBM_21.pdf]] .

As per this thread there are 3 points.
1: Mismatch between Geometry and corresponding sector file ----> Probably that is solved.

2: Whenever Z value of GEM stations updated need to fix their translation values in CbmMuchDigitizeGem.cxx and CbmMuchFindHitsGem.cxx. Can you cross check present translation values and their correctness according to latest v20a_mcbm.

3: We need to put these values inside the parameter file such that need not to hard code these in the digitizer and hit class. As you developed geometries and corresponding classes, Can you think and suggest how to perform the same?

We need to fix the same on priority.
Thanks
Vikas

Actions #11

Updated by Anonymous over 1 year ago

Dear Vikas Sir,
1) When I am looking Z-position for both layers in "much_v20a_mcbm_digi_sector.root" file. It matches with MC points i.e. (85.7 cm and 118.7cm).
2) Z values never translate in MuchDigitization class. Only X and Y values shift.
3) I have tried but not succeed maybe anyone can also try. One other option is, If we are inputting translation values at the time of digitization for different geometries or define the values for each geometry in MuchDigitization class(hardcoded).

Best Regards,
Om

Actions #12

Updated by Anonymous over 1 year ago

  • Assignee changed from Partha Pratim Bhaduri to Vikas Singhal
Actions #13

Updated by Pierre-Alain Loizeau over 1 year ago

Dear all,

From what I can see in the parameter repository the corrected sector file was not replaced: it is for now a symbolic link to the 19a_mcbm version

I could make an MR replacing it with the version proposed by Ajit in this issue.
Please let me know if I should to do it and let you review it or if one of you want to do the MR themselves (which would make it easier to fix problems before merging in case we find some).

Best regards
P-A

Actions #14

Updated by Vikas Singhal over 1 year ago

Dear Pierre,

Thanks for pointing the problem. Kindly you fix and generate the MR.

@Omveer: After merging this fix in Git by Pierre, can you freshly generate residual and pull for x, y and time with much_v20a geometry and default sector file which comes with git version (Manually do not change any thing). We need to check and fix if some bias or shift in the residual.
@Partha and @Omveer, we need to think a procedure to read the value of Z position of GEM Modules from geometry file and then calculate the required translation such that need not to hard code these values inside Digitizer Class (CbmMuchDigitizeGem) and hit reconstruction class (CbmMuchFindHitsGem).
Kindly update accordingly.

Vikas

Actions #15

Updated by Anonymous over 1 year ago

Dear All,
I have found a bug in CbmMuchfFindHitsGem class where the translation value is changed with 0.5 cm in the Y direction That's why we are getting a shift in residual and pull distribution in the Y direction. Now, this is fixed and the class will be committed soon to the repository. The pull and residual distributions are including after modifying the same class. Please have a look.

Best Regards
Om

Actions #16

Updated by Anonymous about 1 year ago

Dear Valentina,
Regarding this issue, I have updated CbmMuchFindHitsGem Class https://git.cbm.gsi.de/computing/cbmroot/-/tree/master/reco/detectors/much . Could you please check and let me know?. If It is okay then please close the issue.

Best Regards,
om

Actions #17

Updated by Valentina Akishina 12 months ago

Dear Omveer,

yes, thank you!
The issue is fixed.

Best regards,
Valentina

Actions

Also available in: Atom PDF