June 19, 2002 A Software Skeleton for the Full Front-End Crate Test at BNL Goal: to provide a working data acquisition (DAQ) system for the coming full.

June 19, 2002

A Software Skeleton for the Full Front-End Crate Test at BNL

Goal: to pGoal: to provide a working data acquisition (DAQ) rovide a working data acquisition (DAQ) system for the coming full FE crate testsystem for the coming full FE crate test

In this talk, I will In this talk, I will

describe the overall system setupdescribe the overall system setup

cover various software components andcover various software components and

report their status and/or what we intend to doreport their status and/or what we intend to do

Kin Yip

June 19, 2002

Tri

gger

Tow

er B

oard

Rea

dO

ut

Car

d TT

C C

ontr

ol

PT

G

veto

Data (through optical link)

trigger

trigger

Signal from a pulser(triggered by TTC)

FE Crat

e

memory

PU

Host 2

Host 1

“Host 2” — single board in the same crate as the Read Out Card — is a diskless node booted from “Host 1” through the network

~VME

Cal

ib.

boar

d

FE

B

DAQ-1

June 19, 2002

Control Crate (Wiener VME with CERN extension)

To control : Workstation Control Crate configure various boards in

the FEC

By using a PCI/VME bridge “Bit3”, the PCI bus on the workstation “maia” and the remote VMEbus in the Control Crate share memory and I/O

Programmed IO (PIO)

Dynamic Memory Access (DMA)

We have upgraded the operating system and the software driver for Bit3 (now from SBS). We have tested :

PIO : 3 MBytes per second

DMA : 15-16 Mbytes per second the obvious way to go

PTG (Pulse Trigger Generator, BNL-made) has been used to generate triggers in this new set of OS and Bit3 driver.

Other electronic components including TTC (with TTCvx and TTCvi) and the SPAC will have to be integrated into this system.

June 19, 2002

Read-Out Crate [Wiener VME (9U/6U) ]

Different from before, the CPU (VMIC) board is in the same crate as the electronic boards (2 Read-Out Cards)

Similarly, there is also a PCI/VME bridge “Tundra-Universe” that we have used to allow the CPU board to communicate with the electronic boards through the VME backplane

We have also upgraded the operating system and the software driver for this PCI/VME bridge. We have also tested :

DMA : 15-16 Mbytes per second

PIO : almost the same as above

We will have to develop the software to configure and read from the two Read-Out Cards when they are available, presumably with the help from the board maker in a similar way that we have done with the ROD Demo Board

Two controllers in two different crates

Controlling trigger rate

June 19, 2002

Data volume and storageA very rough estimate :

No. of channels ~ 16 128 = 2048

128 channels 2 K bytes

16 FEB 32K bytes per event

In a very rough estimation, if we take about 100 K events a day for 5 months, we will end up with ~500 GB of data.

We’ll use Magda (a distributed data manager prototype for Grid-resident data developed at BNL) to manage data transfer and storage

http://atlassw1.phy.bnl.gov/magda/info

We have tested and transferred data from our workstation through the USATLAS cluster to the HPSS (High Performance Storage System) at BNL.

The automatic procedures require two endless loops, one in our workstation (the one connected to the Control Crate) and one in the USATLAS cluster that has the appropriate read/write privilege from/to the HPSS

If desirable, we can replicate the data from BNL to CERN (Castor) which is said to have a cost of 2 SF per Gbyte.

June 19, 2002

Event Monitoring in DAQ-1

Basically, the “Event Sampler” process/interface in DAQ-1 gets the data and pass the data to the “Monitoring Task” process/interface

The “Monitoring Task” would unpack the data and analyze to produce, say, (Root) histogram and then

use the “Histogram Provider” to publish the histograms

The “User Histogram Task” would “receive” the histogram so that any user can examine

June 19, 2002

Possible realistic monitoring plots

June 19, 2002

Data format will be essentially whatever the Read-Out Card maker provides

Each run will start with a new file and the run no. is part of the filename

We expect to have some configuration information in the header/trailer

For Channel mapping, we want to put the mapping in the database and I have started with the one in Athena

We have to take care of all the hardware components such as FeedThrough, preamplier, motherboard etc.

Anaysis code in the framework of a simple C program will materialize at the debugging stage, as we need to check whether the data read out is correct, just like what happened to the ROD Demo exercise

For the general users, we provide the I/O unpacking routine and 3 stage skeleton interface, namely, “initialization, execution and finalization” so that the users can develop their analysis code easily in this framework

Data format, channel mapping and analysis

Runbook, Bookkeeping and DCSThrough the Web and Database server, we will provide the “Runbook” from which users may search for the system configuration for each run.

We will set up a simple report logging system for the “run shifters” to write down their concern or any special features or problems at certain run or time.

We will probably use the OBK (Online BookKeeing) feature in the DAQ-1 as it has easy access to all the run information.

The OBK experts have promised to provide an updated version which provides a Web-based interface.

In any case, the information will be available through the Web server

The DCS (Detector Control System) measurements taken from the FEC will be done asynchronously with respect to the rest of data acquisition

We have sent a PC to CERN and the DCS software system is being set up

We have to figure out what parameters we need to measure

The DCS information will be transferred to the Database and Web servers so that it is readily available to all users