The MINOS Rootbased Framework

1
The MINOS Root-based Framework

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

2
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

3
Evaluation/Transition

• circa Nov'97 we had a FORTRAN (f77) based
  framework using ADAMO
• started to evaluate alternatives
  f77ADAMOCERNLIB 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

4
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 -gt 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

5
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

6
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
  BadThing
• Two (three) 'similar' detectors
• desire to generalize where possible
• group code by function not Near vs. Far (except
  CalDet)

7
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

8
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

9
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_publ
  ic_context/WebDocs/Companion/overview/Configuring_
  Jobs.html

10
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

11
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

12
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

13
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' 11 off the geometry
• FLUKA is on its way
• provides
• visualization, overlap checking
• same geometry in MC and reconstruction

14
Miscellanea

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