Lead group | HLT |
---|---|
Participating groups | HLT, Computing |
Description | Implement a feature-complete scheduler with static resolution of dependencies, that keeps track of the decision flow |
Required FTE | 2.0 |
Available FTE | 2.0 |
Deadline | December 2018 |
Dependencies | Depends on all ongoing activities |
People currently involved | Niklas Nolte, Katya Gorkova |
New effort required? | |
Link to documentation | https://indico.cern.ch/event/663810/contributions/2979356/attachments/1638828/2615837/go![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Computing |
Description | Functional, mutlithreaded LoKi, filterdesktop, combineparticles. In HLT1 we can rely on tracks rather than particles, so need something that creates combinations of tracks (Sascha: This may exist already, eg the functors that create JPsis. We should review what is there). As a starting point we should review what functors are presently in use in HLT1/2. |
Required FTE | 2.0 |
Available FTE | 0.5 |
Deadline | December 2018 |
Dependencies | None at present |
Subtasks | HltUpgradeSelectionFramework |
People currently involved | Sascha, Vanya, Sebastian |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | Everyone |
Description | We need to define exactly what it is we benchmark at HLT1 and HLT2. Reliable determination of throughput and individual algorithm memory/cpu footprint is needed in as automatic a manner as possible. Implemented for Run 1 and partly implemented already for the tracking sequence, but needs to be expanded to all parts of the trigger as time progresses and level of granularity/frequency needs to be discussed. Rosen: Eg: Need something like a more sophisticated timing table |
Required FTE | 1.0 |
Available FTE | 0.5 |
Deadline | Continuous, with performance note to be defined Q2 2018 |
Dependencies | Depends on all ongoing activities |
People currently involved | Rob Currie (infrastructure), Renato Quagliani (as part of his work in the tracking) |
New effort required? | Need at least one more person |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Computing, Physics WGs |
Description | Define selection and bandwidth requirements for several key measurements from each WG |
Required FTE | 1.0 |
Available FTE | 0.5 |
Deadline | December 2018 |
Dependencies | Depends on all ongoing activities |
People currently involved | Mark Whitehead, Alex Pearce, HLT Liasons, several WG experts |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Physics |
Description | Topo-like selection for b-hadrons will need to go to turbo with as much event size reduction as is possible while still allowing physics |
Required FTE | 1.0 |
Available FTE | 0.5 |
Deadline | December 2018 |
Dependencies | Depends on all ongoing activities |
People currently involved | Alex Pearce, Greg Ciezarek |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Computing |
Description | The task is about persisting the information in the trigger to the raw event. Already now online and offline rely on almost the same tools and algorithms, with some differences due to a different file format. This should continue. An initial task would be to review what is currently saved and if there is duplicated or unnecessary information. It is also not yet clear if the current persistency can run in a multi threaded framework. |
Required FTE | 1.0 |
Available FTE | 0.0 |
Deadline | Dec 2019? |
Dependencies | Tightly linked to the event model. |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Computing |
Description | MC matching isn't really implemented in the current (Run 1/2) Moore and in Tesla it was implemented as an afterthought without being fully equivalent what is done in the Brunel and Stripping chain. A technical robust and reliable MC integration is necessary for the upgrade where more will be done in Moore than in later applications. |
Required FTE | 1.0 |
Available FTE | |
Deadline | |
Dependencies | |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT, ? |
---|---|
Participating groups | HLT, ? |
Description | With the added complexity at the level of the trigger, we need to ensure analysts have everything they need to perform their analyses, identify common use cases and develop tools and best practices for their use. Eg: supporting the TISTOS tool. What can we do to reduce reliance on tools that solve issues we can plan for, eg: can we run Moore on a recoed sample without rerunning that reco. |
Required FTE | 1.0 |
Available FTE | |
Deadline | Continuous |
Dependencies | Persistency and Event Model |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Online |
Description | Presently there are specific modes of operation that distinguish the use of applications between online and offline. Development and integration of the upgrade trigger into the online environment will need close collaboration between online and the HLT, with a view to making this as seamless as possible between the offline and online environments. Monitoring of the trigger, alignment and calibration tasks, etc, will also require development. |
Required FTE | 1.0 |
Available FTE | |
Deadline | |
Dependencies | |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Computing |
Description | We need robust and reliable procedures for development, code review, software testing and release management. This is already in-place in Run 2 but could do with being expanded for Run 3. |
Required FTE | 1.0 |
Available FTE | 0.2 (testing), 0.0 (software management within HLT) |
Deadline | Ongoing |
Dependencies | |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT, Tracking, PID |
Description | Details to be discussed between participating groups |
Required FTE | 1.0 |
Available FTE | |
Deadline | |
Dependencies | |
People currently involved | |
New effort required? | |
Link to documentation | https://www.overleaf.com/read/gqfwjfpyhssy![]() |
Lead group | HLT |
---|---|
Participating groups | HLT |
Description | e.g. VeloUTMuon matching for prompt or low pt muons |
Required FTE | 1.0 |
Available FTE | |
Deadline | |
Dependencies | |
People currently involved | |
New effort required? | |
Link to documentation | https://twiki.cern.ch/twiki/bin/viewauth/LHCbInternal/Upgrade_VeloUTMuonMatch, https://www.overleaf.com/read/gqfwjfpyhssy![]() |