LHCb computing highlights
description
Transcript of LHCb computing highlights
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