This is a longish and rather technical mail about bytestream decoding in ATHENA... Its basically a brain dump of what I think Ive learnt recently before I (mercifully?) forget it all. Anyone still reading? OK. As you will have gathered from Juergens mail we now have bytestream (or to use Normans phrase, bite scream) decoding infrastructure in ATHENA for the five potential ROD fragments coming from the testbeam system. The current solution has the great advantage that it does seem to work and means we might be able to make event by event comparisons with calorimeter data at the testbeam. However it is extremely stupid, with simple duplication of code into five pairs of classes which are identical apart from naming. For each fragment there is an xxxBytestreamCnv and xxxBytestreamTool class each of which can handle exactly one fragment of one type (identified by ROD source ID) and converts it to one L1CaloRdoStore subclass with one corresponding key used by StoreGate to look up the object. They five class/key combinations go into a jobOptions fragment and the five classes are declared in the src/components Gaudi library magic. The reason for this duplication is that the simple bytestream decoding infrastructure in ATHENA just converts one fragment to one object of one class. Its not clear to me from the code that it is definitely that limited, but from conversations with Tadashi, I think (and sometimes its hard to be sure what he is saying) that he believes that to be the case. A couple of days ago I spent the best part of an hour with Alessandro di Mattia who is the bytestream expert for the RPCs and MDTs. I was trying to understand more about the "collection bytestream decoding" service which I think is probably what we need for coping with many fragments of the same or different types. Im still not sure I understand it, but I gathered from him that most of the complexities I saw in the various muon examples I looked at were a necessary part of the architecture and not just their optional choices. It was clear that we would not be able to replicate that for L1Calo quickly, hence the decision to go for the stupid, but quick to do, duplication of the simple classes. So what will we need to do it properly? I think we may not be able to use the L1CaloRdoStore, or at least not in the same way or not without modification. Although the simple BS conversion allows you to put an object of _any_ class into StoreGate, it seems that the collection BS conversion needs you to have _particular_ subclasses of StoreGate classes. The structure seems to be that your BS conversion will create one overall "identifiable container" (not sure of the classname). This contains "collections" which are subclasses of the templated DataVector class. One collection may only contain one type of RDO. I am not sure if subclasses will work. Certainly in one of his examples, Tadashi uses a single class with a type field to distinguish completely different types of data. Alessandro does the same. This is not very elegant OO - Steves use of L1CaloRdo subclasses seems much nicer but may not be possible in this architecture. Subclasses might be "sliced" back to their base class. I dont know and we should check. The "container" and "collections" require an offline identifier scheme. This is an integer (or set of integers) that identify one RDO - or maybe just a collection? Im not quite sure of that but maybe Alan knows - having struggled with LAr/Tile identifiers? Apart from the identifiers, we will need a mapping service to convert the identifiers to the ROD fragment source IDs containing the bytestream words for those objects. To create bytestream files from ATHENA simulation we also need the reverse mappings. So I think the architecture requires these classes: - RDOs (we have them, but may not be able to use Steves subclasses?) - converter service class ("Cnv") - associated templated converter Tool - mapping service - identifer class(es)? - collection (similar to L1CaloRdoStore but based on DataVector) - container (simple subclass of identifiable container?) We will also need to decide on the organisation of our collections and how they map onto our "detector elements". For real detectors thats mean cells in eta,phi space. For us I guess its modules (which also map to eta phi of course). The choice dictates the scheme used for the identifiers (somehow). For most detectors there are optimisation reasons for choosing one set of collections over another, ie whether to have a large number of small collections or small number of large collections and which groups of elements in eta phi space go in each one. I think this is mainly to do which how level2 wants to access them. It seems to me we have the following possible choices; (a) one single collection with absolutely everything (b) one collection per ROD with all data from that ROD (c) one collection per source module (PPM, CPM, etc) (d) one collection per L1CaloRdo subclass with all objects of one subclass from the whole system (eg all CPM hit words) (e) subdivisions of (d) by ROD or source module. I think we have no requirements to optimise access by level2 so probably option (a) would be OK for us. I dont know if we have other reasons for subdividing things like (b) or (c). Maybe. If we wanted to keep the nice L1CaloRdo subclasses we might try for (d). However, although I believe that the "collection bytestream decoding" service does not have limitations of gathering N ROD fragments into one collection (to be checked) Im really not sure if one can split words from one ROD fragment into several collections. So (d) and (e) might fall foul of the existing bytestream architecture - at least without some special extra coding. Apparently the RPCs do some complex things but it didnt sound easy. All experts we have talked to so far (John Baines, Tadashi Maeno and Alessandro di Mattia) tend to refer hard questions up to Hong Ma who is the real expert so perhaps we should try talking to him... Free drink to anyone who gets here having read every intervening paragraph!