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

Veloroot Þ GAUDI  What is Veloroot? (for those who don’t 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?

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 group’s 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).

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:

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

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)

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.

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

So, what are the prospects? Blah, blah, blah...

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?)

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)

Integration into GAUDI  Manpower Manpower in the vertex veloroot group is very scarce ; current code is not so small 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.

That’s all for today! Blah, blah, blah...