talk_190298

Minutes of the meeting on the 30.6.98

Present : Dieter Schlatter, Florence Ranjard, Paul Colrain, Giuseppe Bagliesi, Guenther Dissertori, Dirk Duellmann

Giuseppe Bagliesi reported on a first attempt to implement some ALPHA features into our alpha++. In particular, he has created a virtual baseclass AlephObject, from which AlephTrack and AlephEflow classes are derived. In the derived classes the virtual functions QP,QX, etc. (those from ALPHA) are implemented. In the main program he creates transient objects, which in their private part have the copies of the FRFT,FRTL and EFOL banks.
Click here to see the transparencies of his talk. (Note: This is a PDF file. If you do not have the correct plug-in for Netscape, save it and read it with acroread ).
The main problem he encountered was that he couldn't use STL (to build containers and iterators for the AlephObjects). This is because the HP compiler CC does not support STL, and the new aCC compiler would, but will only be supported by Objectivity/Db version 5, which is still not out, but should come soon. So for the moment he sticks to simple variable length arrays (just pointers), looping over it with a for-loop. Dirk suggest to write some simple iterator class which could do the job for the moment. He could help there.
Discussion: Then there was some discussion about the status. Dirk explained what are the pro and cons of copying the info from the persistent classes to the transient ones. In fact, one could create transient objects, which have the correct pointer to the persistent object from which the info could be retrieved. Doing this, the cache handling is done by Objectivity, i.e., by the ooHandle class. The first time an object is required, it is copied to the cache. This gives some advantage if only part of the full data are accessed, or if the information is accessed only few times (which could be the case for us, such as track info, as one typically loops over tracks only once per event).
The advantage of copying everything is that Objectivity is decoupled from the rest (in fact, BABAR is doing something similar), and it could be faster if a lot of data are accessed very often (per event). In this case, the cache handling is not done by Objty. Another advantage is flexibility, in the sense that one can easily change the definition of transient classes and even change the content of objects without altering the content of the database.
Guenther proposes to do some simple performance tests on the database now, since we still have few objects, so changing the code is fast and simple. One should compare copying the data with accessing the data via ooHandles from the transient object. Giuseppe will try to do that.
Another problem which has to be studied is the implementation of links from the EFOL bank to the original Track, ECAL, HCAL banks etc.
Dieter reminds that it should be possible to run over RECO and MCTRUTH. The interface should stay the same. So one could introduce derived classes such as AlephRECOTrack and AlephTRUETrack, and do the correct looping according to some switch.
Dirk mentions that he has written some code for compression of VArrays.
Generally it is agreed on that it is better to do the analysis with transient objects, not write AlephObjects to the database. The only thing which should go there in addition are tags.
The next thing which should be written asap is some AlephSession class!! Dirk promises to give some talk on the classes available in the LHC++ libraries. There are many goodies, such as automatic container handling.
The stuff written by Giuseppe might appear as a new release.

Guenther Dissertori
Tue Jun 30 19:20:38 MET DST 1998