The ALPHA++ Project in ALEPH

1. The ALPHA++ Project in ALEPH Guenther Dissertori CERN EP Guenther.Dissertori@cern.ch RD45 Workshop, Oct 98 Guenther.Dissertori@cern.ch

2. Contents • The goals of the project • Time-Table up to now • The first set-up • The ALEPH data structure and its conversion to persistent objects • The first database • Situation at the moment • Problems encountered • Summary Guenther.Dissertori@cern.ch

3. The goals of the Project • convert the ALEPH data (preferably LEP2 data) from the BOS bank style into persistent objects and write them to an object database (Objectivity/DB) • rewrite a mini-version of the ALEPH analysis package ALPHA in an object oriented computing language (C++), based on the Objectivity database • compare standard and OO performance with regard to efficient access of the data Guenther.Dissertori@cern.ch

4. Goals contd…. • test the software engineered by the RD45 and LHC++ projects. • Provide some input/experience for a possible archiving of ALEPH’s data • Give an opportunity to learn OO programming and design Guenther.Dissertori@cern.ch

5. Time Table • Early Spring 98: • set up of a small group • got into contact with people from RD45 and LHC++, in particular with Dirk Duellmann. • Preparation of the code for bank conversion • May 98: • First release of a database and a simple program to write and read it • June 98: • Second release with several improvements Guenther.Dissertori@cern.ch

6. Time Table, contd... • Summer hole….. • September 98: • Efforts on the analysis package side are increased • October 98: • trial to move from HP to DEC (but still using Objy Version 4) Guenther.Dissertori@cern.ch

7. The First Set-Up A brief review of the ALEPH data structure (main architecture in ALEPH : DEC UNIX (OSF1), version 4.0b) Guenther.Dissertori@cern.ch

8. The ALEPH data structure • Aleph uses BOS for the memory management: • Event data are in memory in COMMON/BCS/IW(...) • BOS provides the I/O stuff and the utilities to “navigate” in BCS through the BANK concept • The ALEPH data are organized in BANKS • The BANKS are described in an “almost” OO language: ADAMO • ADAMO offers a conversion to C headers files (structures) • The translation ADAMO DDL« C++ class is trivial Guenther.Dissertori@cern.ch

