Alignment in real-time in current detector and upgrade 6th LHCb Computing Workshop 18 November 2015 Beat Jost / Cern

Beat Jost, Cern Preamble ❏ I kept the title that was in the agenda, HOWEVER ➢ The alignment procedure described is NOT Real-Time, but rather (bicycle) Online ➢ I reckon, in the future, this will not drastically change 2 6th LHCb Computing Workshop, 18 November 2015

Beat Jost, Cern General Idea 3 6th LHCb Computing Workshop, 18 November 2015 ❏ Use the HLT farm nodes to process (selected) event data (Analysers): ~1800 copies ❏ The results of the event analysis are collected by an Iterator (singleton) that will provide the next set of parameters the analysers will use to redo the event processing ❏ Once the iteration process has converged (or failed) the Alignment process is finished and the final parameter set is stored for future use ❏ The entire process is driven and steered by the run controller via the FSM machinery

Beat Jost, Cern Pictorially 4 6th LHCb Computing Workshop, 18 November 2015 Iterator (Central Node) Analyzer (Farm Node) Analyzer (Farm Node) Alignment Constants Analysis Results … Alignment Constants ~1800 Copies Event Data

Beat Jost, Cern Task Finite State Machine ❏ Standard Online Task FSM ❏ Each task in the system runs this FSM ❏ The sequencing of the different tasks is performed by the run controller and its internal rules 5 6th LHCb Computing Workshop, 18 November 2015 Offline Ready RunningPaused configure (initialize) start pause continue stop reset(finalize)

Beat Jost, Cern Global FSM and sequencing 6 6th LHCb Computing Workshop, 18 November 2015 ❏ The Analyzers issue the pause transition when they have finished the processing of the events (EoF). ❏ The run controller only send the stop command to the Analysers when ALL are paused. During this transition the Analysers ‘publish’ the results of the analysis. ❏ When all Analysers are in the ready state the run controller sends the pause command to the Iterator, which collects the results of the Analysers, calculates the next set of parameters and issues the continue command to the run controller. ❏ The run controller will issue the start command to the Analysers, which will read the new parameters and analyse the data again ❏ And so on… Slave initiated

Beat Jost, Cern Framework Components ❏ The Tasks (Iterator and Analyser) are each composed of two components ➢ A framework service that ensures proper interaction with the run controller ➢ A user component (AlgTool) that implements the real work of the alignment process ❏ Iterator: ➢ Framework Code: AlignDrv, implementing IAlignDrv + OnlineService ➢ User Code: implementing IAlignIterator interaface (basically one routine) and calling the methods of IAlignDrv + doing the real work ❏ Analyser: ➢ If a “standard” event processing (e.g. Brunel-like) application is run, there is no additional coding need, besides the reading of the parameter set in the start transition. The pause transition is called by the online file selector automatically at EoF. 7 6th LHCb Computing Workshop, 18 November 2015

Beat Jost, Cern Status ❏ The alignment procedures are all implemented ➢ VeLo, Tracker and Muon alignment are executed automatically at each fill (when sufficient statistics is available) ➥ Velo within a few minutes after closing –Triggers a run change if deviations are sufficiently big. ➥ Tracker takes a bit longer to accumulate the necessary statistics ➥ Muon takes very long (several fills) to accumulate the necessary statistics ➢ Calo (  0 )calibration is run manually very rarely (few times/year) ➢ RICH mirror alignment run ‘manually’ when needed ❏ Bandwidth-Division also uses the same framework ➢ Run when no other activities are executed ➥ Takes a lot of CPU power ➥ Spawns 20+ tasks… 8 6th LHCb Computing Workshop, 18 November 2015

Beat Jost, Cern Alignment in the upgrade ❏ Assuming the farm nodes still have local disks (very likely, as we prob. still have a split-HLT) ➢ There is not really a reason to deviate from the current scheme ➢ Unless… Requirements (e.g. frequency of alignment) change drastically… ❏ A (somewhat provocative) alternative scheme: Continuous, distributed alignment and calibration ➢ just a fresh idea, surely not yet completely fermented… 9 6th LHCb Computing Workshop, 18 November 2015

Beat Jost, Cern Continuous, distributed alignment and calibration ❏ Basic idea ➢ Each HLT1 trigger task aligns/calibrates continuously while it is processing the event data ➥ No central entity (Iterator) that has to collect the results of the event processing (embedded in the HLT(1) process) ➢ Pros: ➥ No central Iterator ➥ No out-of-process information transfer (xml files) ➥ Re-use information/computational results already present (reconstruction already partially performed during HLT processing) ➥ Not relying in local disk ➥ Seamless update of alignment constants ➢ Cons: ➥ Possible slow-down of HLT processing –Prob. marginal (depending on implementation) ➥ Each process has its own alignment constants –Should be the same (statistically) as events are independent ➥ Need to devise a system to convey the actual alignment used to offline software (just in case…) 10 6th LHCb Computing Workshop, 18 November 2015