LHCb computing highlights

Marco CattaneoCERN – LHCb

2

Data takingm Raw data recording:

o ~120 MB/s sustained average rateo ~300 MB/s recording rate during stable beam

P ~4.5kHz, ~70kB/evento ~1 TB per pb-1

P ~ 1.5 PB for one copy of 2012 raw datad ~ 25% more than start of year estimate

3

Reconstructionm Much improved track quality in 2012

o Factor 2 reduction in track chi2o Higher efficiency for Kshort

m Started with unchanged track selectiono Effectively looser cuts on clone+ghost rejectiono Higher multiplicity due to physics (4 TeV, higher

pileup)m Factor two longer reconstruction time

o High job failure rate dueto hitting end of queues

o Temporary extension ofqueue limits requested andgranted by sites

m Fixed by retuning cutso New Reco version late

April for new dataP Reprocessed April data

o Still tails ~1.5 times slower than in 2011P More improvements expected by end June

4

m Follows data taking with ~5 days delay

Prompt reconstruction

5

Stripping

m Similar problems to reconstruction for early datao Only worse, x10 slower than required, due to

combinatoricsm Improved protections, retuned cuts to follow

tracking improvementso Timing now ~OKo Output rates as expected

m Memory consumption still an issueo Due to complexity of jobs:

P ~900 independent stripping linesd ~1 MB/line

P ~15 separate output streamsd ~100 MB/stream

P Plus “Gaudi” overheadP Total ~3.2 GB, can exceed 3.8 GB on very large events

o Optimisation ongoing

6

CPU efficiency

7

Tier1 CPU usage

m Prompt production using ~60% of Tier1 resources

m Little room for reprocessing in parallel with data taking o Much greater reliance on Tier2 than in 2011

MC production

m Production ongoing since December 2011 for 2011 data analysiso ~1 billion events

producedo ~ 525 different

event types

m Started to producepreliminary samplesfor analysis with early 2012 data

m MC filtering in final commissioning phaseo Keep only events selected by trigger and stripping

lineso Production specific for each analysiso Better usage of disk, but may put strain on CPU

resources8

~ 500 events/job

2012 samples

9

Plans

m As in 2011, we plan to reprocess the complete 2012 dataset before the end of the yearo (obviously does not apply for any data taken in

December)o ~3 months starting late September

P Need ~twice CPU power than prompt processingP Make heavy use Tier2

o Software frozen end June, commissioned during summer

m Further optimisation of storageo Review of SDST format (reconstruction output, single

copy, input to stripping) to simplify workflows and minimize tape operations during reprocessingP Include copy of RAW on SDST

d Avoids need to re-access RAW tapes when strippingd Effectively adds one RAW copy to tape storage….

o Collection of dataset popularity data to be used as input to data placement decisions

o Deployment of stripping also for MC data