1 / 9

LHCb computing highlights

The LHCb experiment at CERN achieved an impressive raw data recording rate, averaging ~120 MB/s, with peaks during stable beam conditions. The reconstruction process saw significant improvements, notably a reduction in track chi2 and higher efficiency in Kshort detection, despite challenges such as increased job failure rates and higher memory consumption. Optimization efforts are ongoing to enhance CPU efficiency and streamline workflows. Plans are in place to reprocess the complete 2012 dataset by year's end, including improved protections and data management strategies.

hei
Download Presentation

LHCb computing highlights

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LHCb computing highlights Marco Cattaneo CERN – LHCb

  2. Data taking • Raw data recording: • ~120 MB/s sustained average rate • ~300 MB/s recording rate during stable beam • ~4.5kHz, ~70kB/event • ~1 TB per pb-1 • ~ 1.5 PB for one copy of 2012 raw data • ~ 25% more than start of year estimate

  3. Reconstruction • Much improved track quality in 2012 • Factor 2 reduction in track chi2 • Higher efficiency for Kshort • Started with unchanged track selection • Effectively looser cuts on clone+ghost rejection • Higher multiplicity due to physics (4 TeV, higher pileup) • Factor two longer reconstruction time • High job failure rate dueto hitting end of queues • Temporary extension ofqueue limits requested andgranted by sites • Fixed by retuning cuts • New Reco version lateApril for new data • Reprocessed April data • Still tails ~1.5 times slower than in 2011 • More improvements expected by end June

  4. Prompt reconstruction • Follows data taking with ~5 days delay

  5. Stripping • Similar problems to reconstruction for early data • Only worse, x10 slower than required, due to combinatorics • Improved protections, retuned cuts to follow tracking improvements • Timing now ~OK • Output rates as expected • Memory consumption still an issue • Due to complexity of jobs: • ~900 independent stripping lines • ~1 MB/line • ~15 separate output streams • ~100 MB/stream • Plus “Gaudi” overhead • Total ~3.2 GB, can exceed 3.8 GB on very large events • Optimisation ongoing

  6. CPU efficiency

  7. Tier1 CPU usage • Prompt production using ~60% of Tier1 resources • Little room for reprocessing in parallel with data taking • Much greater reliance on Tier2 than in 2011

  8. MC production • Production ongoing since December 2011 for 2011 data analysis • ~1 billion eventsproduced • ~ 525 differentevent types • Started to producepreliminary samplesfor analysis with early 2012 data • MC filtering in final commissioning phase • Keep only events selected by trigger and stripping lines • Production specific for each analysis • Better usage of disk, but may put strain on CPU resources ~ 500 events/job 2012 samples

  9. Plans • As in 2011, we plan to reprocess the complete 2012 dataset before the end of the year • (obviously does not apply for any data taken in December) • ~3 months starting late September • Need ~twice CPU power than prompt processing • Make heavy use Tier2 • Software frozen end June, commissioned during summer • Further optimisation of storage • Review of SDST format (reconstruction output, single copy, input to stripping) to simplify workflows and minimize tape operations during reprocessing • Include copy of RAW on SDST • Avoids need to re-access RAW tapes when stripping • Effectively adds one RAW copy to tape storage…. • Collection of dataset popularity data to be used as input to data placement decisions • Deployment of stripping also for MC data

More Related