dataesr/scientific-paragraphs-categorization huggingface dataset:
Raw data handling, filtering, and calibration Raw data from the detector were acquired in units of runs, defined as periods of operation under stable conditions, bounded to limit the resulting file sizes. Typical runs lasted for 30-60 min and contained 10 5 -10 6 events accepted by the L3 trigger. The detector systems required a variety of calibrations to support the event reconstruction algorithms. Derived calibration constants were stored in the conditions database in a crosssubsystem framework defined in the original offline software. The acquisition and processing of calibration data fell into two classes: dedicated-data online calibrations, described above in Section 3. 2. 3, and offline calibrations based on regular collidingbeam data. Of the latter, most were carried out in an extensive automated framework.
In the PC processing for each run, a full reconstruction of the selected events was performed using the calibration constants from the previous run. New constants were generated as permitted by the accumulation of sufficient statistics. This processing had to be performed in the order of data-taking, in order to follow the evolution of detector behavior, and accumulate statistics across multiple runs. The new constants from PC were written to the conditions database. Once this was done, the ER pass was able to process each run in an order-independent way. Among the automated offline calibrations, the duration of colliding-beam data-taking required for a statistically significant calibration varied from minutes to days. Supporting this range of data requirements was a key design goal for the offline calibration system.
The calibration processing was separated into two steps: the accumulation of statistics, and the fitting of calibration constants to the resulting data. In the first phase, data were reconstructed, with the calibration constants from the previous run, and, for each type of calibration, a specific set of reduced data (typically some form of per channel statistics such as a histogram) was accumulated per run. For each type, once sufficient data for a valid calibration had been accumulated, the data were combined and the second phase of calibrationconstants fittingwas performed. The resulting constants were automatically validated against defined standards and checked for unexpectedly large changes from the previous set. They were then stored in the Conditions database for application to any further processing of the present and subsequent runs.
In the final years of BABAR, keeping up with the rate of data acquisition required the parallelization of PC processing across 40-60 CPU cores. Results from the multiple processes were accumulated using a version of the same mechanism used for accumulation over multiple runs. The PC processing was performed at SLAC. The systems for accumulation of data across multiple parallel jobs, and across successive runs, were known as the spatial and temporal databases, respectively. An early implementation of these databases, in Objectivity, is described in Ref. [117]. In the final version of the offline system these databases were reimplemented in the ROOT framework.
Simulation A full MC simulation of the detector and interaction region was developed. The simulation of the basic e þ e -collision physics was performed using a variety of event generators. These were primarily based on the EvtGen  [119]  toolkit developed for CLEO and BABAR. The GEANT4 toolkit  [11]  was then used to simulate the propagation of particles through the detector geometry, and produce a record of their interactions with the detector elements. BABAR-specific software was then used to convert this record into simulated digitized raw data, which was then subjected to full reconstruction. The L1 and L3 trigger and offline filter selection algorithms were evaluated as part of the reconstruction of all simulated data, facilitating the understanding of their effects on detection efficiency for physics processes.
The resulting reconstructed event collections were returned to SLAC. The final simulated dataset, corresponding to the version of the offline software described here, contains approximately seven billion events for specifically requested physics processes and 20 billion generic events. The numbers of generic events generated were chosen to correspond to specific multiples of the numbers of events produced at the ϒð4SÞ resonance. The sizes of the generated samples, as multiples of the production cross-sections for specific final states, are shown in Table  15  for the final simulation production. Earlier production cycles had multiples in the range of one to three. Handling of detector conditions and trigger evolution: The simulation system was designed to track the evolution of the detector and accelerator conditions.
For each calendar month of datataking, a representative set of detector configurations (including the trigger configuration) and conditions (including the constants produced by PC) were selected by detector system experts. In simulation production, event generation requests were divided into increments for each data-taking month, in proportion to the recorded integrated luminosity for the month, and produced using the corresponding configurations and conditions. This produced a luminosity-weighted simulated dataset that reflected the actual history of data-taking. Trigger and filter algorithms corresponding to the monthly configurations were applied to the simulated data as part of their generation and reconstruction. This had the interesting software-maintenance consequence that the final simulation application had to be able to apply all the software trigger algorithms used in the history of the experiment, including ones long since retired from use in data acquisition.
Skimming The final dataset contains more than nine billion events passing the pre-reconstruction filter described above, primarily taken on the ϒð4SÞ resonance. This dataset has been inconveniently large for frequent access by the several hundred collaboration physicists. In order to decrease the number of events needed to be processed as input for analyses and decrease contention from many users accessing the same data, one further step of central processing was applied to the data, the skimming process, which performs two actions: selecting subsets of events deemed to be interesting for various groups of analyses, and pre-processing those events to compute commonly needed quantities and perform multi-particle combinatorics to reconstruct short-lived intermediate states, such as neutral kaons and D mesons.
Persistence of the event data is handled by a translation layer which converts the native C++ BABAR object model to an external form based on the object-persistency framework provided by the ROOT toolkit  [116]. The transient-persistent translation insulates the reconstruction and analysis code from the choice of persistency mechanism. This was crucial to the ability to evolve the persistency model, as described below. The persisted data is in the form of ordinary POSIX [124] files containing data in the ROOT format, together with a meta-data catalog maintained in a conventional relational database. The catalog is supported by a set of tools that permit the versioning and evolution of datasets over time and facilitate production and user analysis tasks running over the large number of files comprising the data  [125].
These tools provide provenance tracking for datasets and ensure the integrity of datasets (completeness and avoidance of inclusion of multiple processings of the same run or unit of simulated data). The BABAR analysis framework supports reading and writing data either via POSIX APIs, covering a variety of file system types (including NFS  [126] , GPFS  [127] , as well as locally attached disk), and via the BABAR-developed Xrootd protocol  [128, 129]. At the production computing facilities, almost all data access uses Xrootd. The Xrootd system provides a simple POSIX-like random file access API, optimized for large transfers, with support for faulttolerance, load-based replication, and a site-wide server-independent namespace. At times when hundreds of analyses were in progress, the provision of sufficient compute capacity required contributions from all the major national computing sites.
The use of C++ still left the data persistence problem unresolved. However, just as the experiment was being designed, a new objectoriented database technology was being adopted in the commercial software market, driven by the rapid acceptance of object-oriented languages in professional software engineering. This technology offered the promise of directly persisting complex objects and their relationships, freeing developers from implementing custom object and reference serialization solutions. It also provided a framework for the organization and cataloging of datasets, another long-standing challenge for HEP experiments. The use of a true database also offered hope that the complex data filtering and selection frameworks independently developed by many experiments could be replaced by the use of structured database queries.
Motivated by the very large datasets expected for the LHC, various research projects in the mid-1990s had explored the use of both relational and object-oriented database technologies for the persistence of HEP data, as an alternative to the use of ZEBRA-like systems and serial tape storage  [131]. The results of these explorations suggested that object-oriented database systems did have attractive features for HEP data. In particular, the CERN RD-45  [132, 133]  study, aimed at selecting a technology for LHC use, ultimately recommended the use of a specific commercial objectoriented database, Objectivity/DB  [134]. Based on these studies and additional performance and scaling tests, BABAR adopted this recommendation, becoming the first major HEP experiment to put this technology into production for event data storage.
By the start of data-taking in 1999, significant problems with this technology choice had become apparent. While the object-persistence features of an object-oriented database had proved useful, other aspects of the database architecture were emerging as ill-suited to HEP data production and analysis, or were a poor fit to other design choices made by BABAR. Moreover, specific performance problems with the vendor implementation were encountered. The transaction model supported by Objectivity proved inappropriate to the write-once, append-only, read-many access pattern typical for HEP event data. Writing to the database generally involved the creation of locks which obstructed the ability to write simultaneously from many sources, in direct conflict with the natural parallelism of HEP data processing.
While improvements in the vendor implementation and in the use of locking by BABAR allowed significant increases in scalability, ultimately the need to lock meta-data objects in the database could not be avoided. This limitation was partially alleviated by maintaining multiple copies of the database for production and user analysis. However, maintaining the consistency of these replicas introduced considerable fragility and complexity to the system. Objectivity provided mechanisms to control of the placement of data, but they lacked the flexibility needed to support optimization of the I/O patterns and to avoid the performance penalties of random-access loads on disk drives. In addition, the Objectivity bulk data and lock server processes presented significant scaling and fault-tolerance problems.
Intensive work with the vendor did result in substantial performance improvements, sufficient to support the initial years of BABAR operation. However, the software engineering effort by the experiment to support this work was found to be unsustainable, especially because of the lack of access to the proprietary Objectivity source code inhibited the detailed understanding of the performance of the database. The complexity of the system developed to overcome the limitations of the database limited the experiment's ability to deliver newly acquired data to analysts in a timely manner, producing considerable dissatisfaction in the collaboration, especially in view of the rapid growth and high quality of the dataset. Further, the original expectation that analyses would be performed on a single event store, with preselections performed via database queries or through the use of lists of pointers to previously identified events of interest, proved impractical to implement, as it would have generated intolerable randomaccess loads on disk-based storage.
The model actually deployed required the production of up to 200 parallel streams of events, with significant levels of duplication of data, in order to relieve the random-access bottleneck and other scaling problems. However, this approach then ran into limitations on the total numbers of object collections in the internal Objectivity data model, producing serious operational constraints. The complexity of both the BABAR and vendor database implementations also became a significant obstacle to distributed computing. The difficulty of installing and supporting the database made it infeasible to perform data analysis at small sites and on personal computers, especially in the absence of network connectivity. BABAR relied on a group of 10-20 institutions to perform a large fraction of simulation production, and the support of the Objectivity database at each site represented the majority of the system administration effort involved.
It did, however, require the development of a new infrastructure for cataloging the ROOT-format event data files. This was developed using standard relational database technology. The micro-DST data corresponding to the first three years of BABAR data acquisition yielded approximately 3 Â 10 5 files comprising a total of 4:2 TByte. These files were all kept on disk, stored on a set of NFS file servers. The largest file sizes in this scheme were a few hundreds of megabytes, to be compared to file sizes of tens of gigabytes for Objectivity, driven by the need to keep the total number of files below a vendor-imposed limit. The ROOT file format naturally supported compression, with a column-oriented data model that led to significantly improved compression statistics compared to the data compression later offered by Objectivity.
The Objectivity-based production systems for reconstruction and simulation were not changed, but their output was converted to the new micro-DST format in an additional processing step. The experience with this system was very positive. It greatly simplified data cataloging and distribution to remote sites, which could now maintain copies of the event data even with limited technical expertise. The reduced event size led to reduced I/O loads and facilitated the scaling up of analysis resources at SLAC and other sites. The success of this initiative led to a decision to re-implement the entire event store along these lines, during the period 2003-2005. This required supporting features of the event store not needed in the experimental analysis-only system, most notably the ability to persist pointer relationships between analysis and reconstruction objects, tracing the derivation of analysis quantities from lower-level reconstructed data.
This feature was particularly crucial to support the new event summary data event component that had been deployed following the start of BABAR production  [136]. A full reimplementation of event persistence also required the use of a much more robust file serving system to support the scale and fault-tolerance required for the combination of production and analysis needs, and the expected growth of the BABAR dataset with increasing luminosity. The Xrootd system described above was developed to meet this need. The non-event databases that had been developed using Objectivityconditions, configuration, and ambientdid not have comparably serious performance and scaling problems, and were left intact in the new computing model. In the final years of operation, however, all remaining uses of Objectivity were replaced with combinations of ROOT for bulk data storage and a conventional relational database for catalog meta-data.
This was motivated primarily by the desire to reduce the operational and support costs associated with commercial software. The reimplementation of the conditions database persistence was more difficult and more disruptive than it had been for the event store, primarily because its original design lacked a transient-persistent translation layer. Significant sections of calibration, reconstruction, and simulation code thus depended directly on the persistent objects defined in Objectivity and required modifications when the new ROOT persistence technology was introduced. Additional details of the migration of the non-event databases are described in Section 3. 2. 3 above. Other than the introduction of the non-Objectivity event store, the most significant architectural change to offline computing in the new computing model was the separation of the generation of calibration constants from the reconstruction of the full event data stream.
Overview As the end of BABAR data taking approached, it became evident that physics analyses would continue for several years. The large data sample offered unique opportunities for future studies, extending over the succeeding decade. Furthermore, in response to new theoretical insights, improved experimental techniques, the necessity for cross checks mandated by new results elsewhere, or the quest for higher sensitivity of combined analysis, could motivate extended or often highly sophisticated new analyses of the data. The final BABAR dataset produced with the most recent software release, referred to as R24, consists of over 9 Â 10 9 reconstructed physics events and 27 Â 10 9 simulated events that, including the skimmed data, are stored in 1. 6 Â 10 6 files. The total data amount to about 2 PByte, specifically 700 Tbytes of raw data, and 985 Tbytes and 653 Tbytes of reconstructed real and simulated data for the two most recent software releases, R24 and the earlier R22, both being actively used in ongoing analyses.
These data are referred to as Legacy data. The BABAR collaboration decided that the best way to preserve this most valuable heritage of the experiment was to create a computing system that would sustain the full analysis capability, including the preservation of the data and the reconstruction and simulation software, accompanied by detailed documentation for future users. The primary challenge was to design and implement such a system at a time when resources available to the collaboration were already declining and experts for data analysis and computing were transitioning to other experiments. To assess the scope of such a data preservation project the collaboration determined the number of actual and projected publications per year. Not accounting for new initiatives, the future research activity is expected to extend to at least 2018 and result in more than 60 publications, as can be seen in Fig.
93. These results of this study led to the inception of a formal BABAR data preservation project in 2008, referred to as the Long Term Data Access (LTDA) project. After intense R&D, consultation and planning, the LTDA hardware acquisition and setup was completed by the end of 2011. A period of software installation, configuration, testing, and benchmarking followed until the LTDA system was officially ready at SLAC in March 2012. By this time, several BABAR collaboration members were already using the system; since then the LTDA use has substantially increased. Conceptually, the LTDA system operates as a separate logical site, similar to the remote analysis and production sites associated with BABAR. In the following, the LTDA requirements and goals are presented, and the implementation, benchmark testing, and operational experience are described.
Goals and requirements The primary LTDA design goal was to preserve the full ability to analyze the BABAR data at least until the end of 2018. Future analyses may require revised event selections, improvements to calibrations and event reconstruction algorithms, simulations of new signatures, and new studies of efficiencies and corrections to the simulation. Therefore, in addition to being able to analyze the R24 and R22 datasets, the LTDA system also needs to preserve full access to raw data, simulated data and control samples for calibrations; allow performance of event reconstruction, skimming, analysis, and fitting procedures; and provide the complete support of code repositories, database and tools, accompanied by accurate documentation for current and future users. With the expected decline of the availability of computing professionals after the cessation of data taking, and the continuing rapid changes in storage technology, computing, and software systems, maintenance and the migration of the data analysis infrastructure to newer systems posed a major challenge.
Design The design approach chosen to address the above requirements was that of a contained computing system, allowing the creation of a controlled environment that simplifies the support of the BABAR analysis framework within a frozen operating system, shielded from upgrades. This also simplifies software maintenance, documentation and user support and requires less personnel to maintain the system. Users are able to access the frozen platform interactively for code development, debugging, and via batch queues for bulk data processing. All frequently accessed data are made available on disk to provide good performance in a standalone environment, and to limit the need for access to the SLAC tape system which serves primarily as a data backup system. The estimate of the required CPU power was based on the projected analysis activity, as reported in Fig.
93. The amount of disk storage was determined to be 1. 3 PByte based on the size of the R22 and R24 legacy datasets; raw data are not kept on disk since they are not directly usable for physics analysis. The entire legacy dataset was migrated to new tape media at SLAC in 2010 and, in preparation for the long term data analysis period, backed up at the IN2P3 computing center in Lyon (France).
Based on these and other tests, the standard LTDA system was configured to use KSM and hyper-threading with up to 22 VMs per compute and storage server and up to 24 VMs per compute-only server. Overall, no performance decrease for data processing with virtualization compared to the conventional processing environment has been observed. In summary, the LTDA system has been successfully implemented and is gradually taking the place of the original BABAR computing system. It is currently used for tens of physics analyses by users, most of them working from remote home institutions. Through the use of virtualization and a unique combination of processing and storage systems, this novel system meets the BABAR analysis needs, while maintaining the familiar analysis environment. The use of Xrootd, interfaced with the SLAC tape library, mitigates the impact of occasional disk failures.
Summary The diverse BABAR physics program was based to a very large degree on technological achievements, the delivery of stable beams of ever increasing luminosity by the PEP-II storage rings, and the reliable operation and excellent performance of the BABAR detector and its associated software, both online and offline. PEP-II exceeded its design luminosity within its first full year of operation, and its performance continued to improve in the following years. By the end of data taking in 2008, the instantaneous luminosity had reached a peak of 12 Â 10 33 cm -2 s -1 , and up to 20 fb -1 were delivered per month. This was achieved through changes to the mode of operation and upgrades, the most prominent were the increase in beam currents, and the implementation of trickle injection. The beam orbits, tunes, and other critical parameters were optimized frequently.