fcl-based mapping of tracker panel identification

[edcallaghan]

Offline data structures and conditions databases have historically labeled individual panels using pair of integers, enumerating planes in the tracker and panels within each plane, constituting a "mostly geographic" system; this is based on the nomenclature of DocDB-888. Each panel is read out by an individual "DTC link," which is a pair identifying DTCs within the computing system, and a channel within each DTC. The data payload from the tracker will label each hit by the panel's so-called ``Minnesota number,'' which is uncorrelated with both the geometry and readout channeling of the detector. Thus, data read out from the digi contain redundant panel-level information (the Minnesota number and DTC channeling), which must be translated into geographic coordinates for downstream analysis.

PR #1402 implements a deserialization routine for tracker digis and contains a fixed mapping from a few DTC channels to geographic coordinates. This PR generalizes that translation into a two-stage mapping derived from fcl: i) nominally, Minnesota numbers are translated into geographic coordinates, but; ii) an invalid Minnesota number in the data causes a second lookup in an optional table mapping DTC channeling and geographic coordinates (retaining a flag that the payload containing this digi is known to contain a mistake, i.e. the bad MN number). The Minnesota number is used as the primary key because it will be stored in persistent ROM on the frontend, and hence will not be susceptible to e.g. errors introduced by rearranging fibers/computers.

Try as I might, I could not construct a fhicl schema which would tolerate tables with keys not known at runtime, so all maps are written in fcl as tuples, from which maps are constructed in the deserialization module.

This PR should be merged after #1402 to preserve authorship and allow for a cleaner diff.

[FNALbuild]

Hi @edcallaghan,
You have proposed changes to files in these packages:

• RecoDataProducts
• DAQ

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for 64c3cfe: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at 64c3cfe.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 64c3cfe at 90410d6
build (prof)	✅	Log file. Build time: 04 min 53 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	❌	Log file. Return Code 1.
FIXME, TODO	✅	TODO (0) FIXME (0) in 2 files
clang-tidy	🔶	20 errors 49 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 64c3cfe after being merged into the base branch at 90410d6.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[eflumerf]

@normanajn Should we discuss this in more detail? I think I was leaning more towards making this kind of map in the artdaq-core-mu2e data formats, as the other subsystems will also need to do this kind of HW-to-Digi channel mapping. Having it in configuration seems error-prone...

[FNALbuild]

📝 The HEAD of main has changed to 3c0bbbc. Tests are now out of date.

[rlcee]

CRV and cal have this functionality implemented in the conditions service framework, like here. This code currently reads text files to define the conversion.

[edcallaghan]

I didn't make a point of it in this PR, but the fcl interface, specifically, is only meant as a temporary measure to give us flexibility in decoding data from different test stands / tracker stations "today." We definitely will want something else as we approach having a single, static detector, and I (personally) don't currently have a preference between text-/db-based and/or moving the functionality into the data format codespace.

[normanajn]

Yes we should figure out what to do regarding a true channel map. I think the right thing to do is sit people down and discuss this (not over email) and come to a conclusion. Ray already has a good start on this but I think we need to figure out where this ultimately sits in the build hierarchy and how we populate and track it.

…

-- Andrew J. Norman Senior Scientist Data Science, Simulation and Learning Mu2e, DUNE, and NOvA Experiments HEPCloud Facility Project Fermi National Accelerator Laboratory 630 840 4016 office www.fnal.gov<http://www.fnal.gov/> ***@***.******@***.***> From: eflumerf ***@***.***> Date: Wednesday, April 30, 2025 at 8:07 AM To: Mu2e/Offline ***@***.***> Cc: Andrew John Norman ***@***.***>, Mention ***@***.***> Subject: Re: [Mu2e/Offline] fcl-based mapping of tracker panel identification (PR #1476) [EXTERNAL] – This message is from an external sender [https://avatars.githubusercontent.com/u/61473357?s=20&v=4]eflumerf left a comment (Mu2e/Offline#1476)<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mu2e_Offline_pull_1476-23issuecomment-2D2841916342&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=I5ewounBMJ1O01sPhizJf-xEnaOaD1hSy0eIrypSWd8&m=CAnLXOLNt_FdUsDUdbVhL6v-JzkhSxhWHfLAyuZzxzlP7mjq_Jp97sA3AZQaEYrq&s=zbvnz6x8WSsruq78AjfVs8kmjAQ6nZmCHH6qp1hP9zI&e=> @normanajn<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_normanajn&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=I5ewounBMJ1O01sPhizJf-xEnaOaD1hSy0eIrypSWd8&m=CAnLXOLNt_FdUsDUdbVhL6v-JzkhSxhWHfLAyuZzxzlP7mjq_Jp97sA3AZQaEYrq&s=qwcJXlsP8_33ydhEf8jMd7LU-lNx0lhMzCItCOhR9sM&e=> Should we discuss this in more detail? I think I was leaning more towards making this kind of map in the artdaq-core-mu2e data formats, as the other subsystems will also need to do this kind of HW-to-Digi channel mapping. Having it in configuration seems error-prone... — Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mu2e_Offline_pull_1476-23issuecomment-2D2841916342&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=I5ewounBMJ1O01sPhizJf-xEnaOaD1hSy0eIrypSWd8&m=CAnLXOLNt_FdUsDUdbVhL6v-JzkhSxhWHfLAyuZzxzlP7mjq_Jp97sA3AZQaEYrq&s=zbvnz6x8WSsruq78AjfVs8kmjAQ6nZmCHH6qp1hP9zI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AF2UFYKLJCJS6CKCEPCMHU324DDJDAVCNFSM6AAAAAB4EDSSZ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBRHEYTMMZUGI&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=I5ewounBMJ1O01sPhizJf-xEnaOaD1hSy0eIrypSWd8&m=CAnLXOLNt_FdUsDUdbVhL6v-JzkhSxhWHfLAyuZzxzlP7mjq_Jp97sA3AZQaEYrq&s=DamE_e3xyzegwQpIcv16xBc8XY8A2wQfw112itXPQZc&e=>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[brownd1978]

This PR addresses shortcomings of the original PR (1402). It is intended as a stopgap to allow detector work to continue while code development proceeds. I agree with the comments about long-term solutions, but those are outside the scope of this PR, which is to provide the algorithm in PR 1402 with code which meets Offline standards. I would appreciate your review from that perspective.

[brownd1978]

Note 2 tests failed in the CI. cmake is failing with:
File /scratch/workspace/GitHubPRTests/mu2e-offline-build-test/Offline/DAQ/src/StrawDigisFromArtdaqFragments_module.cc is not defined in CMakeLists.txt!
File /scratch/workspace/GitHubPRTests/mu2e-offline-build-test/Offline/DAQ/src/StrawRecoFromArtdaqFragments_module.cc defined in CMakeLists.txt but not found in directory!
Job completed with failure.

There are also 20+ clang-tidy errors associated with the use of Trace. Addressing those are beyond the scope of this PR, but it needs to be addressed eventually.

[edcallaghan]

@FNALbuild run build test

[FNALbuild]

⌛ The following tests have been triggered for c5e945a: build (Build queue - API unavailable)

[FNALbuild]

☀️ The build tests passed at c5e945a.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged c5e945a at 3c0bbbc
build (prof)	✅	Log file. Build time: 04 min 35 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	✅	Log file.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 2 files
clang-tidy	🔶	20 errors 49 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at c5e945a after being merged into the base branch at 3c0bbbc.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[eflumerf]

This is fine for now, but an Issue should be opened to make sure that the channel-mapping is done in a way that satisfies all parties, and consistently across subsystems.