# Presentation: 380207

## The MINOS Root-based Framework

- Robert Hatcher
- Fermilab Computing Division
- BteV Offline Software Mini-Workshop 2004-06

## Quips and Disclaimers

- This is not an official MINOS talk
- informal and personal perspective
- The MINOS framework is a product of many individuals
- in no particular order:  Nick West (Oxford), George Irwin (Stanford), Mark Messier (Harvard, now IU), Pete Border (UMN), Brett Viren (BNL), Sue Kasahara (UMN), Liz Buckley-Geer (FNAL), Jon Urheim (UMN, now IU), Robert Hatcher (IU, Caltech, Stanford, now FNAL)
- It was developed with very little FNAL support
- Offline Software has never been a WBS item in the MINOS project
- seriously understaffed (and still is to a large degree)
- most also had serious other responsibilities to experiment or other projects
- primary developers were *not* at FNAL, most had little/no FNAL experience
- both inexperience and resistance to doing things the “FNAL way”

## Evaluation/Transition

- circa Nov'97 we had a FORTRAN (f77) based framework using ADAMO
- started to evaluate alternatives – f77+ADAMO+CERNLIB seemed dead end
- attempted to show serious proposals at June '98 Ely meeting
- at the time no clear choices anywhere –
-  C++ vs. Java; ROOT vs Objectivity; use of CLHEP, LHC++, OpenInventor, RogueWave, etc...
- knowledge from own experiences at BNL, Soudan2, SNO, CLEO, ...FNAL
- reviewed numerous frameworks: D0, CDF, Gaudi, CLEO, ATLAS, BaBar...
- many FNAL'ers told us that we should adopt D0 or CDF as our own
- MINOS is different in significant ways (fixed target, **two** detectors, not all tied to beam)
- hard to see how to adapt – both seemed very experiment-centric (& collider-entric)
- if two gorillas can't agree on “proper way” why should we take either as a good model
- significant parts of either were strongly disliked by key people in some respect

## Adopting Root as a framework