9. ADAMO DDL FRFT : 'Global Geometrical track FiT NR=0.(JUL)\ Number of words/track\ Number of tracks' STATIC = (InverseRadi = REAL [*,*], TanLambda = REAL [*,*], Phi0 = REAL [0.,6.3], D0 = REAL [-180.,180.], Z0 = REAL [-220.,220.], Alpha = REAL [-3.15,3.15], EcovarM(21) = REAL [*,*], Chis2 = REAL [0.,*], numDegFree = INTE [0,63], nopt = INTE [0,149] ); C++ CLASS class FRFT { public: // default constructor FRFT() {} float InverseRadi; float TanLambda; float Phi0; float D0; float Z0; float Alpha; float EcovarM[21]; float Chis2; int numDegFree; int nopt; }; Example: The FRFT bank Guenther.Dissertori@cern.ch

10. The DDL structure ooObj NAME=FRFT =FRTL = . . . . AlephBank void setname(char* name) int LoadFromMem(int* p) In total : 173 banks!! char*4 _bankname NAME_Bank NAME ooVarray(NAME) NAME_Table float InverseRadi; float TanLambda; float phi0; …. int LoadFromMem(int* p) Guenther.Dissertori@cern.ch

11. The Database structure Database 1 Container Container Container Events_<run#> Banks_<run#> Runs Database 2 Federated Database Run Event Bank Bank Event Bank Guenther.Dissertori@cern.ch

12. ALPHA++ Release2.1 Using the previously explained structure, a first database was built: • 2000 data events (1997) and 1000 qqbar MC events have been copied into the Objectivity database • C++readDB program allows to: • Loop over the events and over the banks • Copy the BANKS from Objectivity back to the BOS common • The “standard” ALPHA can be run reading the events from Objectivity and calling the FORTRAN from C++ • It is possible to run DALI (Event display), reading the events from Objectivity • It is possible to fill HistOOgrams and write them to our FD. • I do not have hard numbers for performance comparison, but running on small data set (interactively) gives satisfactory performance. Guenther.Dissertori@cern.ch

13. The analysis side • The Idea is: • put a layer between database and analysis • concrete: during reading time for every event transient objects are built from the persistent ones, and the analysis runs only on these transient objects • At the moment also the BOS common is filled again, so in principle it is possible to run our full ALPHA • The analysis performance could be increased by writing also TAGS to the database with links to specific events, and only those events are copied into memory then Guenther.Dissertori@cern.ch

14. A first analysis model Guenther.Dissertori@cern.ch

15. The analysis objects... • In ALPHA the “tracks” have common attributes: • QP, QX, QY, QZ … • Reproduce the ALPHA structure • tracks, Eflow, Calobjects, photons… • Inheritance from the abstract class AlephObjects • Vertices • Inheritance from AlephVertices • Abstract Class class AlephObject { public: ~AlephObject(); virtual float QP() = 0; virtual float QX() = 0; virtual float QY() = 0; virtual float QZ() = 0; virtual float QE() = 0; virtual float QM() = 0; virtual float QCH() = 0; }; Guenther.Dissertori@cern.ch

16. The situation at the moment • Until now we have worked on HPPLUS, on some dedicated AFS project area ( not much space) • But we want to move to Digital Unix (most of the ALEPH env. is on Digital Unix) • In addition we got a dedicated 50 Gbyte disk attached to our big machine (shift50, DUNIX 4.0b, cxx 5.6) • Have to recompile our ddl’s on DEC and install a new database on our new big disk (...some problems encountered, see later) Guenther.Dissertori@cern.ch

17. At the moment…. On the database side : • Further upgrades planned (or working on, or done) • change all the built-in types to the ODBMS standard, eg. • char d_Char , int d_Long etc • replace Objty-specific types to HEP-aliases, eg. • ooHandle(AlephBank) HepRef(AlephBank) • Smart variant (by Dirk) of factory pattern in order to avoid inclusion of 173 bank header files (otherwise needed for bank construction) . This helps to improve considerably the compilation step. Guenther.Dissertori@cern.ch

18. At the moment… • Write a new database using the above upgrades on our big disk • about 130k events written. Example: One database contains • 8 runs , 47860 events , 3904243 bank-objects => 490k bank-objects/run , 6k events/run , 82 bank-objects/event • size : 1.21 Gbyte • Get a working program not only on HP, but also on DEC Guenther.Dissertori@cern.ch

19. At the moment…. On the analysis side : • Working on designs and implementation of • a session manager , which supervises a • database manager • IO-manager (user interface) • general iterator • interfacing and alignment of OO and Fortran part of the analysis package • Fortran should disappear slowly • implementation of analysis features (locking, relationships, b-tagging, jet finding etc) in OO Guenther.Dissertori@cern.ch

20. Problems encountered • When running ootoolmgr on hpplus and opening the window on a machine of our aloha cluster segmentation fault • The move from HP to DEC revealed itself more painful than expected: • the same code as on HP does compile (Obj 4, cxx 5.6), but produces system errors and segmentation faults which do not happen on HP • When compiling in debug mode (-g), the ddl-library and thus the executable blows up (>20 Mbyte) • If one tries to include all bank header files, the compilation phase “explodes” • Generally: • it is quite painful to work with 173 banks, and working with a sub-sample not always reveals all upcoming problems….. Guenther.Dissertori@cern.ch

21. Summary • The first setup of an OO database was rather simple and successful • A working (non-trivial) OO analysis program and serious performance tests to be expected in a couple of months • We have not yet tested (in detail) LHC++ analysis tools such as IRIS(+HEP) EXPLORER • Recently some difficulties in migrating to DEC encountered Many thanx to Dirk Duellmann for his support and patience!!! Guenther.Dissertori@cern.ch