Do not ask for geometry in GLO ITS-TPC and TOF matching QC

[chiarazampolli]

@shahor02 , @noferini , @ercolessi , @njacazio
@ercolessi , @njacazio , @noferini : for TOF, the same should be done online

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2022-pp-apass4
async-2023-pbpb-apass
async-2023-pp-apass1
async-data
async-mc
async-2022-pp-apass6

[noferini]

For my understanding, why is geometry no longer required?

[shahor02]

Thanks! Labels :) ?

[chiarazampolli]

Yes, I am still not used to them :-)

Chiara

[chiarazampolli]

@benedikt-voelkel , what is "async-data"? what is "async-mc"?
I also expect no MC for apass1 of pp 2023 anymore: do we want to patch it too? @noferini

[chiarazampolli]

For my understanding, why is geometry no longer required?

To my knowledge, the full geometry is needed only when we use material corrections, but we don't. We use propagateParamToDCA where Bz is used.

@shahor02 can comment more.
See also O2-4687.

[noferini]

Since I think that this is critical only for data, I would mark it only for async-2023-pbpb-apass,
apass4/apass6 2022 data reco is over and we will not reconstruct anything with those tags but MC (-> no need to cheery-pick this change there).
Do you agree?
In general I would not touch QC in a tag when data reco is over (better to have the same setting in data and MC)

[shahor02]

For my understanding, why is geometry no longer required?

To my knowledge, the full geometry is needed only when we use material corrections, but we don't. We use propagateParamToDCA where Bz is used.

@shahor02 can comment more. See also O2-4687.

Full geometry is needed only if the mat. correction is done via TGeo (which should never be done in the barrel in the production since it is very slow, instead the mat LUT should be used) OR if it is used for matrices fetching. For some detectors (ITS, MFT, and partially TRD) we already have lightweight matrices pools which can be preloaded from the CCDB w/o requiring full geometry.
But the TOF sometimes uses TGeometry to build its matrices. @noferini please crosscheck in the https://its.cern.ch/jira/browse/O2-4687, if TOF-related tasks mentioned by @chiarazampolli indeed do not need geometry for matrices.

[noferini]

Hi @shahor02 ,
also @ercolessi ran a local test with and without geo enabled in the json and she got the same result (and no crash).
Then , I confirm we don't need geo for TOF there