FCC Tutorial, 2.4.2: Part II: Produce a flat tree and analyse events. error: no member named 'TrackerHitData' in namespace 'edm4hep'

Analysis
1

Hi! I am following the FCC Tutorial. In, 2.4.2: Part II: Produce a flat tree and analyse events, I am running into the error: no member named ‘TrackerHitData’ in namespace ‘edm4hep’ while trying to run the treemaker_flavor.py.

I am using the key4hep/releases/2025-05-29. The analysis fails with the following error message:

----> INFO: Loading analyzers from libFCCAnalyses...
----> INFO: Loading analysis script:
            /afs/cern.ch/user/s/sbakare/FCC/FCCSW/FCCAnalyses/treemaker_flavor.py
----> INFO: Multithreading enabled. Running over 4 threads
----> INFO: Loading functions.h...
Warning in <TClass::Init>: no dictionary for class edm4hep::MCRecoParticleAssociationData is available
Warning in <TClass::Init>: no dictionary for class edm4hep::TrackerHitData is available
Warning in <TClass::Init>: no dictionary for class edm4hep::ObjectID is available
Warning in <TClass::Init>: no dictionary for class edm4hep::Vector2i is available
----> INFO: Number of the output files: 1
----> INFO: Running locally...
----> INFO: Creating dataframe object from files:
            	- ./localSamples//p8_ee_ZH_Zmumu_ecm240/p8_ee_ZH_Zmumu_ecm240_edm4hep.root

----> INFO: Number of local events: 10,000
----> INFO: Output file path:
            ./outputs/treemaker/flavor/p8_ee_ZH_Zmumu_ecm240.root
Warning in <TStreamerInfo::BuildOld>: Cannot convert edm4hep::ReconstructedParticleData::covMatrix from type: float to type: edm4hep::CovMatrix4f, skip element
Warning in <TStreamerInfo::BuildOld>: Cannot convert edm4hep::MCParticleData::momentum from type: edm4hep::Vector3f to type: edm4hep::Vector3d, skip element
Warning in <TStreamerInfo::BuildOld>: Cannot convert edm4hep::MCParticleData::momentumAtEndpoint from type: edm4hep::Vector3f to type: edm4hep::Vector3d, skip element
Warning in <TStreamerInfo::BuildOld>: Cannot convert edm4hep::ClusterData::positionError from type: float to type: edm4hep::CovMatrix3f, skip element
input_line_168:2:225: error: no member named 'TrackerHitData' in namespace 'edm4hep'
  ...var1, ROOT::VecOps::RVec<float>& var2, ROOT::VecOps::RVec<edm4hep::ClusterData>& var3, ROOT::VecOps::RVec<edm4hep::TrackerHitData>& var4, ...
                                                                                                               ~~~~~~~~~^
input_line_172:2:225: error: no member named 'TrackerHitData' in namespace 'edm4hep'
  ...var1, ROOT::VecOps::RVec<float>& var2, ROOT::VecOps::RVec<edm4hep::ClusterData>& var3, ROOT::VecOps::RVec<edm4hep::TrackerHitData>& var4, ...
                                                                                                               ~~~~~~~~~^
Traceback (most recent call last):
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/bin/fccanalysis", line 136, in <module>
    main()
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/bin/fccanalysis", line 131, in main
    run(parser)
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/python/run_analysis.py", line 728, in run
    run_stages(args, rdf_module, anapath)
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/python/run_analysis.py", line 389, in run_stages
    run_local(rdf_module, chunk_list[0], args)
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/python/run_analysis.py", line 221, in run_local
    inn, outn = run_rdf(rdf_module, file_list, outfile_path, args)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/python/run_analysis.py", line 113, in run_rdf
    dframe3 = get_element(rdf_module.RDFanalysis, "analysers")(dframe2)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/afs/cern.ch/user/s/sbakare/FCC/FCCSW/FCCAnalyses/treemaker_flavor.py", line 176, in analysers
    df = jetFlavourHelper.define(df)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/cvmfs/sw.hsf.org/key4hep/releases/2025-05-29/x86_64-almalinux9-gcc14.2.0-opt/fccanalyses/0.11.0-a25snu/python/addons/ONNXRuntime/jetFlavourHelper.py", line 224, in define
    df = df.Define(var, call)
         ^^^^^^^^^^^^^^^^^^^^
  File "/cvmfs/sw.hsf.org/key4hep/releases/2024-10-03/x86_64-almalinux9-gcc14.2.0-opt/root/6.32.04-vms5ij/lib/ROOT/_pythonization/_rdf_pyz.py", line 372, in _PyDefine
    return rdf._OriginalDefine(col_name, callable_or_str)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Template method resolution failed:
  ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void> ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void>::Define(string_view name, string_view expression) =>
    runtime_error: 
