CERN Prototype

From DUNE
Jump to navigation Jump to search

Materials and Meetings

Infrastructure

Expected Data Volume and Rates

Estimates in this area were developed over a period of time. Both data rate and volume are determined primarily by the number of tracks due to cosmic ray muons, recorded within the readout window, which is commensurate with the electron collection time in the TPC (~2ms).

For a quick summary of the data rates, data volume and related requirements see:

A few numbers:

  • Planned trigger rate: 200Hz
  • Instantaneous data rate in DAQ: 1GB/s
  • Sustained average: 200MB/s

The measurement program is still being updated, the total volume of data to be taken will be ~O(1PB). Brief notes on the statistics can be found in Appendix II of the "Materials" page.

Software and Computing

Intro

As of March 2015, this is work in progress. In accordance with common requirements, we anticipate preserving three copies of "precious" data to be collected during the experiment. One primary copy would be stored on tape at CERN, another at FNAL and auxiliary copies will be shared between US sites e.g. BNL and NERSC. There are proposal to reuse software which was proven in IceCube and Daya Bay experiments, to move data between CERN and the US with appropriate degree of automation, error checking and correction, and monitoring.

The salient point of the Software and Computing plan is near-time processing and monitoring of data quality, including full tracking in express production streams. This can be done on a subset of the raw data. At the same time, a rough estimate indicates that for off-line processing, ~5000 cores will be sufficient to process data with about same speed as it is collected.

Handling the data

Storage at CERN

EOS is a high-performance distributed disk storage system based on XRootD. It is being used by major LHC experiments as the destinations to which DAQ is writing raw data.

CASTOR is the principal tape storage system at CERN. It does have a built-in disk layer, which was earlier utilized in production and other activities but this is no longer the case since this functionality is handled more efficiently by EOS. For that reason, the disk storage that exists in CASTOR serves as a buffer for I/O and system functions.

Historical references and more recent writeups can be found in Appendix III of the "Materials" page.