Upgrade to WireTracker_info

[sfranchel]

BEGINRELEASENOTES

• Update code to use WireTracker info instead of DCH, allowing for easier compatibility with other trackers

ENDRELEASENOTES

Updating DCH digitizers and part of the tracking code to use the WireTracker_info structure allowing to share more easily code between Drift Chamber and Straw Tubes tracker.

This PR will need first the changes in k4geo to be merged:
key4hep/k4geo#581

ccing @s6anloes

[s6anloes]

Thanks for this PR!
I have asked @andread3vita to take a look at the changes in GenFit

[andread3vita]

Hi! When I run the ctest for the TrackFitter after compiling your version of k4geo, I get the following error:

GenfitTrackFitter  WARNING DCH_info unexpected error: ObjectExtensions::extension: The object has no extension of type 4491726DD2577FF6.. This may indicate missing drift chamber or configuration issues.
9: ApplicationMgr        INFO Application Manager Initialized successfully
9: ApplicationMgr        INFO Application Manager Started successfully
9: 
9: TUnixSystem::Di...   FATAL segmentation violation

Do I need to do anything else before running the fitter with WireTracker_info?

[s6anloes]

Hi! When I run the ctest for the TrackFitter after compiling your version of k4geo, I get the following error:

GenfitTrackFitter  WARNING DCH_info unexpected error: ObjectExtensions::extension: The object has no extension of type 4491726DD2577FF6.. This may indicate missing drift chamber or configuration issues.
9: ApplicationMgr        INFO Application Manager Initialized successfully
9: ApplicationMgr        INFO Application Manager Started successfully
9: 
9: TUnixSystem::Di...   FATAL segmentation violation

Do I need to do anything else before running the fitter with WireTracker_info?

@sfranchel , it seems you missed to change the extension type in your k4geo PR.
Specifically these lines (maybe some others as well):
https://github.com/sfranchel/k4geo/blob/21cb58f05b884f12235fef3e20a41cf52dfd7681/detector/tracker/DriftChamber_o1_v02.cpp#L42
https://github.com/sfranchel/k4geo/blob/21cb58f05b884f12235fef3e20a41cf52dfd7681/detector/tracker/DriftChamber_o1_v02.cpp#L485

Could you update there?

[s6anloes]

In the CompositeTT function arguments as well:
https://github.com/sfranchel/k4geo/blob/21cb58f05b884f12235fef3e20a41cf52dfd7681/detector/tracker/DriftChamber_o1_v02.cpp#L28
https://github.com/sfranchel/k4geo/blob/21cb58f05b884f12235fef3e20a41cf52dfd7681/detector/tracker/DriftChamber_o1_v02.cpp#L496

[s6anloes]

Ah sorry, nevermind. The new WireTracker_info is in the same namespace, I missed that. Then I'm not sure what the problem that @andread3vita is seeing is ...

[sfranchel]

Thank you @andread3vita and @s6anloes for looking into this, I'll try replicate the error on my side and investigate the issue. Will report here updates.

[s6anloes]

I have investigated the failing GenFit test a bit and have found a solution.
I will comment all the files that need to be changed, also in key4hep/k4geo#581 .
TODO: check also if digitiser is impacted

[sfranchel]

I have investigated the failing GenFit test a bit and have found a solution. I will comment all the files that need to be changed, also in key4hep/k4geo#581 . TODO: check also if digitiser is impacted

Many thanks @s6anloes for pinning down the issue! Based on your suggestions I have updated the way that the DCH_info pointers are retrieved, and it seems to be working now. All ctests are passing locally! 🥳

[andread3vita]

Hi @sfranchel! I confirm that this PR does not affect the fitter. It looks good to me!

[SanghyunKo]

I have one small comment on the Vector3D typedef, and another major request on catching the section cellID encoding scheme.

[SanghyunKo]

m_dc_decoder can be nullptr when the tracker is not a wire tracker:

k4RecTracker/Tracking/components/GenfitTrackFitter.cpp

Lines 155 to 187 in c701eca

	try {
	std::string DCH_name(m_DCH_name.value());
	dd4hep::DetElement DCH_DE = m_geoSvc->getDetector()->detectors().at(DCH_name);
	m_dch_info = DCH_DE.extension<dd4hep::rec::DCH_info>();
	dd4hep::SensitiveDetector dch_sd = m_geoSvc->getDetector()->sensitiveDetector(DCH_name);
	dd4hep::Readout dch_readout = dch_sd.readout();
	m_dc_decoder = dch_readout.idSpec().decoder();
	std::string desc = m_dc_decoder->fieldDescription();
	std::set<std::string> fields;
	std::stringstream ss(desc);
	std::string token;
	while (std::getline(ss, token, ',')) {
	auto pos = token.find(':');
	if (pos != std::string::npos) {
	fields.insert(token.substr(0, pos));
	}
	}
	if (!(fields.count("superlayer") && fields.count("layer") && fields.count("nphi"))) {
	warning() << "DCH decoder missing required fields: " << desc << endmsg;
	throw std::runtime_error("Invalid DCH decoder");
	}
	} catch (const std::exception& e) {
	warning() << "DCH_info unexpected error: " << e.what()
	<< ". This may indicate missing drift chamber or configuration issues." << endmsg;
	}