RDataFrame: An error occurred during just-in-time compilation. The lines above might indicate the cause of the crash
 All RDF objects that have not run an event loop yet should be considered in an invalid state.

  ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void> ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void>::Define(string_view name, string_view expression) =>
    runtime_error: 
RDataFrame: An error occurred during just-in-time compilation. The lines above might indicate the cause of the crash
 All RDF objects that have not run an event loop yet should be considered in an invalid state.

  Failed to instantiate "Define(ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void>&,std::string,std::string)"
  Failed to instantiate "Define(ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void>*,std::string,std::string)"
  Failed to instantiate "Define(ROOT::RDF::RInterface<ROOT::Detail::RDF::RJittedFilter,void>,std::string,std::string)"

It looks like the jetFlavourHelper is calling some C++ code (like JetConstituentsUtils::get_mtof) that expects an edm4hep::TrackerHitData collection, but this data type doesn’t seem to exist in the edm4hep.

How do I solve this issue?

2

Hi @sbakare,

Can you try using the Key4hep stack, which comes with the pre-edm4hep1 branch of the FCCAnalyses?

source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-03-10

or

git clone --branch pre-edm4hep1 https://github.com/HEP-FCC/FCCAnalyses.git
cd FCCAnalyses
source ./setup.sh

The tutorial is using winter2023 samples which are no longer compatible with the latest Key4hep stack.

Best,
Juraj

1 Like
3

Hi @jsmiesko

Thank you so much! Yes, that works perfectly for the older (pre-edm4hep) samples.

I have a follow-up question, though. I’m now trying to run the analysis on my own locally produced EDM4hep samples (generated with MG+P8+Delphes), but it gives an error as the EDM4hep tree structure is different.

Could you please guide me as to how I can produce similar results for these new EDM4hep samples?

Thanks again for your help!

Best, Shreyas

4

Hi @sbakare,

FCCAnalyses is provided pre-compiled in each Key4hep stack, you can try using this version of the FCCAnalyses just by running fccanalysis command. If you want to be sure that FCCAnalyses will be able to understand your samples, I recommend sourcing the same stack as was used for the creation of the sample.

One of the limitations of the FCCAnalyses from the stack is that once the stack is released everything in it is frozen and no additional features or bug fixes can be added. In order to benefit from the latest changes in the FCCAnalyses you can compile it yourself using the procedure from the tutorial, except instead of cloning pre-edm4hep1 branch you would clone the main branch. The same advice holds also here, in order to be sure that your compiled version FCCAnalyses understands the samples you generated, you need to compile the FCCAnalyses in the same stack.

Note about the pre-edm4hep1 branch: The differences between the current stack and the stack which was used for the creation of the winter2023, and similar samples, was too great to be able to overcome it just by recompilation, that is why we, for now, also maintain this version of FCCAnalyses.
Nominally, analyzers not using the winter2023 samples should use main branch of FCCAnalyses.

Note about sourcing the Key4hep stack: FCCAnalyses respects the Key4hep stack which is already set up in the environment, so the nominal procedure to compile FCCAnalyses should start with sourcing of the appropriate stack. In case one wants to have everything in just one command, FCCAnalyses (main branch) now supports providing parameters for the sourcing script. You can see the options by running source setup.sh -h. But I’m also listing them here:

