Core Applications Software

1
Core Applications Software

• Lucas Taylor
• Northeastern University

2
US-CMS Core Applications Software

• 2 sub-projects of US-CMS SoftwareComputing
  Project
• User Facilities (focussed on Tier 1 and Tier 2
  centres)
• Core Applications Software (the subject of this
  talk)
• Two main tasks for Core Applications Software
• US contributions to CMS Core Software
• US responsibility for delivering a canonical
  fraction (25)
• Software support specifically for US-CMS
  physicists
• To enable them to meet their detector commitments
• To enable them to fully exploit LHC physics
• To enable them to do the above from their home
  institutes

3
Core Software Scope

• Architecture of CMS software
• Software process and development environment
• Software framework, persistency services,
  utilities,
• Tools for distributed data access / processing
• Analysis environment and toolkits
• etc
• requires professional software engineering
  expertise
• In other words, all that is required to support
  the closely related (mostly PRS) activities of
• event generation, detector and trigger
  simulation, reconstruction, data selection
  (online offline), physics analysis, test-beams,
  etc.
• ...requires professional physicist expertise

4
Core Software Planning
CMS Coordinator L. Taylor, Northeastern
CMS Coordinator D. Stickland, Princeton

• Three closely-related CMS projects with large
  software components
• Core Software and Computing
• Physics Reconstruction and Selection (PRS)
• TriDAS
• Adjustments to CMS organizational entities
  plans are being refined
• Software engineering resource needs will not
  change dramatically
• N.B. this is an evolution not a revolution !

MONARC Spokesperson H. Newman, Caltech
5
Core Software Milestones
Functional prototype phase is now complete
May 2000 L2/L3 ?10 reduction
Nov 2000 L2/L3 ?100 reduction
Dec 2000 Trigger TDR
May 2001 TriDAS discovery at 100Hz
End 2001 DAQ TDR
End 2002 Software Computing TDR
5 Mock Data Challenge
6
Aside remark on the LHC schedule

• Current status (L.Maiani , RRB, 23 Oct 2000)
• So far there is no change in the machines
  critical path
• 5-6 months delay in ATLAS/CMS caverns
• Expect 2 weeks running in 2005 full running
  from April 2006
• What are the implications for the CAS project?
• (Most of) CMS detector to be installed as
  originally planned
• Still need functioning (if partial) TriDAS and
  offline in 2005
• Significant software work to be done before 2005
  related to detector / TriDAS / physics
  optimization
• No software delays possible if no detector/TriDAS
  delays
• Some savings possible for (UF) hardware purchases
• No significant savings for Software are
  anticipated... ...although more detailed
  consideration is required

7
Functional Prototype Deliverables

• Documented requirements
• Set of Software Prototypes, Packages,
  Documentation
• Software Infrastructure
• repository, multi-platform build, release,
  distribution, and documentation systems.
• Proposal for a Baseline set of Technologies
• Proposed Project Evolution Plan

8
Where we go following the Functional Prototype

• The Software is now moving into pre-production
  phase (also known as Fully Functional Software)
• Evolutionary changes in CMS organisation three
  closely-interacting projects
• Core Software and Computing
• Physics Reconstruction and Selection
• TriDAS
• Increase formality for CMS planning
• Collection and refinement of use-cases and user
  requirements
• Systematic re-examination and documentation of
  architecture and framework (Café new project
  with strong US involvement)
• Re-alignment of schedule and milestones (with
  whole of CMS)
• Definition of work packages and deliverables

9
US-CMS Core Software Planning

• An interim team has been working on CAS planning
• 2. Core Applications Software
• L. Taylor (Acting L2 - temporary), I. Fisk
  (Acting Deputy L2)
• 2.1. Software Architecture
• D. Stickland, L. Tuura,...
• 2.2 Interactive Graphics and User Analysis
• I. Gaponenko, L. Taylor,...
• 2.3 Distributed Data Management and Processing
• J. Bunn, I. Fisk, T. Wildish, R. Wilkinson,...
• 2.4 Support
• I. Fisk
• Level 2 and Level 3 managers to be defined once
  our new L1 manager (Lothar Bauerdick) is fully on
  board

