NANOAOD: a new compact event data format in CMS Karl Ehatäht (NICPB, Tallinn) on behalf of the CMS collaboration karl.ehataht@cern.ch Future prospects References • Promote the format to achieve target adoption of 50-70% of all CMS physics analyses • Develop customized NANOAOD formats for specialized tasks such as automation of object calibration workflow • Explore the possibility to add support for alternate choices of generator information and parton distribution functions which are currently expressed as event weights but do not fit within the typical NANOAOD event size • Increase the frequency of producing new NANOAOD Ntuples [1] "The NanoAOD event data format in CMS", M. Peruzzi, G. Petrucciani, A. Rizzi, ACAT 2019 [2] "A further reduction in CMS event data for analysis: the NANOAOD format", M. Peruzzi, G. Petrucciani, A. Rizzi, EPJ Web Conf. Volume 214, 2019 AK4 jets, 382, 23% Generator-level particles, 310, 19% Electrons, 117, 7% Generator-level AK4 jets, 91, 6% Vertices, 87, 5% Hadronic taus, 84, 5% Muons, 75, 5% Trigger objects, 73, 4% Others, 422, 26% 1-3 MB 500 kb 50 kb 1-2 kb RAW AOD MINIAOD NANOAOD Event size Introduced in year 2009 / 2010 Run1 2011 / 2012 LS1 2013 / 2014 End of Run2 2018 / 2019 Typically run twice a year ~1 month runtime, run every few months 1-2 week runtime Motivation ROOT Ntuple ‒ nObject ‒ Object_var[i] ‒ Object_otherIdxQualifier[i] ‒ ... Self-descriptive collection name (example: Electron, Muon, Tau, Jet) Size of the collection (range of [i]) (example: nMuon, nPhoton) Link / cross-reference to associated collection (example: Muon_jetIdx, GenPart_genPartIdxMother) Event-level variables such as: MET (MET_pt, MET_phi), PDF weights (n/LHEPdfWeight), trigger bits (HLT_*), … i-th object in the collection Attribute of the object (example: Tau_eta, Jet_btagDeepB) Provenance tracking TTree::GetEntry() to access the event content ROOT::TTree ROOT::TBranch Figure 2. Breakdown of a simulated 𝑡ҧ𝑡event by average storage size of its high level objects (in bytes). Figure 1. Evolution of data tiers used in CMS. Figure 4. Structure of NANOAOD Ntuple [2]. ‒ Events ‒ LuminosityBlocks ‒ Runs • Standardized access to complex high level physics objects – simplifies automation of physics analyses • No need for CMS software to perform data analysis • Lower barrier of entry for new students • Enables open data access for people outside CMS • Documentation of physics objects embedded in NANOAOD Ntuples • Increases integrity and quality of physics analyses • Modular structure of the NANOAOD format promotes parallel and continuous development • Time between data recording and publication shortened • No need for custom Ntuple production by individual analysis groups • Typical thresholds used in physics analyses applied to high level physics objects (𝜇, 𝑒/𝛾, 𝜏ℎ, jets) • Storing the output of 𝑒/𝛾, 𝜏ℎand 𝑏-jet identification algorithms, rather than the input variables to these algorithms • Not storing redundant information that can be later derived from the event content (such as systematic variations of jet energy scale) • Not storing 32-bit floating point numbers at full precision because experimental measurements are not performed at this high precision • File size further reduced with LZMA compression algorithm • Production fast at 10 events / second / core • Reading faster than kHz with decompression • Required storage in data tiers projected to reduce by a factor of two (more than 2 exabytes) if 50% of the analyses switch from MINIAOD to NANOAOD during HL-LHC [1] • No tracks or individual particle • No details about detector configuration candidates, store jets instead • No object cleaning and skimming applied to maintain flexibility on an analysis level 0 20 40 60 80 100 120 09/2017 03/2018 09/2018 03/2019 09/2019 Number of forks Centrally maintained companion tool available to perform analysis-specific steps after NANOAOD production: • Computation of systematic variations of physics observables, data to simulation c