Data Flow Description

Joined work of:

• Daniel Lellouch
  
• Raz Alon
  
• Ohad Silbert
  

RDO Structure

Bytestream conversion is triggered on demand: A client opens the TgcRdo container in the data store and asks for a particular collection by key. If the key is not in the store, the store is programmed to activate the registered converter for that type of data (this is true for everything in the store, not just RDO). The registered converter then tries to fill the store with the requested data. In the RDO case, the stored converter activates the Bytestream converter. So the only way to see BS conversion in action is to write an algorithm that specifically asks for the data.

TgcRdo is a DataVector of TgcRawData. TgcRawData is basically a simple object which has a few different constructors, one for each bytestream fragment id and it usually assings the values given in the arguments into members.

A creation of a TgcRdo has the following flow:

• In TgcRdoContByteStreamCnv::createObj, a TgcRdoContainer is instantiated, and filled with one TgcRdo for each of the 12(RODs?) x 2 (end caps) = 24 rdoIds.
• missing link - who takes one TgcRdo out of the above collection and passes it to the user below
• TgcRdoByteStreamTool::convert receives a collection of ROBs and an RDO. It extracats the headers, status and data fromt eh ROB and uses:
• TgcROD_Decoder::fillCollection gets as arguments a bytestream (starting already at the data part), an RDO and all the headers and status words, and uses TgcByteStream::ByteStream2Rdo to convert the bytestream.
• TgcByteStream has two methods, Rdo2ByteStream and ByteStream2Rdo. One of the arguments to ByteStream2Rdo is a TgcRdo. In ByteStream2Rdo, TgcRawData objects are created according to the fragment id (different constructor for each type) and pushed into the given TgcRdo.

-- RazAlon - 10 Dec 2007

PRD Structure

PRD (Prepared Raw Data), Also referred as RIO (Reconstruction Input Object), is an object built out of RDO. It contains a hit segments data using the global coordinate system .

The manipulation of PRD is defined by several classes and packages. (I STILL HAVE TO FIND WHO CREATES AND WHO USES PRD)

• TrkPrepRawData - The package that defines the PrepRawData base class. The implemetation of the abstract classes is done in InDetPrepRawData and MuonPrepRawData.
  • Trk::PrepRawData - This is the base class. It contains the following members:
    • clusId - This is a 32 bit identifier of cluster that produced this PRD (strip, tube etc.). (NEED TO FIND OUT WHAT VALUES THIS IDENTIFIER TAKES AND HOW THEY ARE DETERMINED)
    • locpos - This is the local position of the measurment in the local coordinate system of the detector - This is still not the global coordinate system. This is of type Local Position
    • rdoList - This is a list (vector) of identifiers (32 bit) that procduces the PRD.
    • locerr - The errors in the measurments. Can be null. Of type ErrorMatrix.
• MuonPrepRawData - A package that provides Muon spectrometer specific implementations of the common Trk::PrepRawData. It contains Muon::CscPrepData, Muon::RpcPrepData and Muon::TgcPrepData. All of them are derived from Muon::MuonCluster.
  • Muon::MuonCluster - This class represents a cluster in the Muon spectrometer. It is derived from TrkPrepRawData. It has the following members:
    • RODId - A 32 bit identifier of the central measurment of the cluster.
    • CollectionHash - The hash associated with the PRD collection is the storegate.
    • locpos - The position of the cluster in the detector loacal coordinate system. The first coordinate is the precision (???) coordinate, the second is set to the center of the strip.
    • rdoList - List of channels associated with the cluster.
    • locErrMat - The measurement errors.
  • Muon::TgcPrepData - This class derives from Muon::MuonCluster. In addition to the base class members it also has another member:
    • detEl - This is of type MuonGM::TgcReadoutElement. This is a pointer of the Detector Element on which the measurement was done. This object is part of the GeoModel and it is used to find the coordinates in the global coordinate system. (I THINK IT HAS NO OTHER USES BESIDE IT)
    • Global Position - Of type Trk::GlobalPosition. It is calculated from detEl and locpos.

The package MuonRdoToPrepData Transforms RDO into PRD. It has the four classes: CscRdoToCscPrepData, MdtRdoToMdtPrepData, RpcRdoToRpcPrepData and TgcRdoToTgcPrepData.

• TgcRdoToTgcPrepData - Derives from Algorithm. It loops over TgcRDO, decodes each of them and fill up PrepRawDataCollection. The collection itself is kept in the Storegate.

-- OhadSilbert - 06 Dec 2007

ESD/AOD Data

I found the following image. This was taken from an old talk given by AmirFarbin

Basically, The reconstruction produces ESD files with containers that associate the hit clusters in the detectors to particle track. The ESD size is ~500k/event.
The AOD is produced out of the ESD by an AOD builder. The AOD builder rearrange the particles in "physical" containers such as electrons, muons, taujet etc, and trim unrelevant information on the detector itself. There is a way to go back from the AOD to the ESD to find more information about each element. The AOD size is ~100k/event.
Ther Event Tag consist only a small fraction of event data, in order to classify the events according to important final state particles. It is build out of the AOD (In this diagram it doesn't look like this, but all the refferences I found showed that the data is coming from the AOD) and its size is ~1k/event.
ling to AOD and ESD keys

-- OhadSilbert - 02 Dec 2007

Open issues

• What is MuonRawDataMonitoring? What is MuonMonitoring?

-- OhadSilbert - 06 Dec 2007