# Presentation: 634707

## STOREGTE  A Data Model Toolkit for the Atlas Software Architecture

- Paolo Calafiura, C. Leggett,
- H. Ma, D. Quarrie, S. Rajagopalan

## Event Data Model 

**Notes:**
Ask to your night shift colleague in the counting room (assuming you remember how a counting room looks like) to explain how Track reconstruction works and he may come up with a diagram like this: the event raw-data digits are read in and decoded, wire hits are reconstructed and fed into some tracking algorithm, which creates the event tracks ready to be analyzed
 Now show this diagram to a software architect and she will say: “Ah! A blackboard architecture: you must be dealing with some pattern recognition problem!”

## The Blackboard Pattern

- execute

- loop
- nextSource

- adapted from the ”Siemens” Patterns book

- operates on

**Notes:**
Your architect would then go to the blackboard and draw the following object diagram.

The blackboard is the central data store. It provides an interface to read and write to it. Elements of the solution (tracks) and intermediate results (hits) are posted on the store by the relevant  Knowledge sources (Tracking, Hit Reconstruction etc).

Knowledge sources are subsystems that solve  specific aspects of the problem. They are activated in turn by the Control Framework, they examine the contents of the data store(s) and determine if they can contribute to the solution.

The Control Framework runs a loop that monitors the changes to the blackboard and decides what action to take next. 

##  Data Store Pros and Cons

- Separates stable data from evolving algorithms
- Algorithms can be independently added, updated or removed from a running system
- Algorithms need to locate data in the store
- Control Framework must be configured correctly to reach the desired solution

**Notes:**
Separates stable data from evolving algorithms
 algorithmic code is known to be the least stable part of  “immature” software systems
 it also the most “proprietary” one: domain specialists tend to have exclusive control of this code, while data objects which appears on the store have often multiple clients and multiple providers

Algorithms need to locate data in the blackboard
  Once you separate the data from the algorithms producing them you need to identify each data object with a “well known name” that allows the producers and the consumers to locate it

Algorithms can be independently added, updated or removed from a running system
 this allows to explore in parallel the solution space in the (never-ending) development stages with minimal impact (at least until run-time) 

Control Framework must be configured correctly to reach the desired solution 
 if you remove the hit reco, the tracking and the analysis will still run ok technically speaking but won’t produce the desired results 

## What is StoreGate?

- A type-centric Data Store
- StoreGateSvc: Data Store client API (Gaudi service)
- Data Object virtual proxy with lazy instantiation
- A set of Data Object design tools
- Handle for “automatic update” of time-varying data
- Persistable inter-object references
*Polymorphic STL-like Collections** with defined element **ownership*
*Memory pool for optimized memory allocation*

**Notes:**
Type-centric here means type-safe (static checking) and that the data registry key contains the object type 

## StoreGateSvc: Type-centric Store

- All instances of
- a given type

- Virtual proxy

- All types
- in store

- Templated
- read/write

## Identifying Data Objects

- Data object type
- User defined key(well-known name)
- Default data object
- Use Data Object History (provenance)
- Reduce user-defined keys
- Not yet implemented

- Event
- Store

- “YourTracks”
- TrackCollection

- My
- Tracking

- Write
- “MyTracks”

- Read
- “MyTracks”

- Your
- Analysis

- Read
- “YourTracks”

- “MyTracks”
- TrackCollection

- provenance

## StoreGateSvc API

- To record (write) a data object
- StatusCode sc =
- 	p_sgSvc  record(pTrkColl,  TrkCollKey);
- To retrieve (read) a data object
-    p_sgSvc  retrieve(pTrkColl[,TrkCollKey]); p_sgSvc  retrieve(beginTC, endTC);
- where :
- pTrkColl is a (const) pointer to a TrackCollection
- TrkCollKey is an identifier for a data object.  It  can be a simple string like:  “MyTrackCollection”
- beginTC, endTC are iterators over all TrkColl instances in the store

**Notes:**
No detail just mention that All these methods are templated in TrackCollection.
Perhaps also the “retrieveAll”

## Control Object Access and Creation

- DataProxy
- Virtual Proxy that collaborates with Gaudi (one day, POOL) transient-persistent conversion mechanism
- In the future may use history info to reconstruct data object on-demand
- Lazy data object instantiation (on client access)
- Support/enforce const-correctness
- StoreGateSvc allows to “freeze” a data object ready to be used or written out

- creates

## DataHandle for Time-Varying Data

- Purpose:
- Hide store dynamics from client code
- Handle is bound to DataProxy during initialization
- Automatically updated (again using lazy instantiation) when Data Object enters a new validity range
- Use cases:
- alignment data
- calibration objects
- detector description information
- anything which has an associated validity range

## Asynchronous update of Calibration Data

**Alg**

**Handle**

**Storegate**

**Proxy**

**IOVSvc**

**CondDB**

**NovaCnv**

**PPSvc**

- regHandle(**handle,key**)

- 

- accessData()

**T***

**DataObj*******

- reset()

- callback(**dbKey**)

**T***

- 

- regFcn(**this,&Fcn,handle,key**)

- reset()

- initialize

- execute

- async

- bindHandle(**handle**)

**IOVDbSvc**

**IOV,string**

- getData(**key**)

**DataObj*******

**PersSvc**

- updateAddress(**TA**)

- updateAddress(**TA**)

- buildIOA(**string**)

