AFT in LCG Era

1
AFTin LCG Era

• Vincenzo Innocente
• CERN/EP

2
CCS Physics Applications in CMS

• Everything physicists directly see
• COBRA
• IGUANA
• DDD
• OSCAR
• FAMOS
• XDAQ
• SCRAM

3
Architecture Overview
Coherent set of basic tools and mechanisms
Consistent User Interface
4
Framework(s)

• Why two frameworks (COBRA and IGUANA)?
• Integration of the 2 reptiles has been postponed
• Avoid impact on DAQ-TDR
• For instance Current Iguana plug-in mechanism
  requires changes in SCRAM
• No agreement in November on Analysis environment
• Wait for new persistency framework and LCG
  software
• Integration is planned for next major release
• This will include also the transition to LCG
  software

5
Which future for CMS Framework(s)

• COBRA implementation, design and foundations hit
  by
• Objectivity fate in HEP
• GRID claims for responsibility
• Unclear future in CMS of Python, Lizard, SWIG
• Obsolescence of many basic components
• Many issues reopened
• Loose or tight integration with LCG persistency
• Sharing of responsibility with GRID
• MetaData how, where, who
• Which UI, which GUI
• Scripting yes, no, at which level
• C interpreter OR compiled and
  dynamically-loaded code
• Integration with build system and running
  environment

6
Detector Description

• DDD is ready to mark a major milestone with a
  full round-trip within Geant4
• Full persistency mechanism for G4 geometry
• Soon integration test with ORCA to replace G3
  geometry model
• CMS Prototype essentially finished
• Not CMS specific
• Supports several geometry models
• Not bound to XML
• Rely on external geometry modellers (currently G3
  or G4)
• RTAG and then common product!

7
Simulation

• Simulation infrastructures not (yet?) a real CCS
  task
• OSCAR priorities have privileged G4 validation to
  framework integration
• Line of though in CMS that simulation does not
  require a common framework with reconstruction
  (G4 API and UI suffice)
• Direct consequences
• Simulation use-cases relevant for COBRA not
  exercised yet
• CMS does not have a validated architecture for
  simulation software
• A clear CMS position is now required at least in
  the context of LCG.

8
CCS role in LCG era

• Basic Software components will be provided by LCG
  as
• Supported External software (mainly public
  domain)
• In house developed components
• Part of a larger effort (HEP or wider)
• Specific to LHC
• The main role of CMS CCS
• Directly contribute to LCG projects
• Develop specific CMS software to integrate,
  interface, extend the components provided by LCG
• Two lines of though
• Provide a coherent and consistent framework
• Expose native API and UI even if conflicting

9
Simulation, Reconstruction Analysis Software
System
Physics modules
Specific Framework
Reconstruction Algorithms
Data Monitoring
Event Filter
Physics Analysis
Generic Application Framework
Calibration Objects
Event Objects
Configuration Objects
adapters and extensions
Basic Services
C standard library Extension toolkit
ODBMS
Geant3/4
CLHEP
Paw Replacement
10
Software Baseline

• CMS plan is to baseline CCS software end 2003
• Before choosing among components we have to
  choose an Architecture
• What to expose to physicists
• How we build and run software application
• How physics modules communicate with each other
• How we use external software
• If we use a unique approach to all this
• What use we make of external software and how we
  collaborate with(in) LCG will much depend on
  these choices