- At the time Root was fairly nascent
- as early adopters: visionaries or just plain nuts?
- I think time will show us to be lucky – closer to the first than the second
- support on many platforms (though MINOS currently doesn't support NT)
- Decision to *not* hold Root at arm's length – not restricted to I/O
- Root is not a complete framework but certainly more than a toolkit
- still evolving - has meant that some work flows MINOS -> Root
- good working relationship with Root development team
- Our first C++ framework was meant to be tossed ... like all good software development management books say one should
- alas, not enough manpower – left with evolution

## General Comments

- Important to adopt coding conventions early
- no one adheres to them in all ways – hard to enforce in a manpower limited group – but serves as a helpful guide to newcomers
- Lots of MINOS code is quite procedural
- we're physicists, not fanatics
- Decentralized 'core' group – many locations
- e-mail via listserver is a primary communications device for both developer discussions and user's questions (much like roottalk list)
- phone mtg every fortnight (keep minutes as a record!)
- concept of site librarians and mentors
- both for MINOS specific info and Root in general

## Package Organization

- MINOS has a very shallow but broad organization
- SoftRelTools as a build system
- many packages, few subdir's (mostly test/validation)
- Make heavy use of Root's ability to deal with dynamic library loading
- not yet using new ability to pre-map class to library connection in order to get automatic library loading (too new hasn't been integrated into build)
- does mean that:
- load order can be important
- circular dependencies between packages are a BadThingTM
- Two (three) 'similar' detectors
- desire to generalize where possible
- group code by function not Near vs. Far (except CalDet)

## Root for I/O: Data Files

- Root gives us I/O that provides:
- automatic streamer generation (very few hand written streamers)
- schema evolution
- networked file access: rootd, dCache, objects via specialized sockets
- persistable pointers and references (TRef)
- MINOS doesn't distinguish Persistent vs. Transient store
- Root is not keen on the idea ... and frankly we saw it as a bother
- We make some use of TFolder as a whiteboard
- probably do well to be more systematic about it
- Objects in TFiles undergo compression
- save ~50% in space

## Data Files

- MINOS Persistency uses TTrees of *Records*
- each is a *stream *that can be correlated with other streams by VldContext
- VldContext: detector, simflag (MC vs. Data), timestamp
- multiple records of same VldContext on different streams
- RawRecords hold RawDataBlock objects – internally each is simply a flat block of data, but object specialization encapsulates unpacking
- Candidate records hold reconstructed objects
- NtpRecords are fully split into individual data members
- root's ttree/ntuple drawing facilities make for easy access
- retains VldContext matching ability
- pushing TTree “friend” capabilities of Root – drive Root's design/evolution
- Config records involve 'lower bound' matching of VldContext
- Record base class has bifurcated
- poor support for templating in early root
- now how to transition while retaining ability to read old files

## JobControl

- loon executable is root + basic MINOS package libraries
- Job scripts are straightforward C++
- either interpreted by CINT or compiled with ACLiC
- load additional package libraries
- construct sequence of *modules *into a *path*
- configure the modules, algorithms, framework elements
- attach files (beyond cmd line), control message service verbosity
- run the path, report statistics
- JobControl itself is fairly independent of Root
- but scripting uses CINT and dictionaries make framework accessible
- TTask came after our Modules had been defined
- Special module provides hooks for calling CINT interpreted functions
- makes easy one off coding quick and easy
- _[http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Companion/overview/Configuring_Jobs.html](http://www-numi.fnal.gov/offline_software/srt_public_context/WebDocs/Companion/overview/Configuring_Jobs.html)_

## Candidates/Algorithms

- Algorithms create Candidates
- Algorithm is stateless; Candidate is essentially filled in by own ctor
- called by Modules or other Algorithms
- not the CLEO model of triggers where requesting X causes Y to run
- Candidates hold reconstructed information
- essentially data-only
- a candidate one writes out today should look the same when read in tomorrow, irrespective of the state of the code and/or the database
- user interacts with them via a Handle
- provides memory management / ownership
- limits ability to re-write: clone-to-own
- use of TRef's to provide linkage (as well as direct pointers) to other objects
- should have been templated from the start, but Root wasn't up to it
- now difficulties in making a transition
- user confusion, proliferation of classes, excess boilerplate code

## Database Interface

- DatabaseInterface package is top level user visible component;            it is layered on top of:
- RDBC – supposed to be JDBC-like interface
- on top of odbc++, unixODBC, + drivers (e.g. MyODBC)
- choices directly in Root: MySQL, Postgres; came later
- SQL does not stand for “Standard” Query Language
- Homegrown system for turning rows in the returned result set into objects and dealing with memory management issues
- Performance requirements aren't to demanding – detectors are stable
- but we do have multiple detectors and multiple subsystems
- FarDet has 185856 strip-ends
- Satellite 'site' databases – cascade through DB's
- ultimately FNAL Oracle warehouse is final/definitive source

## Event Display

- Official EvtDisplay framework is heavily Root based (of course), but
- developer disagreed with Root's signal/slot – use sigc++ instead
- had lots of difficulty with original layout issues
- much feedback w/ Root team (usually quite productive)
- MINOS code/suggestions incorporated into Root
- Root (is/was) developing new tools to make life simpler
- ntuples + Root's inherent abilities make it too easy
- rogue displays based off ntuple quantities
- ntuple data at this point is too flat – almost fortran-like

## Geometry

- Currently TNodes/TShapes
- though not (for the most part) directly seen by user
- MINOS contributed TXTRU shape
- Plan in short term to transition to TGeo classes
- In conjunction with TVirtualMC
- this immediately gets us GEANT3 using this geometry
- GEANT4 geometry is 'cloned' ~1:1 off the geometry
- FLUKA is on its way
- provides:
- visualization, overlap checking
- same geometry in MC and reconstruction

## Miscellanea

- Proof
- parallel processing – MINOS has not yet explored this to any extent
- Navigation / Lattice
- MessageService
- Dispatcher