Control Actions for the Atlas Software Framework

1
Control Actionsfor the Atlas Software Framework
Paolo Calafiura, LBL

• ACAT 2000
• Fermi Lab, October 19 2000

2
The Atlas Software Architecture

• Overall design principles specified Dec 99 by the
  Architecture Task Force
• data and algorithm object separation
• proxy data access using a Transient Data Store
• no direct module-to-module communication
• traditional control flow
• technology-independent database access layer
• Athena Framework prototype implementation
• based on the existing Gaudi architecture effort
  (initiated by LHCb)

3
Control Framework

• The control framework is the part of an
  infrastructure that makes sure that
• The right piece of software
• Runs
• At the right time
• With the right inputs and
• The outputs go to the right place
• (Lassi Tuura)

4
GAUDI Architecture
Converter
Converter
Application Manager
Converter
Transient Event Store
Data Files
Persistency Service
Message Service
Event Data Service
JobOptions Service
Algorithm
Algorithm
Algorithm
Data Files
Transient Detector Store
Persistency Service
Particle Prop. Service
Detec. Data Service
Other Services
Data Files
Transient Histogram Store
Persistency Service
Histogram Service
5
Definitions

• Algorithm (Module)
• Atomic unit (visible controlled by framework)
  of calculation and/or processing.
• ApplicationMgr
• creates and initializes Services and Algos.
  Drives the Algorithms processing
• Data Object (Collection)
• Atomic unit (visible managed by transient data
  store) of data. NOT necessarily a dumb data
  object.
• Transient Event (Data) Store
• Central service and repository for data objects.
  Provides data location, data object life cycle
  management, transparent smart pointer/data
  converter interaction.
• Also Transient Histogram Detector Stores
• Data Converter
• Provides explicit (some implicit soon) conversion
  from arbitrary persistent data format (ie.
  ZEBRA, Objectivity, etc.) to transient data
  object.
• Services
• Globally available software components providing
  framework functionality.
• Properties
• Control and data parameters for Algorithms and
  Services.
• Job Options File
• Text file defining configuration and
  properties. (from Craig Tulls Gaudi
  Tutorial Introduction)

6
(No Transcript)
7
The Application Manager

• Input

AppMgr
HitFinder
Tracker

• Algorithms

• Action Methods

Initialize
Execute
Finalize
Initialize
Execute
Finalize
8
Whats missing?

• For most use cases, nothing really...
• Use cases not easily covered by this approach
• Event filtering I/O modules must handle disk
  file open/close actions
• Calibration must handle stepping of input signal
• Simulation pile-up of events coming from
  multiple streams
• Dont want to require each algorithm to handle a
  file opened action
• Too much coupling among Algos and the
  ApplicationMgr
• each and every algo must implement exacty three
  handlersinitialize, execute and finalize

9
What else do we need?

• Support multiple event sources (e.g. for pile-up
  studies)
• Notify modules only about the actions they may be
  interested into
• Notification must be type-safe only modules
  implementing the right action handler interface
  can be notified.
• Control the order in which the modules handle
  actions
• Define the actions, the order of modules and the
  action sources, dynamically via the User
  Interface
• No physical coupling between ApplicationMgr and
  modules
• actions can be added or removed without
  triggering massive recompilations

10
The Control actions Framework

• Sources

Finalize
FileClose
NewRecord

• Actions

HitFinder
Tracker

• Modules

• Handler Methods

11
The Core Entities

• Action Source
• drive the framework generating actions
• Action (and Concrete actions)
• observe sources for matching actions, run module
  methods
• Modules
• handle actions, adding matching handlers method
  to their queues

12
Scenario Running a Action

• The source notifies all registered actions that
  he has a newRecord action ActionSourcenotify
  DEBUG notifying newRecord
• newRecord object catches the message and notifies
  its observers, the modulesActionupdate DEBUG
  newRecordinstanceof NewRecordAction got message
  newRecord
• Each module add the matching handler to the
  newRecord queue
• Now newRecord runs the scheduled handler
  methodsActionrun DEBUG newRecordinstanceof
  NewRecordAction startsHitfindernewRecord
  DEBUG runningActionrun WARNING
  newRecordinstanceofHitFinder__newRecord was
  not ready and had to be rescheduledHistogrammer
  newRecord DEBUG runningHitfindernewRecord
  DEBUG running

13
Implementation

• As usual we added a level of indirection
  (actually two)
• each source is an Observable generating actions
• each action is a typed Observable that notifies
  its registered modules when it observes the
  corresponding action
• In a sense each action is a separate control
  framework
• A Module implements a separate interface for each
  action he can handleclass Algorithm
  virtual public TActionHandlerltInitgt,
  virtual public TActionHandlerltnewRecordgt,
  virtual public TActionHandlerltFinalizegt .
• It looks very much like the Typed
  Message/MultiCast pattern (J. Vlissides, Pattern
  Hatching, great book)

14
Where do we stand?

• We have a web page http//electra.lbl.gov/ATLAS/f
  ramework/controlstates/actiondesign.html
• We have a prototype
• Integrated in Atlas SRT
• can get a stand alone version from URL above
• Integration with the ApplicationMgr (being
  rewritten) in progress
• Use it to explore interactions with other new
  domains
• Scripting/User Interface
• Event Data Model (next talk, VLSC305)

15
Thanks to

• So many people that Ill sure forget some
• Vincenzo Innocente
• Jim Kowalkowski
• Charles Leggett
• Pere Mato
• John Milford
• Dave Quarrie
• Marjorie Shapiro
• Lassi Tuura
• Craig Tull
• Laurent Vacavant

16
Lassis Object Networks

• Colors data types
• Modules behavior
• Whole network component
• Input-output dependency

17
(No Transcript)
18
The Module class

• Define a Module class that provides access to the
  core servicesclass Module virtual
  public IModule, virtual public IProperty,
  virtual public TEventHandlerltSysInitializegt
  public IMessageSvc msgSvc()
  templatelt class Tgt StatusCode service(const
  stdstring name, T svc)

19
Setting up - a sample script

• associate Actions and ActionSources
  ActionSource rawFile(inputFile)
  next_Record.attach(rawFile)
• define Sequences of components to be executed
  sequence all "hitFinder",
  "tracker", "myanal" sequence reco
  "tracker", "myanal"
• define Action handlers, with usual flow-control
  constructs next_run.run("all") while
  (next_Record.run("all"))
  fill_histos.run("reco")
  fill_Bhistos.run("paolo")

20
Running

• The framework runs Actions following the script
  order.
• Control returns to the framework after each
  action completes
• The Action tries to run each registered module in
  order
• The module determines the status of its
  associated method, run it if ready, and report to
  the Action.
• The Object Network (or a Data Manager) notifies
  modules when their Parameters are ready or
  change.
• The Action may re-queue a module which is
  NotReady.

21
Scenario Running a Action
22
Scenario Setting Up

• First we define the action classes
  DEFINE_CTRL_STATE(NewJobActionS)DEFINE_CTRL_STAT
  E(NewRunAction)DEFINE_CTRL_STATE(NewRecordAction)
  
• Then we create the module managersHitFinderMgr
  hitFinderHistogrammerMgr myHistos
• We create the actions instances and we register
  the module with them. NewJobAction
  newJob("newJob") newJob.addIObserver(myHis
  tos) newJob.addIObserver(hitFinder)
• Finally we create the action source and register
  the actions with it.ActionSource
  testSource("testSource")testSource.addIObserver(
  newJob)testSource.addIObserver(newRun)testSo
  urce.addIObserver(newRecord)

23
(No Transcript)