DaMI metadata fields

Discussion

Pantelis Kontaxakis (University of Geneva), Juraj Smieško (CERN)

Training of the MC Production contacts

CERN, 13/3-005

21 October 2026

Current LFN schema

  • Directory
    
    /fcc/<machine>/<campaign>/<energy>/<process>/[<detector>/]<datatype>/<prodID>/
                        
    • Datatype
      • Generator level: stdhep, hepmc, lhef
      • Fast sim: delphes
      • Full sim: sim, rec
    • <detector> only for fast and full sim; KKMC has the generator there instead
  • File
    
    <prodID>/000/<process>_<datatype>_<prodID>_<task>.<ext>
                        
    • <datatype> matches the directory, except two hepmc productions with gen in the file name
  • EOS path: /eos/experiment/fcc/prod + LFN

LFN examples

  • Generator level: file format as datatype, generator only for KKMC (without campaign)
    
    /fcc/ee/test_spring2024/240gev/ZH/stdhep/00016879/000/ZH_stdhep_16879_1.stdhep
    /fcc/ee/spring2024/50gev/nu/hepmc/00800000/000/nu_hepmc_00800000_0.hepmc
    /fcc/ee/winter2023/91.19gev/tautau/lhef/00016140/000/tautau_lhef_16140_1.lhe
    /fcc/ee/91.2gev/tautau/kkmcee/lhef/00015639/15639_weights_events_info.tar.gz
                        
  • Fast sim (Delphes): detector label and delphes
    
    /fcc/ee/summer2026/240gev/ZH/IDEA/delphes/00017123/000/ZH_delphes_17123_1.root
                        
  • Full sim (CLD): detector version and sim/rec, one production ID per step
    
    /fcc/ee/test_spring2024/240gev/ZH/CLD_o2_v05/sim/00016880/000/ZH_sim_16880_1.root
    /fcc/ee/test_spring2024/240gev/ZH/CLD_o2_v05/rec/00016881/000/ZH_rec_16881_1.root
                        
  • Energy written as 240gev, 91gev, 91.188gev, 91.2gev; some productions without campaign

LFN schema proposals


# A: generator in place of the detector at generator level
/fcc/<machine>/<campaign>/<energy>/<process>/<detector|generator>/<datatype>/<prodID>/

# B: generator and detector always present
/fcc/<machine>/<campaign>/<energy>/<process>/<generator>/<detector|none>/<datatype>/<prodID>/

# C: datatype first
/fcc/<machine>/<campaign>/<datatype>/<energy>/<process>/<detector|generator>/<prodID>/

# D: DaMI dataset name in place of the energy and process
/fcc/<machine>/<campaign>/<dataset>/<datatype>/<prodID>/
              
  • A: <datatype> = file format at generator level, stage (delphes/sim/rec) after it, EDM4hep implied
  • B: generator recorded for every datatype, fixed depth
  • C: one subtree per datatype, easier cleanup and quotas
  • D: path follows the DaMI record, e.g. p8_ee_ZH_ecm240
  • In any case: one energy format, one capitalisation of the detector labels

Candidate metadata fields

Identification dataset name★, campaign★, accelerator★, stage★, detector★, file type★
Physics process description★, centre-of-mass energy★, generator and version★, generator-level cuts
Normalisation cross section★ (unit, source), k-factor, matching efficiency, sum of weights
Statistics number of events★, number of files, size
Provenance Key4hep release★, generator card★, config version★, DRS request★, transformation IDs★
Location EOS path★
People requester★, MC contact★
Status validation★, known limitations, comment

★ proposed as required

To settle

  • Which fields are required, which are optional?
  • Names and units of the keys, e.g. cross section in pb
  • Where does the cross section come from, and who fills it in?
  • One record per process, or per process and step?
  • Validation: a simple status, or a reference to what was checked?
  • Regular checks of the records: what is checked, and how often?

The MC contacts keep the agreed fields in order for the datasets of their physics group