First implementation of exporting input variables and infer the ParT network with onnxruntime

[suehara]

BEGINRELEASENOTES
This is automatic generation written in ReleaseNotes.md

• 2025-12-05 SUEHARA Taikan

  • Implement backward compatibility for MC-PFO assignment
    • Add default parameter to InitMCPPFOCollections for backward compatibility
    • Use simple method (first element) when Track-MC relation is not available
    • Use improved method (weight-based, multi-track support) when available
    • Maintain full backward compatibility with upstream v00-11

• 2025-12-03 SUEHARA Taikan

  • Add optional ONNX support with backward compatibility
    • Enable ONNX Runtime support as optional feature (ENABLE_ONNX CMake option, default: OFF)
    • Make onnxruntime and nlohmann_json optional dependencies
    • Conditionally compile ONNX-related source files
    • Full backward compatibility when ENABLE_ONNX=OFF

• SUEHARA Taikan and collaborators (2024-2025)

  • Machine Learning and ONNX integration

    • Add MLInputGenerator, MLMakeNtuple, MLInferenceWeaver for ML-based flavor tagging
    • Add WeaverInterface and ONNXRuntime for ONNX model inference
    • Add DNNProvider2 for DNN-based vertex finding
    • Implement event-based classification with jets
    • Add dEdx support for particle identification

  • Flavor tagging improvements

    • Improve PFA-track assignment and track-MC assignment
    • Implement true jet flavor assignment from MC
    • Add MC-to-jet assignment algorithm (AssignJetsToMC)
    • Bugfixes on MC flavor assignment
    • Add sorted track and neutral accessors (getAllTracksSorted, getNeutralsSorted)

  • Code quality and compatibility

    • Update C++ standard to C++17 with CMake 3.5+ requirement
    • Compatibility fixes for key4hep environment and onnxruntime
    • Various bugfixes in weaver output and neutral PF candidate masking
    • Add event-based input support

ENDRELEASENOTES

[tmadlener]

I have started to have a look here and I was wondering whether you could add some example steering files for

• Running data collection for training
• Running the inference with the trained model

That would also help me judge if all of the classes are in the end necessary. It's not entirely clear to me if all of the different ways of doing inference are necessary or if we could drop them.

There are a few comments below which I found while having a first quick look.

[tmadlener]

Suggested change

	vector<const Track*> tracks_unsorted = getAllTracks(withoutV0);
	// order particles by energy
	vector<std::pair<float, int> > order_tr;
	order_tr.resize(tracks_unsorted.size());
	for(size_t i=0; i<tracks_unsorted.size(); ++i){
	order_tr[i] = std::pair<float, int>(tracks_unsorted[i]->E(), i);
	}
	std::sort(order_tr.begin(),order_tr.end(),[](std::pair<float,int>a,std::pair<float,int> b){
	return a.first > b.first;
	});
	vector<const Track*> tracks;
	tracks.resize(tracks_unsorted.size());
	for (size_t i=0; i<tracks_unsorted.size(); ++i) {
	tracks[i] = tracks_unsorted[order_tr[i].second];
	}
	return tracks;
	auto tracks_unsorted = getAllTracks(withoutV0);
	std::ranges::sort(tracks_unsorted, {}, &Track::E);

Since we are building with c++20 in any case, we can also use std::ranges::sort and not create an intermediate vector just for soting. Similar for the neutrals below.

[tmadlener]

Will these relations be persisted to files in the end? Maybe I am just missing it, but are the FromType and ToType parameters set on this collection so that it is easily possible to identify what is being linked in this collection?

[tmadlener]

Why not make this a class and mark the map as static? As far as I can tell that should have the same effect?

[tmadlener]

This should probably be an input parameter, and configurable somehow in the long run.

[tmadlener]

Does this construction work properly? I remember in the past, adding a vector to a tree, that later has to re-allocated because it grows made the pointer stored here invalid. I don't see any explicit calls to reserve or resize here for these vectors that would make them "stable" when adding elements.

[tmadlener]

I think this should be checked in the initialization and it should also be a hard error already there, not something that will just create a lot of log messages but still continues to run.

[tmadlener]

What is the reason to partial_sort_copy here? As far as I can see, tracks_orig and neutrals_orig are only used here and no longer after sorting has happened, and even though it says partial_sort here the effect will be that the whole vector will be sorted. sort is usually quicker than partial_sort. So I would propose something along the lines of

auto tracks = event->getTracks(); // NOTE: the explicit copy we do here by omitting '&'
std::ranges::sort(tracks, std::greater{}, &Track:E);

[tmadlener]

Is this header used anywhere? It looks like it can be removed?

[tmadlener]

Suggested change

	# Development branch additions (merged 2025-12-06)
	* 2025-12-05 SUEHARA Taikan
	- Implement backward compatibility for MC-PFO assignment
	- Add default parameter to InitMCPPFOCollections for backward compatibility
	- Use simple method (first element) when Track-MC relation is not available
	- Use improved method (weight-based, multi-track support) when available
	- Maintain full backward compatibility with upstream v00-11
	* 2025-12-03 SUEHARA Taikan
	- Add optional ONNX support with backward compatibility
	- Enable ONNX Runtime support as optional feature (ENABLE_ONNX CMake option, default: OFF)
	- Make onnxruntime and nlohmann_json optional dependencies
	- Conditionally compile ONNX-related source files
	- Full backward compatibility when ENABLE_ONNX=OFF
	* SUEHARA Taikan and collaborators (2024-2025)
	- Machine Learning and ONNX integration
	- Add MLInputGenerator, MLMakeNtuple, MLInferenceWeaver for ML-based flavor tagging
	- Add WeaverInterface and ONNXRuntime for ONNX model inference
	- Add DNNProvider2 for DNN-based vertex finding
	- Implement event-based classification with jets
	- Add dEdx support for particle identification
	- Flavor tagging improvements
	- Improve PFA-track assignment and track-MC assignment
	- Implement true jet flavor assignment from MC
	- Add MC-to-jet assignment algorithm (AssignJetsToMC)
	- Bugfixes on MC flavor assignment
	- Add sorted track and neutral accessors (getAllTracksSorted, getNeutralsSorted)
	- Code quality and compatibility
	- Update C++ standard to C++17 with CMake 3.5+ requirement
	- Compatibility fixes for key4hep environment and onnxruntime
	- Various bugfixes in weaver output and neutral PF candidate masking
	- Add event-based input support

These will be automatically added by our tagging script if you put them between the BEGINRELEASENOTES and ENDRELEASENOTES in the PR as you have already done.