Vertex Detector Status

1
Prospects for Integrating Veloroot into GAUDI
D. Steele - 24/11/1999
2
Veloroot Þ GAUDI

• What is Veloroot? (for those who dont know)
• Motivation
• What It Does
• What it Should Also Do
• How Does it Differ from Corresponding Sections of
  SICB?
• Integration into GAUDI
• Feasible?
• How OO and/or standard is ROOT VELOROOT?
• Manpower requirements?

3
Veloroot Þ GAUDI

• Motivation
• Needed to read/analyse test beam data
• Realised that F77 was becoming more and more
  unfeasible as a language C chosen
• LHC considered too immature at the time (1997)
• Vertex groups transition to OO is unavoidable
  and the testbeam environment could provide an
  excellent opportunity for the vertex group to get
  experience with proper C/OO programming.
• Personpower with OO experience in short supply,
  need as much off the shelf help as possible.
  ROOT chosen to fill this gap (based on CERNLIB).

4
Veloroot Þ GAUDI

• First Version
• Functional, but not flexible.
• A lot of throw away code generated
• A lot of code was FORTRAN in disguise, and, in
  any case was not very OO (no inheritance or
  containment, lots of globals, etc.)
• Too many God objects
• Test beam setups were hard coded switching
  setups was very complicated (i.e. almost
  impossible.)
• Reading raw data required a first pass at the
  data by a special program whose only job was to
  parse the FZ file and write out a second file
  after clusterisation.
• A lot of this code was a C Hello World
  programme and, so suffered from numerous bugs.
• To keep our sanity, a new version was proposed,
  designed, and written

5
What is Veloroot

• Veloroot, now in its second release, is
• a testbeam reconstruction and analysis package
  performing
• FZ (raw data from CASCADE) handling
• mapping between all the complicated regions,
  strips, FE chips, etc for the various testbeam
  setups
• pedestal subtraction and common-mode noise
  correction to produce hits
• clusterisation
• track-fitting
• detector alignment,
• user-based analysis and data visualisation
• ROOT based

6
What is Veloroot

• Veloroot, should also
• be able to read in our testbeam Monte-Carlo
  output (Géant 3 programme which outputs ROOT
  files) - (not very difficult, but not done)
• be able to store and read back all intermediate
  data (I.e. hits, clusters, tracks) - (rather
  involved, 50 done)
• have an integrated event display- (on the
  shopping list, i.e. not done)
• be able to take alternative implementations of
  hit producers, cluster makers, and track finders
  - (100 done, but not tested since we currently
  have no alternate implementations)

7
Algorithm Differences with SICB

• GAUDI has been aiming, primarily, to take
  SICBesque algorithms and re-write or wrap them so
  they work in the GAUDI setup.
• Q How should conflicts between the algorithms
  present in SICB and in VELOROOT be handled?
• A
• Since pedestal effects and common mode noise are
  not included in SICB, they are not an issue.
• The clusterisation algorithm is the same as the
  one in SICB the implementation differs somewhat,
  though. Integration of the two should not be
  difficult.

8
Algorithm Differences with SICB

• A (continued)
• SICB tracking is done together with the inner
  outer trackers as well as the vertex detector in
  a global Kalman filter fit. In veloroot, a
  least-squares fit is done for track-fitting
  certain details, like errors due to multiple
  scattering, are not included in the fit.
• One solution
• Use the new GAUDI tracking for most things, but
• use the veloroot-based tracking for things like
• level-1 trigger
• internal vertex detector alignment,
• tracks which are outside the acceptance of the
  inner/outer trackers, and
• vertex detector standalone studies

9
Blah, blah, blah...
So, what are the prospects?
10
Integration into GAUDI

• Feasibility How standard is ROOT?
• Most aspects of such an integration are quite
  feasible. Most of the functionality of veloroot
  could be added to GAUDI and a GAUDI task
  created to perform existing veloroot jobs.
• However, there are a few remaining potential
  hurdles
• reading the raw data files (FZ)
• (link to CERNLIB shared library issues? - could
  also convert the FZ files to another format, but
  that would be painful)
• how to interface this to the testbeam MC
  (Géant-3)
• (maybe convert this as well, to Géant-4, inside
  GAUDI?)
• what happens to all the detector layout and
  alignment files?
• (i.e. how do we avoid clogging up the database
  and the code repository, since these will change
  very often?)

11
Integration into GAUDI

• Feasibility
• Potential hurdles (continued)
• elimination of older C syntax
• ROOT does not support all of ISO C
• ROOT supports only an incomplete and non-standard
  version of STL based on an old HP implementation
• The structure/syntax of some veloroot code is
  unnecessilarily complicated since many of the
  features are missing in ROOT.
• Replacement of ROOT specific classes with more
  standard implementations (STL, internal GAUDI
  classes)

12
Integration into GAUDI

• Manpower
• Manpower in the vertex veloroot group is very
  scarce
• current code is not so small 35000 lines (.h,
  .cxx)
• only 1 person (C. Parkes) will still be around
  next year from the current veloroot software
  group (!!!)
• However, several people could conceivably be made
  available from member institutes (Liverpool,
  Lausanne). (Names left off to protect the
  innocent.)
• Timescale?
• Difficult to estimate, since no in-depth study
  has been done. Certainly, a few months, minumum.
• Part of the problem here is to define, precisely,
  the scope of such a project to establish a
  timetable.
• Vertex group meetings are planned to discuss this.

13
Blah, blah, blah...
Thats all for today!