In principle we only need to add it to the current configuration and decide which algorithm to use and then people can try it out for their magic flavour tag models...

https://github.com/iLCSoft/MarlinReco/blob/master/Analysis/SiPID/src/SiTracker_dEdxProcessor.cc

For the vertex they are named <TrackerHitCollectionName>Relations but for the inner/outer tracker they are named <SimTrackerHitCollectionName>Relations

After investigating the tracking issue, adjusting the parameters MaxCellAngle and MaxCellAngleRZ to 0.5 (as opposed to 0.1), in the displaced step, has significantly enhanced the reconstruction of displaced tracks (tested with displaced single particle). These conditions were frequently not met, leading to track not being reconstructed.
The choice of the 0.5 value was somewhat arbitrary, and further optimisation is required.

However, despite this adjustment, an issue persists in properly reconstructing the Heavy Neutral Lepton (HNL) vertex with electron tracks. Interestingly, when considering all tracks in the event, the HNL vertex reconstruction aligns better with the expected distribution. What factors could be contributing to the reconstruction efficiency of electron?

1- Reconstructed vertex displacement (normalised to 1)

2- Comparison of Generated and reconstructed vertex displacement for MaxCellAngle, MaxCellAngleRZ = 0.5, left reconstructed with electrons tracks and right with all tracks in the event

3- Comparison of Generated and reconstructed vertex displacement MaxCellAngle, MaxCellAngleRZ = 0.1, left reconstructed with electrons tracks and right with all tracks in the event

There are still some warnings emitted for every event at the moment, we should fix that.

=================== WARNING ===================
static method CellIDDecoder::setDefaultEncoding
does nothing anymore. Use the constructor to 
specify your encoding string !!
===============================================
[ MESSAGE "MyDDMarlinPandora_10ns"] Failed to extract ecal calo hit collection: ECALOther, lcio::DataNotAvailableException: LCEventImpl::getCollection: collection not in event:ECALOther

• remove ECALOther #14
• find where CellIDDecoder warning comes from and fix it... see e.g. iLCSoft/MarlinReco#100

Change license to Apache v2 as the rest of key4hep (?)

for faster tracking resolution studies

Requires some retraining for the isolated lepton and photon taggers...

• IsolatedLeptonTaggingProcessor
• TaJetReclustering
• IsolatedPhotonTaggingProcessor

ILD steering file

This kills k4run before the help message can be printed :/

• Find better place for the test input files, e.g. key4hep eos
• Document how test input files are created
  • Find out how I created the current test file

ddsim -S cld_steer.py -N 4 --compactFile $K4GEO//FCCee/CLD/compact/FCCee_o1_v04/FCCee_o1_v04.xml --inputFile ../yyxyev_000.stdhep --outputFile test.slcio

• Create edm4hep test input file
• Add test for edm4hep input

In

LcioEvent           FATAL  Standard std::exception is caught 
LcioEvent           ERROR lcio::IOException: [LCReader::open()] File(s) not found:    
EventLoopMgr        ERROR Unable to initialize Algorithm: LcioEvent
ServiceManager      ERROR Unable to initialize Service: EventLoopMgr
ApplicationMgr      ERROR Application Manager Terminated with error code 1

We should provide a more helpful error message catching this and pointing to the new --inputFiles

Thx to @gaswk for the report!

I have encountered an intermittent issue where a hit is occasionally missing in the vertex or tracker during the reconstruction process. This seems to occur randomly and is not specific to any detector model, theta, or momentum. This problem does not correspond to a specific event but affects the entire reconstruction process. Interestingly, relaunching the reconstruction with the same conditions resolves the issue.

I add some examples:
1-
First reconstruction for 80 and 89 deg (third set of points) and r position of the hits in the vertex:

Second reconstruction with the same input resulted in:

2-
With the CLD_o3_v01 geometry, the first reconstruction showed these pT and d0 resolution:

While a simple relaunch altered the results, indicating a possible missing hit in the tracker as the difference in d0 is quite small. Unfortunately, I no longer have access to the files for further analysis

This issue has been observed multiple times, although it appears to be random.
Do you any idea what could be the problem?