[ALICE3] TRK/Geometry: small bug fix

[AizatDaribayeva]

Just a small bug fix in the geometry features.

[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-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[alibuild]

Error while checking build/O2/fullCI_slc9 for 01a6a32 at 2026-03-02 23:36:

## sw/BUILD/O2Physics-latest/log
c++: fatal error: Killed signal terminated program cc1plus
ninja: build stopped: subcommand failed.


## sw/BUILD/o2checkcode-latest/log
--
========== List of errors found ==========
++ GRERR=0
++ grep -v clang-diagnostic-error error-log.txt
++ grep ' error:'
++ GRERR=1
++ [[ 1 == 0 ]]
++ mkdir -p /sw/INSTALLROOT/aa9b3f35ca0fd74682683a24a8b1ad4e500ce95d/slc9_x86-64/o2checkcode/1.0-local100/etc/modulefiles
++ cat
--

Full log here.

[fcolamar]

Hi @AizatDaribayeva, @njacazio, a comment from my side: I see that this PR modifies how the retrieval of the alpha angle and of the X of a given ML/OT sensor, i.e. by subtracting the number of VD modules.
What is done, to me, seems now consistent to how the mCacheRefXMLOT are filled (starting from 0 and not from getNumberOfActivePartsVD. Anyway, I'm worried that there could still be an inconsistency on how that array is used, in the TimeFrame class.
See in particular:

AliceO2/Detectors/Upgrades/ALICE3/TRK/reconstruction/src/TimeFrame.cxx

Line 116 in 3626eea

alpha = gman->getSensorRefAlphaMLOT(chipID);

where there are the lines:
int chipID = hit.GetDetectorID();
alpha = gman->getSensorRefAlphaMLOT(chipID);
and I think that GetDetectorID() starts from 0 in the VD, and not in the ML (so the first element of ML is not 0 but 'getNumberOfActivePartsVD', .i.e at the moment 12 since the VD disks were removed).
Isn't there an issue of this kind?

[fcolamar]

Ah I see that the PR was just merged in the meantime, but let's anyway have a look at this point, thanks

[njacazio]

Ciao @fcolamar we can revert if needed

[fcolamar]

Actually re-checking it should be fine, in the getSensorRefAlphaMLOT there's indeed the subtraction by getNumberOfActivePartsVD that brings back the chip value passed as argument to 0 for the first ML module.
All clear, thanks!

[AizatDaribayeva]

Ciao Nicolo, Fabio, As I was saying in mattermost, the vectors for x and alpha are filled exclusively for ML and OT only. So for example, for index = 0, the first chipID of the ML will be written. So, every time we retrieve the angle and x values from these vectors, for given chipID we will be shifting to the correct index in the vectors. Also, I'm putting assert in the getters in order to make sure that the chipid which given as a parameter for these getters correspond to ML/OT. Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Nicolò Jacazio ***@***.***> Sent: Tuesday, March 3, 2026 10:47:15 AM To: AliceO2Group/AliceO2 ***@***.***> Cc: Aizat Daribayeva ***@***.***>; Mention ***@***.***> Subject: Re: [AliceO2Group/AliceO2] [ALICE3] TRK/Geometry: small bug fix (PR #15112) [https://avatars.githubusercontent.com/u/1282257?s=20&v=4]njacazio left a comment (AliceO2Group/AliceO2#15112)<#15112 (comment)> Ciao @fcolamar<https://github.com/fcolamar> we can revert if needed — Reply to this email directly, view it on GitHub<#15112 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BYYAYAGP5ANJMV737WML6F34O2S2HAVCNFSM6AAAAACWEKAOIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSOBZHA2TGOBVGA>. You are receiving this because you were mentioned.Message ID: ***@***.***>