10
Creation of the CAS WBS

• Maintain the US-CMS WBS distinct from CMS WBS
• Clarity regarding US roles and responsibilities
• Inclusion of US-specific items (notably local
  support)
• Requires ongoing integration with International
  CMS planning
• Acknowledge that software is different to
  hardware
• no mass-production of many similar components
• software technologies continuously evolve
• continuous need for functioning systems from now
  to turn-on
• Adopt a rolling approach to software planning
• More detail (deliverables, milestones, etc.) in
  short-term
• Longer-term resources according to
  level-of-effort scaling
• Optimal use of resources in a changing
  environment

11
Granularity of the CAS WBS
Recall, e.g. L2 CAS L3 IGUANA L4
Interactive graphics L5 GUI Extensions L6
Tree widget

• t ? t1year (i.e. FY2001 for ttoday)
• Define US-CMS tasks to typically level 5 / 6
• Associate deliverables, milestones
• Assign resources to each task
• Ensure that, by definition, the rolled-up
  resources assigned in the US-CMS WBS are the sum
  of
• canonical 25 scaling of full CMS software
  project
• US-specific support for physicists 25 of US-CMS
  total
• Consult repeatedly with CMS
• t1year ? t2year (i.e. FY2002 for t today)
• As above but only define tasks to typically level
  4 / 5
• beyond t2years (i.e. FY2003,4,5,...for t
  today)
• As above but define tasks to level 3 (
  ongoing resolution)
• US-CMS responsibilities are essentially
  level-of-effort

12
Rolling the Planning Forward

• Dont panic
• there is always a complete plan
• we roll forward the level-of-detail and
  responsibilities
• the required resources are constrained by the CMS
  envelope
• Need to ensure consensus of US-CMS agencies.
  E.g.
• Minor changes (L5) quarterly review (ASCB /
  JOG)
• Major changes (L4) annual review (CB,
  DOE/NSF)
• Need to ensure consensus of CMS
• Increase formality of reporting to CMS project
• CMS Software Computing Technical Board (6 times
  / year)
• CMS Software Computing Board (4 times
  / year)
• Aside can we rationalise the timing of the
  various reviews ?
• FNAL Software and Computing Oversight group
  (twice / year ?)
• DOE/NSF Reviews (twice / year ?)
• CMS Software Computing Internal Review
  (annual)
• LHCC Review (annual)

13
US-CMS CAS Tasks Engineers Today

• Detailed description of WBS tasks
• Printed document, draft 1.3 WBS Dictionary
  for the Core Applications Sub-Project (WBS items
  2.1 - 2.4)
• Next talk by Ian Fisk

14
CAS Software Engineers Hiring Status
15
Software (and Computing) MoUs

• Discussions on Software MoUs in Hoffmann review
• Distinct from detector Maintenance Operations
  MoUs ?
• Opening discussion CERN RRB (23 Oct)
• Further discussions in RRBs of April 2001 / Oct
  2001 /
• Range of opinions on appropriate level of detail
  for commitments
• CMS tends to favour level-of-effort commitments
• rather than detailed deliverables which are hard
  to define for software and sustain into the
  future
• Appropriate time-scale for Software MoUs
• After detector MO MoUs gt Oct 2001 ?
• Before Software Computing TDRs lt Dec 2002 ?

16
Contingency

• CAS resources are dominated by personnel
• Variety of skills of software engineers (FTE is
  not well-defined)
• We need more tracking experience to understand
  how much effort various tasks really require
• Intrinsic uncertainty in overall CMS estimate
• tens of percent probably not a factor of two
• Market forces influence salaries (? Nasdaq !?)
• There may be unforeseen (US-)CMS crises needing
  injections of manpower, perhaps expert consulting
• Proposal for CAS personnel contingency
• add a fixed percentage to base cost as management
  reserve e.g.
• 10 for FY 2001 and 2002
• 25 for FY 2003 and beyond

17
Summary of CAS Resources

• Description of WBS tasks
• Printed draft 1.3 of WBS Dictionary for the Core
  Applications Sub-Project (WBS items 2.1 - 2.4)
• Next talk by Ian Fisk