(not a practical use-case, but safer to guard from nullptr since it is allowed in principle)

[SanghyunKo]

Now looks good to me :)

[s6anloes]

TFile::TFile ERROR file /k4rectracker/DCHdigi/test/test_DCHdigi/dch_proton_10GeV_.root does not exist

It seems the tests are failing because the CI_TYPE environment variable in DCHdigi/test/test_DCHdigi/test_DCHdigi.sh is not correctly filled:
ddsim --steeringFile sim_steering.py --outputFile 'dch_proton_10GeV_${CI_TYPE}.root' -N 10 --runType batch --random.seed 42

@jmcarcell , do you have experience with this problem?

[sfranchel]

Hi @s6anloes that CI_TYPE was a naive attempt to make sure the correct files are considered during the CI running. But that was very poorly implemented and would have required a bit more changes. So I removed it for now... In any case, at the moment I see CI tests passing locally when compiling with the nightly release.

[s6anloes]

Okay so now the tests fail for alma9 and ubuntu26, but run for ubuntu24.
The problem seems to be the k4geo that is found.

For ubuntu24:
-- Found k4geo: /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2026-06-22/x86_64-ubuntu24.04-gcc13.3.0-opt/k4geo/e62aebd647d04585521b19098e80f5ff71b7cd8e_develop-prkriy/lib/cmake/k4geo/k4geoConfig.cmake

For alma9:
-- Found k4geo: /cvmfs/sft-nightlies.cern.ch/lcg/views/devkey-head/Sat/x86_64-el9-gcc14-opt/lib/cmake/k4geo/k4geoConfig.cmake

Could it be a problem with the new lcg stacks of key4hep, @jmcarcell @andresailer ?
The new WireTracker_info class that is now utilised by the drift chamber is present though in the lcg nightly:

$ echo $K4GEO
/cvmfs/sft-nightlies.cern.ch/lcg/nightlies/devkey-head/Sat/k4geo/HEAD/x86_64-el9-gcc14-opt/share/k4geo

$ ls /cvmfs/sft-nightlies.cern.ch/lcg/nightlies/devkey-head/Sat/k4geo/HEAD/x86_64-el9-gcc14-opt/include/detectorCommon/
DetUtils_k4geo.h  WireTracker_info.h  xtalk_neighbors_moduleThetaMergedSegmentation.h

[jmcarcell]

Okay so now the tests fail for alma9 and ubuntu26, but run for ubuntu24. The problem seems to be the k4geo that is found.

For ubuntu24: -- Found k4geo: /cvmfs/sw-nightlies.hsf.org/key4hep/releases/2026-06-22/x86_64-ubuntu24.04-gcc13.3.0-opt/k4geo/e62aebd647d04585521b19098e80f5ff71b7cd8e_develop-prkriy/lib/cmake/k4geo/k4geoConfig.cmake

For alma9: -- Found k4geo: /cvmfs/sft-nightlies.cern.ch/lcg/views/devkey-head/Sat/x86_64-el9-gcc14-opt/lib/cmake/k4geo/k4geoConfig.cmake

Could it be a problem with the new lcg stacks of key4hep, @jmcarcell @andresailer ? The new WireTracker_info class that is now utilised by the drift chamber is present though in the lcg nightly:

$ echo $K4GEO
/cvmfs/sft-nightlies.cern.ch/lcg/nightlies/devkey-head/Sat/k4geo/HEAD/x86_64-el9-gcc14-opt/share/k4geo

$ ls /cvmfs/sft-nightlies.cern.ch/lcg/nightlies/devkey-head/Sat/k4geo/HEAD/x86_64-el9-gcc14-opt/include/detectorCommon/
DetUtils_k4geo.h  WireTracker_info.h  xtalk_neighbors_moduleThetaMergedSegmentation.h

Ignore this for now, may be related to https://gitlab.cern.ch/gaudi/Gaudi/-/work_items/398.

[s6anloes]

Ignore this for now

What exactly do you mean with 'this'?
Do you mean we should ignore my assumption that it has anything to do with the spack vs lcg build of key4hep, and try to find a solution based on the link you provided?

Or do you mean we should ignore the failing test, because it should run locally, meaning we can go ahead and merge?

Or do we ignore in the sense that we have to wait until it is fixed on the Gaudi side?

[jmcarcell]

That you can merge, if it's that issue in Gaudi then once this PR lands in the builds then CI should work fine.

[s6anloes]

I don't have permission to merge until the checks succeed it appears.
Can you do it, @jmcarcell ?
Thanks!