{'fraction_non_alphanumeric': 0.01965163019205002, 'fraction_numerical': 0.006811076373380974, 'mean_word_length': 5.043859649122807, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
The CMS Reconstruction Software

We report on the status and plans for the event reconstruction software of the CMS experiment. The CMS reconstruction algorithms are the basis for a wide range of data analysis approaches currently under study by the CMS collaboration using the first high-energy run of the LHC. These algorithms have been primarily developed and validated using simulated data samples, and are now being commissioned with LHC proton-proton collision data samples. The CMS reconstruction is now operated routinely on all events triggered by the CMS detector, both in a close to real-time prompt reconstruction processing and in frequent passes over the full recorded CMS data set. We discuss the overall software design, development cycle, computational requirements and performance, recent operational performance, and planned improvements of the CMS reconstruction software.


The CMS Experiment
Software for the Compact Muon Solenoid (CMS) experiment must support a variety of user applications from a single, shared code base. Applications span the entire range of experimental work, and include the online trigger system, reconstruction and simulation executables, data quality monitoring, analysis-based event skimming and user data analysis. The requirements for these applications differ substantially, however a single code framework (CMSSW [1]) provides an efficient structure for code reuse and shared algorithm development. With hundreds of active developers, frequent software releases facilitate integration of new features as well as bug fixes identified in production activities.
In this paper, we discuss the development and status of the event reconstruction software in CMS. The algorithms that make up the CMS event reconstruction software build physics objects (e.g., muons, electrons, jets) from the raw data recorded by the detector. All events collected by the CMS trigger system are reconstructed by the CMS prompt reconstruction system soon after being collected. Subsequent processings are carried out in order to incorporate improvements to software algorithms and updated detector calibrations, however the prompt reconstruction data samples have made up much of the data used for CMS physics results with the initial LHC data samples. In addition, a subset of the event reconstruction algorithms make up part of the high-level trigger system, which reduces the data recording rate from approximately 100 kHz of Level-1 trigger accepts down to a few hundred events/second of data written to tape rate.
Over the past year, the first proton-proton data from the LHC has changed much of the development focus of the reconstruction algorithms to handle the changing accelerator and detector conditions seen in these data. In these proceedings, we discuss the basic structure of the CMS event reconstruction software and summarize technical performance characteristics observed with recent data samples. Figures 1-4 summarize some of the basic physics object performance results using the initial LHC proton-proton data samples. We show tracking, muon, electron and calorimetric performances. Data driven methods are used, and we compare results with expectations from Monte Carlo simulations. Our Monte Carlo simulations were tuned with detector calibrations and alignments based on expected early data taking conditions. We see excellent agreement between data and simulation results. In the case of the resolution on the measured total transverse energy (E T ) in the event, our particle flow based algorithm is already at the anticipated design (TDR) performance level. Further details on each result can be found in references [2,3,4,5,6].    Figure 5 summarizes the flow of reconstruction algorithms used to reconstruct raw data. Data are first unpacked into single detector objects, which are then used to form physics objects such as tracks, photons and muons. Finally, these are refined by additional algorithms such as those that estimate the missing transverse energy of the event and that determine the probability that each jet in the event is due to a b quark.

Software structure
In the CMSSW software framework, algorithms are formed by one or more modules. Modules are configurable through a python interface and communicate by placing objects into an underlying event object and making use of objects placed into the event by other modules. Typically, tens of modules are defined to implement each component of the event reconstruction.  Figure 6 summarizes the time to process events in a recent data (October 2010) proton-proton run. The different contributions shown in Figure 2 correspond to the trigger path used in the decision to save each event for offline analysis. We show data from the minimum bias, muon, electron/photon and jet triggers. We see that the average time to process an event ranges from 1.2 seconds (for minimum bias triggers) up to 2.6 seconds (for jet triggers). These event processing times are a strong function of the events actually recorded by the CMS trigger. As the trigger accept rate has changed only slightly while the LHC luminosity has increased by orders of magnitude, we have observed more than a factor of ten increase in average event processing times since early LHC proton-proton runs.

Software performance
We see that one event in approximately 20,000 has a processing time above 20 seconds. These events typically correspond to an abnormal detector condition and have been used to reveal inefficient algorithm implementations over the past year. The current rate of these long-running events is sufficiently low as not to cause an operational problem, and does not significantly impact the average event processing rate.   Figure 6 also shows the memory usage of the reconstruction algorithms, measured as the total VSIZE of the application. We see that the algorithms themselves, including calibrations and geometry definitions, are around 800 MB. Adding also the memory used by the output file buffers and dataquality histogram codes brings the total up to about 1200 MB, which is well within the total memory budget for the CMS prompt reconstruction system. We do observe events with large combinatorics (primarily in the tracking algorithms) that lead to jumps in memory usage beyond that shown in Figure  6. Over the commissioning phase of CMS, we have worked to reduce the operational impact of these events through algorithmic improvements. Gains in memory usage (and fragmentation) have been achieved through studies based on specific events where a large memory increase is observed and through ongoing efforts to reduce memory allocations in CMS production applications. As the rate of complex events increases with luminosity, we expect to continue this effort over the coming run.
The contribution from the output file buffers is driven by the total data volume written out by the reconstruction algorithms for use by analysts. CMS has two data tiers for detector commissioning and analysis use. The "RECO" tier is around 350 kB/event in current data samples (470 kB/event in t-tbar Monte Carlo events) and is designed primarily for detector commissioning. While essentially all current analyses in CMS are based on the RECO data tier, it is too large to be widely distributed during the 2011 data run. We are in the process of moving most analysis work to the "AOD" tier, which is less than 100 kB/event on current data samples (130 kB/event in t-tbar Monte Carlo events). The largest contributors to the AOD event size are the detailed calorimetric data saved to enable rerunning jet creation algorithms on the AOD data and the detailed information needed for the CMS particle flow algorithms.

Outlook
The first year of LHC proton-proton running has been an important test of the operational robustness of the CMS reconstruction algorithms. We have observed only a handful of job crashes in the past several months of running, and typical event reconstruction time and job memory footprint are similar to expectations. As the LHC luminosity and average number of pile-up events increases, algorithms will be further challenged with more complex event topologies. In addition to improvements to operational stability, we continue to integrate feedback from on-going analysis to improve the physics performance of the reconstruction algorithms. In addition, the increased luminosity will require that additional algorithms be incorporated into the CMS high-level trigger. This will require performance improvements and/or algorithm simplification given a CPU budget of around 40 msec/event in the trigger system. Ongoing work is focused on adapting our event reconstruction software for the 2011 LHC data run and on longer term performance requirements. In particular, we are in the process of adopting the AOD data tier for most physics analysis work in CMS, and looking at algorithms that scale poorly as the average pile-up increases.