**IOA**

- setRange(**clID,key,IOV**)

- createObj(**IOA**)

- setAddress(**IOA**)

**IOA**

**IOA**

- buildIOA(**string**)

- partial **IOA**

- regProxy(**proxy**)

- bind(**handle,key**)

**Notes:**
Shock and awe, don’t discuss

## Work with User Types

- What is a Data Object? An object recorded into StoreGate (SG)
- Only constraint is to be an “Assignable”
- No base class for SG data objects
- SG uses generic programming to work with user types adapting to the interface they provide (“export”)
- Same strategy used for SG collections and inter-object relationships

## Inter-Object Relationships

- Need Persistable Ptr that
- is technology-independent
- does not require Hit to derive from any base class
- supports deferred access, creating the pointed-at object upon dereferencing
- allows to point at
-  SG primary objects (Data Objects)
-  SG secondary objs (elements of a Data Object)

- registry

- unknown

**Notes:**
DataLink is not enough
Links to secondary objects
Most often relationship is to an element of a data object (which is usually a container) 
Locating one of these elements requires container-specific indexing info
ElementLink
Loosely speaking a DataLink to the container with a container-specific Indexing Policy allowing to locate the element
There are pre-defined Indexing Policies for all STL-like containers and a few Atlas containers 

## DataLink and ElementLink

- Policy-based design(parameterized inheritance)
- ElementLink is a composition of policies
- Default Indexing Policy generated according to host container type

**GenerateIndexing**
**Policy**

- Host

## The Need for Speed

- Atlas L2 and EF are using Athena & SG
- share Algorithms and Services with offline
- Performance Studies
- raw-data object access
- Speed-up > x10
- Optimized containers
- Key hashing
- A lot of work

**Notes:**
Yellow cleanup
Green IDC sequential
Black SG sequential
write 	~ s (1GHz)
read 	~ 20 s
optim read 	~500 ns

## Back to the Drawing Board

- Missed reqs and implementation surprises
- Writing concrete and reading abstract
- “Symlinks” (Concrete DObj)  (ABC)
- Proper solution when reflection available
- Templates and physical design
- Use PIMPL idiom to hide template implementation
- Keep libraries and executables small
- Templates and compilers
- Undetected compilation errors
- unit tests also improve compilation coverage
- Unreadable compiler msgs (100+ lines)
- boost concept-checking and compiler assertions

**Notes:**
This is the blackboard in Hong’s office @ BNL with the original SG API
Poor physical design came from heavily templated code
	coupling via “loaded” header files
	most implementation changes in SG required massive recompilations
Unreadable compiler error messages
	users of STL know what I am talking about
	still a nuisance
Undetected compilation errors
	template compilation is JIT, SG errors appeared later in the integration stage
	unit tests now exercise (and force compilation of) every single method
	occasional problems with the odd combination of arguments
Writing concrete and reading abstract
	the maker of say a cell collection knows which concrete collection it is making (say LArCellCollection)
	downstream analysis algorithms may want to work in terms of abstract CellCollection (say to combine results from multiple calorimeters)	 

## Status and Outlook

- SG blackboard is a mature product
- Used extensively by Atlas developers offline and online
- Performance and memory footprint meet requirements
- Data Object tools (links, containers, DataHandle) complete but newer: will need some fine tuning
- Need tools to exploit Athena History Objects
- to Identify Data Objects
- (perhaps) to steer Reconstruction-on-demand
- Integration with LCG
- New data link storage policy based on POOL Refs
- Use SEAL Dictionary for Inheritance info

## Slide 18

**Notes:**
Volume ON

## StoreGateSvc in Athena/Gaudi

- Converter

- Algorithm

- StoreGateSvc

- Persistency
- Service

- Data
- Files

- Algorithm

- StoreGateSvc

- Persistency
- Service

- Data
- Files

- Detector
- Store

- Message
- Service

- JobOptions
- Service

- Particle Prop.
- Service

- Other
- Services

- Histogram
- Service

- Application
- Manager

- Converter

- Converter

- Event
- LoopMgr

- Auditors

- Scripting
- Service

- Sequencer

**Notes:**
Athena-Gaudi Object Diagram
The main components of the architecture can be seen in the slide. 
The green boxes play the role of the Control component in the blackboard diagram
The Algorithms are the Knowledge sources
The StoreGateSvc provides an API to access Data Store (the blackboard)
The conversion mechanism (in blue) act as bridge between the framework and the specific technology of persistency mechanism.
Other algorithm services are in grey

## IOV Class Example

**class myIOVClass {**
**public:****   virtual StatusCode CallBackFcn(list<string> &dbKeys);****private:****   ****const**** DataHandle<CalAlign> m_align1;****   ****const**** DataHandle<CalAlign> m_align2;**
**      ****myIOVAlg2* that;**
**};**
**myIOVClass::initialize() {****  ****p_IOVSvc->regHandle(m_align1, dBkey1);****p_IOVSvc->regFcn(&myIOVClass::CallBackFcn, this, ****	****	****      m_align1, dBkey1);****p_IOVSvc->regFcn(&myIOVClass::CallBackFcn, this, **
**	****	****	****      ****m_align2, dBkey2);**
**   ****p_IOVSvc->regFcn(&myIOVClass::CallBackFcn, this,**
**                    ****&myIOVClass2::OtherCallBackFcn, that);**
**}**

**Notes:**
Note callbacks