-l/--latest         Setup the latest release of the Key4hep stack
-n/--nightlies      Setup the latest nightlies version of the Key4hep stack
-p/--pinned         Setup the pinned version of the Key4hep stack
-b/--from-build     Setup the version of the Key4hep stack used for the latest

Best,
Juraj

5

Thank you @jsmiesko this clears a lot of confusion I had.

When I try 2.2.1: Generate and Simulate Events with DelphesEDM4Hep as per the instructions, with official winter2023 Pythia and Delphes cards and sourcing the pre-edm4hep1 branch to use DelphesPythia8_EDM4HEP, it generates the edm4hep samples with different structure than the ones used in the tutorial.

Please correct me, So if I want to run the treemaker_flavor.py on these samples, I need to change the names of the collections in the code appropriately. (i.e. Muon#0.index should be Muon_objIdx.index and so on) Right? And then I can run fccanalysis run treemaker_flavor.py ?

If so, can you please guide me to the naming documentation or examples to learn more?

6

Hi @sbakare,

Are you generating your samples in this stack?

/cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-03-10

or in the latest release?

/cvmfs/sw.hsf.org/key4hep/setup.sh -r 2025-05-29

One of the differences between winter2023 samples and the samples generated in the recent stacks is different naming system for the EDM4hep branches (i.e. Muon#0.index → Muon_objIdx.index and so on). So if you want to use the example analysis script treemaker_flavor.py, which works with winter2023 samples, with the new samples you need also to adjust your analysis script.

Best,
Juraj

7

Hi @jsmiesko , Yes I want to adjust the current analysis script with the new samples. But I am finding it difficult to understand the changes I need to make. Are there any examples or documentations that you can point me to please?

8

Hi @sbakare,

we do not have a dedicated documentation for the transition, but the pull request with the change should be somewhat helpful: AIDASoft/podio#405.

Best,
Juraj

9

Hello @jsmiesko ! Thank you very much for your help so far.

I realized one thing,
if I generate Pythia8 + Delphes samples using the following Key4hep stack:

source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-03-10

and if I use pre-edm4hep branch of the FCCAnalyses (the one that comes with this same stack) to follow 2.4.1 and 2.4.2 of FCCTutorial (with necessary changes in the branch names) everything works perfectly.

But when I try and generate Pythia8 + Delphes samples using the latest Key4hep stack:

source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2025-05-29

and if I use the FCCAnalysis that comes with this same stack to follow the same tutorials (with necessary changes in the branch names), 2.4.1 of FCCTutorial works fine.

But 2.4.2 of FCCTutorial does not work (!!)

Here is the long error that I encounter:

Why does this happen? I am using the same latest stack [-r 2025-05-29] for generation as well as for fccanalysis, so it should work (if it works for [-r 2024-03-10] stack) right? or am I missing something here?

Best,
Shreyas

10

Hello @jsmiesko

I think this has to do with the way collection: "dNdx": "EFlowTrack_dNdx" is stored.

2.4.1 Works well because it does not use dNdx, whereas 2.4.2 of FCCTutorial uses it.

In my understanding, FCCAnalysis [Both 1. FCCAnalysis from the latest Key4hep stack [-r 2025-05-29] and 2. FCCAnalysis cloned from the master branch and compiled] expect the collection "dNdx": "EFlowTrack_dNdx" to be in const RVec<edm4hep::Quantity> format. But, the DelphesPythia8_EDM4HEP (from the same latest Key4hep stack [-r 2025-05-29]) generates EDM4hep files containing "dNdx": "EFlowTrack_dNdx" collection of the format edm4hep::RecDqdxData. Please correct me if I am wrong.

Thank you again! Best, Shreyas

11

Hello @sbakare,

this is an example where FCCAnalyses analyzer needs to be updated to a change done in the previous step of the event processing chain, can you try updating the concerned function/functor? And submit a PR with the change?

Best,
Juraj

12

Hello @jsmiesko ,

Thank you for the guidance.

I have updated the function to handle the RVec<edm4hep::RecDqdxData> type and submitted a Pull Request with the fix:

Best,
Shreyas

1 Like