# Muon Week 2016 : Offline Status and Plans ## Run2 and Run3 ### Laurent Aphecetche #### 27 May 2016
<!-- .slide: data-state="secondary-slide" --> # Run2 --- <!-- .slide: data-background-image="background-2.png" --> # Run2 developments See master JIRA ticket [ALIROOT-6564 : Muon 2016 reconstruction readiness](https://alice.its.cern.ch/jira/browse/ALIROOT-6564) - [ALIROOT-6562](https://alice.its.cern.ch/jira/browse/ALIROOT-6564) Add MCH LV values to OCDB - [ALIROOT-6563](https://alice.its.cern.ch/jira/browse/ALIROOT-6563) Add ClusteringAbort and TrackingAbort flags to the Muon ESD/AOD - [ALIROOT-6615](https://alice.its.cern.ch/jira/browse/ALIROOT-6615) Reset MUON/Calib/RejectList in RAW OCDB 2016 - [ALIROOT-6599](https://alice.its.cern.ch/jira/browse/ALIROOT-6599) Remove unused OCDB objects - not started (but clearly not critical, more a spring cleaning issue) - [ALIROOT-6561](https://alice.its.cern.ch/jira/browse/ALIROOT-6561) Flag the MUON/Calib/HV OCDB object as already patched for St12 - done - MTR efficiencies (to be able to get their effect in simulations) - Remove in-reco-QA --- # Add MCH LV values to OCDB <!-- .slide: data-background-image="background-2.png" --> The issue : - some LVPS were unstable end of 2015. LV trips could not be accounted for _automatically_ offline as the LV information is missing from OCDB The solution : - get low voltages stored in the OCDB, like the HV, so we can kill offline the detection elements that suffer from LV trips. The status : - setup of the transfert from DCS archive to OCDB (via Shuttle) was quite an epic story but finally succeeded this thursday... - next step (TBD) is to test the rejection based on LV trips on reconstruction. Fallback : - remove runs with LV trips from the good run list - that's the current situation actually --- <!-- .slide: data-background-image="background-2.png" --> # Add ClusteringAbort and TrackingAbort flags to the Muon ESD/AOD The issue : - for some events the clustering (or the tracking) is aborting for some reason (e.g. too many pads hit) - we don't flag those events so we don't easily get a handle on them The solution : - flag the aborted events at ESD/AOD level so they can be studied / rejected later on The status : - not started Fallback : - check with the reconstruction logs that the integrated fraction of affected events is small - close our eyes --- <!-- .slide: data-background-image="background-2.png" --> # Remove in-reco-qa The issue : - the QA-that-runs-within-AliReconstruction (not the one running on ESDs and giving us the runlists for analysis...) is no longer maintained The solution : - amputate the related parts of our code from the repo. The status : - Currently some DQM agents rely on some QA classes - So first the custom DQM agents for both MCH and MTR to be ready : - MCH is almost OK (though some testing still to be done) - MTR not quite ? Fallback : - continue as now to use non-maintained-and-poorly-written code --- <!-- .slide: data-background-image="background-2.png" --> # EVE updates As part of the EVE development for Run2 and Run3, Jeremi set up a table(["Run3 EVE readiness"](https://docs.google.com/spreadsheets/d/14ZOmIrxn5UPbdUMRKz9aU5KYfYQcQGUILUxNVYzxvQI/edit#gid=0)) to follow the progress. So far we are green. <img src="/talk/2016-05-27-run2-run3-muon-offline-for-muon-week-pornichet/eve-table.png" width="900px"/> --- <!-- .slide: data-state="secondary-slide" --> # Run3 --- <!-- .slide: data-background-image="background-3.png" --> # Reminder of the context In Run III, Alice will (mainly) becomes trigger-less and acquire MB Pb-Pb collisions at 50 kHz (instead of ~1 kHz currently). Input data to the readout will be huge (~3 TB/s), and has to be reduced, online, to a more manageable value of 90 GB/s to disk (and 20 GB/s to T0). This _data reduction_ is the top priority of the Run III reconstruction, Alice-wide. For the muon detectors specifically the numbers are (much) smaller : - input to read out ~ few GB/s - output of EPN ~ same order (unless we drop the pad information completely) So we can hope to actually perform _more than a mere data reduction_, i.e. do a _full reconstruction_ with _physics-grade quality_. That's what the MRRTF group is supposed to deliver at some point. --- <!-- .slide: data-background-image="background-3.png" --> # Muon Run3 Reconstruction Task Force a.k.a. MRRTF To tackle the issue, a "task force" was setup end of 2014... - Wrote a ["self-assigned" mandate](https://twiki.cern.ch/twiki/pub/ALICE/Run3MuonReconstructionTaskForce/mrtf.pdf) beginning of 2014 and started a [twiki](https://twiki.cern.ch/twiki/bin/view/ALICE/Run3MuonReconstructionTaskForce) - [Kickoff meeting](https://indico.cern.ch/event/342718/) in oct 2014 - Nothing happened then for about a year - Then tried to setup (bi) monthly meetings. - Made a [3 days hackathon](https://indico.cern.ch/event/503464/) in Subatech in march this year. --- <!-- .slide: data-background-image="background-3.png" --> <img src="snails.png" width="980px" /> --- <!-- .slide: data-background-image="background-3.png" --> # Moving the snail(s) Things are starting to move, but still quite slowly. Conclusion I : team was set up way too early Conclusion II : hard to get _available_ (wo)man power for the job (i.e. there's always more pressing issues than Run3 stuff) Conclusion III : there are lots of things to learn, so slow start might actually not be _too_ worrysome... --- <!-- .slide: data-background-image="background-3.png" --> # Reconstruction chain "big picture view" <img src="flowchart-cru-flp-epn-mch-mid.png" height="650px" /> --- <!-- .slide: data-background-image="background-3.png" --> # Reconstruction chain status... <img src="flowchart-cru-flp-epn-mch-mid-with-status.png" height="650px" /> --- <!-- .slide: data-background-image="background-3.png" --> # Achieved so far - [Play with AliceHLTWrapper](https://github.com/aphecetche/AliceO2/tree/muon-hltwrapper-basic-test/muon/hltwrapper) - [Toy device in Go](https://github.com/FairRootGroup/FairRoot/tree/dev/examples/advanced/GoTutorial) - Speedup of 100x for MCH preclustering stage - Ability to stage filtered raw data (on SAF), i.e. keep only muon information in raw data chunks. - not limited (nor driven by, originally...) to Run3, but quite usefull - e.g. two _full_ PbPb runs from 2011 are available on SAF --- <!-- .slide: data-background-image="background-3.png" --> # Some pointers... ... if you are interested, for your own personal use or because you want to join the game... - [TDR : Upgrade of the Online-Offline Computing System (O2)](https://cds.cern.ch/record/2011297) - [TDR : Upgrade of the ALICE Readout & Trigger System](http://cds.cern.ch/record/1603472) - [HLT Tutorial](https://indico.cern.ch/event/279723/) - [O2 Status and Plans (Dec. 2015)](https://indico.cern.ch/event/452733/session/4/contribution/23) - [ALFA Framework Status (Dec. 2015)](https://indico.cern.ch/event/452733/session/4/contribution/25) <!-- [Relative memory access speed](http://www.overbyte.com.au/misc/Lesson3/CacheFun.html) --> <!-- [Interactive latencies](http://www.eecs.berkeley.edu/~rcs/research/interactive_latency.html) --> --- <!-- .slide: data-state="secondary-slide" --> # Questions ? --- <!-- .slide: data-state="secondary-slide" --> # Backup --- # Playing with the MCH filtering stage <img src="digit-inspector.png" height="650px" />