# Presentation: 005491

## Proposal for changes to CMS  Core Software

- CMS Framework Review Task Force

## Charge & Mandate (1)

- Issued by:
- 	- David Stickland CCS
- 	- Paris Sphicas     PRS
- We were asked to:
- List good concepts to be present in a framework and event model based on the Tevatron RunII experiences
- Review the current features of the CMS EDM
- Provide a list of "missing features" in the CMS environment

- Nov 2004

## Charge & Mandate (2)

- Establish a set of rules or guidelines for ORCA code developers (various physics packages) to determine the interaction between them and the framework
- Produce a list of changes that are needed. The list can include changes in concept and the design of the EDM
- Produce a possible work-plan along with an estimate of the resources required -- to implement the changes needed

- Nov 2004

## Participants:

- Vincenzo Innocente
- Bill Tanenbaum
- Liz Sexton-Kennedy
- Marc Paterno
- Jim Kowalkowski

- Walter Brown
- Lothar Bauerdick
- Peter Elmer
- Lassi Tuura
- Avi Yagil
- Ken Bloom

- Nov 2004

## Overview

**We did cover all points of the charge**
**Made a list of important features needed based on RunII, part of a draft document**
**Examined their presence in the CMS framework**
******Agreed on a list of missing features!**
**Produced a list of desirable changes to CMS framework**
**Will present a possible work plan to implement the above (IF decision to do so is reached, and the CMS collaboration decides to adopt it)**

- Nov 2004

**Notes:**
Depends who “we” is – it’s a long list of work to be done   – is there a long list of those who will do the work?

Lothar: Thinks we have a plan.

Does the plan involve putting some sort of name to the work?  Informally yes.

## Main issues

**Following are what we a-priori thought to be the ****biggest, stickiest, most contentious**** issues:**
- Event class, Modules, communication...
- Scheduling (Reco-on-Demand, HLT etc.)
- Data structure, usage patterns (ROOT, ORCA-Lite...)

- Nov 2004

## Event Data Model (EDM)

- There will be one (and only one) **Event** class
- Event represents a single crossing
**Modules’ (*****Reconstruction Algos’*****) Communication:**
**Modules **interact with each other only via the** Event **class
**Modules** *shall not* interact directly (call) other modules.
**Modules** are directly "configurable“
- internal details (algorithms) are configured by "percolating" **ParameterSets** to them, from the **Module** that contains them.
- no other method of obtaining configuration is allowed
- Event data objects should not depend upon the classes that create them.

- Nov 2004

**Notes:**
Vicky:  I recognize all this; it looks just like RunII.  Is there anything we noticed we did wrong?

It’s the principles of Run II.    If you don’t enforce the principles, then the practices diverge. At CDF, kept tight watch and they were adhered to.  At CMS, the people designing core servers were conscious of these but had no power to enforce them.  When we’re rethinking all this stuff, it’s crucial that Dave S and Paris S take these and make them stick.

BobT:  So you see this group staying together?
Yes.

So that group listed will exist?  Yes, people contributing different percentages of their time.

Enforcement from that body?  No, it has to come from someone who is fulltime such as Vincenzo.  If it’s in the context of complete reengineering of software, and heads of experiment are behind them, then it’s better.

## Order of execution(who does what, when)

- Based on requirement of HLT configuration and performance:
- 		 Explicit, up-front scheduling of module execution (“path”)
- 		Be able to load all required libs, before first event is processed
- Implicit invocation (reco-on-demand) has merits in use-cases (visualization, interactive analysis)
- 		Can it be kept as well?
- 		How much does it cost to do so?

- Nov 2004

## Scheduling

- We had a long discussion of **scheduling mechanisms**
- Agreed on a system that allows for two:
- explicit scheduling
- implicit invocation (Reconstruction on Demand)
- In the context of explicit scheduling, the framework will prevent implicit invocation
- We have agreed to put off calculated scheduling; it may be re-considered at a later date.

- Nov 2004

