KLOE Daq Event Building and final YBOS Output

The Kloe event Building is done in three stages:

---

• RECEIVER-STAGE (author: W.Grandegger):

  ---

  For each DAQ chain the sub-events collected in "streams" by the "collector" processes running in the L2 CPUs are sent via the l2send processes and trough the usage of the DFC map to their final destination SBC node. In each node a l2receive process puts the streams of subevents in a multiple (for the different chains) circular buffer . A full description of the Sender/Receiving processes and test of performances done for different configurations can be found here (Wolfgang Note/Memo or whatever + a detailed WWW page). In this first stage the builder access the circular buffer and, for each trigger number, locates the sub-events of each chain. Then it gives the complete list of these sub-events to the following stages. A description of the used data structures for streams, header of the strems, subevent and slavesubevent can be found here .

  ---

• ROCK-MANAGER CONSISTENCY STAGE (author: I.Sfiligoi):

  ---

  For each trigger number, the internal consistency of the RockManager super-frame for the sub-events is checked by comparing the trigger-word in the sub-headers and testing the sub-footers position. In the data words coming from the RockM no explicit reference to the chain number exists.

  ROCK MANAGER DATA WORD

  NVD	Crate	Na	SupFrame	SofFrame	EofFrame	Slot	Channel	RsvB	Data
  31	30-28	27	26	25	24	23-20	19-13	12	11-0

  The event output is simplified eliminating all the unused words (i.e. the sub-headers and sub-footers) and adding the information of the number of daq-chain which is useful for the Detector Mapping . and offline reconstruction. The final daq data word after this reformatting is as follows:

  DAQ OUTPUT DATA WORD

  Chain	Crate	Slot	Channel	RsvB	Data
  31-28	27-24	23-20	19-13	12	11-0

  The list of subevents give in Input to the last stage is called l2slavesubevent consisting in data lengt, event number and array of Daq Data Words.

  ---

• YBOS BUILDING STAGE (Author: S.Miscetti)

  ---

  To minimize the work to be done Online and to avoid unnecessary and unwanted errors we have decided to operate the so called Fast Ybos event building assuming the following constraints:

  • The translation from DAQ Geographycal to Detector addressing is a full load of the DMAP package and it is the first relevant Offline or Online monitoring operation. Online Data Words will keep the Daq Address.

  • The usage of the Dmap Online has to be minimized. It should be avoided whenever possible to translate the addresses of each single Daq words in order to make just memcopies of the received sub-events. In order to do this we have required that only one detector for chain is allowed . Of course each detector can have more than one chain.

  As a conclusion of all this discussion we have changed the old proposed Kloe Data structure and reduced the Ybos event Building to 6 banks only:

  • LRID

  • EVCL

  • Detector Banks (CALR,DCHR,QUAR,TRGR)

The most recent version of the package l2build is available trough: packman L2 v2.1 . There are some other processes which share a lot of goodies with the event Building. The mostly connected are:

• l2record for the moment just on disk. Tape will probably not be implement as an L2 process.
• l2spydaemon from memory.

Accessing Ybos information:

• From disk:
  • Simple F77:
    • l2ybosread.f (HP) ,
    • l2ybosreadosf.f ,
    • example of Makefile ,

  • USING A_C:

    whatever A_C executable can access data both on OSF/HP just using inp module read, inp file filename, use your_module. Example to get DAQ - information.

    • setup your logicals with: source raw2cele_setup.csh
    • use from Offline area $K_TLS module RAW2NTU
    • Dictionary file for linking: raw2ntu_dict.uic

• From the memory:

  Trough the usage of the package l2yboslocate

See the official page.