1 / 21

The ALPHA++ Project in ALEPH

The ALPHA++ Project in ALEPH. Guenther Dissertori CERN EP Guenther.Dissertori@cern.ch RD45 Workshop, Oct 98. 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

jovan
Télécharger la présentation

The ALPHA++ Project in ALEPH

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related