**Notes:**
Calculated scheduling: what does that mean (Vicky)?
User doesn’t specify anything; just specify that object to be made. 

I want this track to be displayed = reconstructed.

Mesh things together and calculate even before first event. Information has been given to framework and it can calculate the scheduling.

You want to know inputs and outputs to module anyway....

## Event Format - Usage Patterns:

**“****Bare Root“.** The stored form of objects has to be sufficiently simple to allow their use without class libraries or additional code.
**ROOT with a small set of libraries.** This can use classes of type "basic elements". We want the classes of this second level to be defined by CMS. Analysis of data in this format shall not require access to external databases.
**ORCA-Lite**. Within ROOT *or * Framework with a medium set of libraries. This can use classes of type "1" and also of type "2". Analysis of data in this format shall not require access to external databases.
**Full ORCA**. Within the framework, using the full reconstruction  program. This includes not only the software libraries but also includes full connectivity to any external resources.

- Nov 2004

**Notes:**
Question from Vicky...

## What Does Use of Root Look Like?

- To figure out what the branch structure of the data should look like, we discussed what we want to use at the Root prompt (in case "1").
- Our example assumes a branch "ele" carrying electrons from one algorithm, and a branch "trk" carrying tracks from one algorithm.
- Our example is to plot the **pt** of the track associated with each electron in the electron collection:
- 		t->Draw("trk.pt[ele.tk.id]")
- Raw data is stored in a ROOT tree as well, but is not *required* to be transparent to **Bare ROOT**.

- Nov 2004

**Notes:**
What does simple mean?  Can’t have multiple inheritors?

Yes, C-structs, if ROOT were to fall off the planet, you could extract the cstruct and reconstruct.

## Requirements on ORCA

- Clear guidelines to Developers
- For proper interaction with the framework
- Will be specified and exemplified as a part of migration
- Object structure
- Persistent objects should be “simple”, to support the required four usage patterns
- No code should be needed to interpret such basic elements
- The representation in memory, and the persistent representation, should be the same (refit Vs. puff)
- ORCA-Lite
- Code reorganization  (de-spaghettization)
- Split into: Analysis and Reconstruction Tiers
- Data object definitions should be packaged separately from the Ana/Reco algorithms.

- Nov 2004

## Additional Issues

- Non-Event Data (was MetaData)
- (data sets)
- (conditions)
- Plug-in Manager
- Component Model

- Nov 2004

**Notes:**
They’re 2 different things.  Answer: For some people, it could include ...

## Non-Event Data: data sets

- Main Objective: dataset book-keeping
- Events are classified into O(50) Primary datasets.
- These are achieved via ~10 intermediate *online streams*.
- Classification into those, based on trigger decision
- This hierarchy is one of *event classification* --- different types of events, not different kinds of contents.
*data tiers*, which are defined by contents and levels of processing.
- MUST specify at job config stage if one wants AOD, RECO or RAW data

- Nov 2004

## Non-Event Data: data sets

- Dataset:
- 	 *collections of files*
- 	 *collections of events*.
- To define the event sample to be processed by a given job, need to specify:
- Event class/type: Primary DataSet (inclusive ele, di-jet...)
- Event representation (RECO, AOD...)
- Processing pass # (this year’s re-reconstruction)
- N.B. Skims, Tags, E.D. etc. may be identified as a different processing pass or with an additional DataSet attribute.
- Event & Run number ranges

- Nov 2004

## Non-Event Data: conditions

- Need to handle various “configuration” data:
- Algorithm configuration data (parameter set)
- Calibration data, “constants” database
- ...
- It is important to have full information for "officially produced" event data, while still supporting development by individuals doing something other than "official production."
- We identify two differently tracked information:
- Algorithm configuration data -- we've been calling these **ParameterSets**. They have a central authority to issue unique IDs.
- Calibration, survey, etc. data -- these have a different central authority to issue unique IDs. A single ID should suffice to specify all such data.

- Nov 2004

## Plug-in Manager & Dynamic Loading

