future framework john baines for the future framework requirements group 1
TRANSCRIPT
1
Future Framework
John Baines for the Future Framework Requirements Group
2
Contents
• Introduction : why a new framework• FFReq report• Key concepts• Timescales• Recommendations & Observations• Next Steps• Prototypes/Demonstrators• The HLT use-case & Views Demonstrator• Summary
Note: More technical discussion in Core Software meeting on Thursday
3
Why do we need a new framework?• To exploit full potential of future computer hardware
– Transistor density continuing to rise:• Increase in cores, not clock speed • Per-core memory a limitation
– Rapid developments in co-processorsÞ Need to go parallel:
• Run algorithms in parallel• On different events• On different parts of same event
• Internal parallelisation• Out-sourcing to external accelerators
• Take the opportunity to improve structure & functionality– Support trigger functionality as integral part of framework– Improve configuration – transparent, easily understood, recordable, reproducible– Further Improve memory layout of EDM objects:
• benefit from SIMD & facilitate outsourcing to accelerators
– …
Year
Moore’s law
Clock Speed
4
Future Framework Requirements• Future Frameworks Requirements group
– Started work in March ’14– Regular open meetings=> Report in CDS for comments (5 Dec 2014)
ATL-COM-SOFT-2014-048• Gives overview of current system – offline
& trigger• Lists requirements for New Framework• Recommendations & Timescales• Observations
• Please read & comment in CDS– So far 3 comments
5
Some Key Concepts• Whiteboard:
– stores data objects and exchanges them between components
• View: – same interface as whiteboard. Contains
subset of data objects e.g. in RoI
• Algorithms: – explicitly declare their Data Dependencies– Receive context: either whole event or
view
• Scheduler:– Executes algorithms - in parallel where
possible (subject to constraints)– Also handles schedulable resources and
tasks: Incidents become tasks
• Tools: – Configurable component of algorithm -
private (no public tools)
• Services:– shared and global – must be aware of
context when called from algs and tools.
Retain core design principles of current framework
6
Timescales: driven by Run-3 readiness
2014
Q3 Q4
LS 1
New FrameworkDelivered and
production-ready
Basic tests running in
initial framework prototype
Run 3
Framework Requirements
Capture Complete
Decision on core technological solution
Design, Prototyping,
Initial Implementn
Continued Development
Refinement & further
development as needed
Complete migration
Validate &
CommissionMigration of a limited set
of algos.
Migration of extended set
of algos.
Bug fixes, further
refinement as needed
HLT software Commissioning
Complete
Migration of Algorithms and Tools
to new framework complete
Fram
ewor
kAl
gs &
To
ols
Framework running
limited set of algos.
7
Recommendations• ATLAS should evolve framework to support multi-threaded and multi-process
execution of events and algorithms in offline & trigger use cases– Retain core design principles of current framework, but extend to:
• better support concurrent execution• incorporate the HLT requirements
• Readiness for Run-3 => not so much time => need to quickly decide next steps • Development should include real algorithmic code from very early stage
Observations• Basing New Framework on evolution of Gaudi/Athena framework would be a good
choice• Continue to benefit from collaboration from LHCb and CERN SFT
• Development of New Framework requires significant effort from skilled developers• Will also need significant effort for algorithmic changes:
=> investment in training for existing & new developers
8
Next StepsUnder Discussion – to be finalised
• Produce Final version of FFReq document– Taking into account comments - please read & comment in CDS– Add appendix on Analysis use-case
• Small subgroup formed • Aim to produce appendix on ~short timescale
– Take into account comments from ATLAS management:• Clearer separation of requirements & design• Distinguish “must-have” and “would be nice” requirements• Add discussion of migration strategy for non-framework code – algorithms, tools...
– Review by small technical review team– Final sign-off from OAB
• Establish project to design & implement Future Framework – Prioritisation of work– Add effort estimates
=> Endorsement by EB
9
Prototypes/Demonstrators• Continue and expand current prototyping work• Focus on answering key design questions• Demonstrators:– G4 Simulation – CaloHive – Scheduled Incidents – Views – see next slides
10
Key HLT Concepts• Only 1 in 100 L1-accepts selected by HLT and recorded
to disk • Need to minimize resource cost to reach decision
Key design principles:• Incremental Reconstruction & Selection
Þ Provides Early Rejection• Reconstruction inside geometrical Regions (Regions of
Interest)• Independence of trigger chains: one trigger does not
influence another=> can add/remove/pre-scale chain without affecting other triggersÞ facilitates calculation of trigger efficiencies
• Ability to import offline tools into online environment
11
Views DemonstratorIn Run-1 & Run-2 the HLT use-case implemented via extensions to current framework:• HLT Steering:
• Schedules HLT algorithms • Provides them with a RoI context
• HLT Navigation:• Associates objects in a RoI
In New Framework:• Scheduler also supports HLT use case• Views provide RoI context
Views Demonstrator will:• Assess options for implementing views• Demonstrate that they meet HLT requirements• Demonstrate minimal impact to offline use-case• Address portability of offline tools to online environment with no/minimal
changes
HLT in Existing Framework
12
Summary• Finalise FFReq Report
– incorporate comments – Small sub-group established to add Appendix on Analysis Use Case– Review by small technical review team
=> Final sign-off from OAB• Next Steps:
– Establish project to Design and Implement Future Framework• Develop work-plan: Priorities, deliverables, milestones, effort
estimates
=>Endorsement by EB– Recruit effort and start design & prototyping work
• Happening now – a very good time to join effort!– Kick-off workshop planned for May
Note: More technical discussion in Core Software meeting on Thursday
Under Discussion.
Details to be finalised
13
CDS Comments• Anna:
– Request for small corrections and clarifications – addressed in new version • Markus:
– Clarify relation of New Framework to Gaudi– Mention EDM for raw and PrepRawData, Identifiers, Identifiable containers– Extrapolator tool – example of big complex shared tool– Need to allow deletion of objects from whiteboard to limit memory– Demonstrator needed for views – Framework must support internal parallelism within algorithms
• order in which the threads are submitted and processed known and deterministic– Clarify the roles of algorithm/tool interface and whiteboard in data exchange
• Interface specifies data, objects themselves on whiteboard – Persistency: needs to support current and future formats– Support for coprocessors:
• Framework needs hooks• Implementations for specific architectures should follow a cost/benefit analysis
– Clarification on configuration– Need for follow-up on Analysis
14