- We propose that the SEAL  plug-in manager and scheme for dynamic loading should be adopted by CMS
- We think this assures us of all three required use cases:
- Never load anything during run-time
- Run-time loading of all required Libs before processing starts
- Loading on-demand
- No intent to support static build

- Nov 2004

**Notes:**
What does it mean in terms of packing up jobs and sending all over the grid?  It puts a lot more work on your sandbox.  Point to your shared libraries ...

We’ve successfully run CMS simulations on resources we didn’t control (Ian).

## Component ModelMulti Threading

- We propose that the SEAL component model should be adopted by CMS
- We propose that “services” (geometry service, calibration service, ...) should use this component model
- We propose strong limits on the use of multithreading
- Non framework code should not spawn threads
- Non framework code should not require explicit locking
- Simple rules (no use of class statics, etc.) should be enforced for user code, to allow for thread-safe use

- Nov 2004

## Deliverables – Notes (To be submitted by CMS week)

- Precursor note containing:
- RunII use cases
- Observations on availability in CMS
- List of suggested additions
- Start from internal document
-  Editor: VI
- “Problem Space” note
- May be introduction of the next
- Editor: Lothar & Avi
- Workshop Summary note:
- Structured skelton
- Incorporating detailed notes
-  Editor: Marc & Bill

- Nov 2004

**Notes:**
Long trail of details and design notes from the workshop. Will become the above documents.

## Slide 20

- Nov 2004

**Notes:**
T0 is whenever we get approval from the experiment. Maybe January.

Vicky:  What does the line represent?  What there is to do, or doing it?  The 1 month/1FTE .....Reason Marc doesn’t want to just use RSCP is it has...   re-implement in one month?    Vicky raises a big red flag on that.

Lothar: Not meant to solve all the deployment issues either.  

It’s the primer set system to be used by EDM. 

What else is it asking to do?  Parses.

This is just to get groundwork and be ready, not to be used for calculating FTEs.
During CMS week, present and find first victim.
Then how much work to turn into real production thing to use and support?  Didn’t discuss that, but we’re told we get 6 months before it has to come out in beta and replace existing software framework.  So for 6 months they’ll live w/ frozen infrastructure code while we do this.

T0 when?  January ish.... We have produced initial design to look at. Also outlying what it would look like, but no commitment or volunteering effort. If CMS agrees to this, we’re interested in doing it, depending on expertise available at the Lab.  We won’t do it without a clear mandate from CMS to do it, carry out, etc.  Wouldn’t even start until that’s reachable or reached.  Then, it would all be at FNAL and we’d have to get some help from elsewhere such as Philippe.  Vicky: That’s where a realistic estimate is essential.  Have talked about branch aliasing ... small project, 1 week.  

Vicky:  Some pieces I have no personal intuition, but those I do (and others) so we are asking but not being critical, so we need to know what we’re getting into.

We could take it as it is...  Marc objected about something Liz doesn’t totally understand.

Ian:  Marc claimed original RCP is something of a prorotype, so wants to work at it and get it right this time.  

Lee:  Had a DBC backend but it was never deployed...  Amber agrees about roadblocks.  Collaboration or resources? Nature of people developing things and control over process and choices that are made.  
Lee: Marc is worried about the database part. If we could combine it with the FronTier part, ... 
There’s a whole other aspect about data and all 3 have significant deployment issues.

The two weeks were very productive, and Vincenzo very receptive.  Management buyin from PRS side. We want to be cleancut about not pushing it down anyone’s throat, it’s well thought out. In the end are they going to enter into negotiations.  Vicky: They’d be crazy not to accept your offer, but wat if you get what you wish for...  Enough effort and strength to do this.  Everyone agrees this would put us in a unique position which emphasizes the need for a good process.Time scales are not negotiable; must be scoped to match them.

Vicky:  A very political but helpful thing may be BTeV. Liz: We’ve been thinking alon these lines.

Wrote document as best practices (Liz) therefore applicable to other experiments.