Analysis

List of tools to analyze the SiW ECAL Beam tests

Indico agendas for Analysis meetings:

• 3 Dec 2015: https://indico.in2p3.fr/event/12487/
• 10 Dec 2015: https://indico.in2p3.fr/event/12532/

Analysis Topics

• Check pedestals and stability, dependency on rates and < adc >.
• Put threshold of < adc > to distinguish in-beam and out-of-beam acquisition.
• Calibration
  • High gain and low gain
  • Linearity between MIP position and , pedestals and
  • Check linearity between in-beam and expected response
• Anomalous readout: Check error rate for misbehavior.

Arbitrarily selected entries from e-log

Eg. for entry 958: visit https://llrelog.in2p3.fr/calice/958

958 - peak at 1350 for parallel beam

933 - S-curves, 49 degrees, for threshold=230, 270, 310, 350

882 - 4 channels of chip 12, dif 1, MIP for threshold = 200 and 230.

832, 786, 113 - reduced occupancy in central chip, triggers leak from BX to BX+1

762, 767 - problem with Zedboard <-> CCC cable

641, 618 - chip 15 reading out problem, solved by switching from 5 Hz to 4 Hz spill rate; from my memory: at 10 Hz half of chips was not read out

382, 447 - switch from 10 msec of spill dead time to 50 msec, 10 msec resulted in data corrupation

181, 392 - violin plot: MIP drops with total chip charge, pedestal is fixed (corresponds to average charge), the effect may be due to pedestal baseline negative shift with the total chip charge. Note, at this moment the effect of trigger shift from BX to BX+1 under load (described in entry 832) was not known.

153 - higher noises in DIF2 -> more "pedestal"-like triggers and retriggers, eg. in run 103

100 - fix threshold at 230

91 - dif0 removed from configuration, dif1,2,3 -> dif0,1,2

33 - dif order

27, 32 - first look at data: MIPs, N triggers in XY, retriggers, pedestal RMS

First (late) meeting

Data Access, Run Summary and Configuration

• Data Access
• Run Summary and Detector Configuration

Root framework

Analyze root online

• on DAQ machine llrcaldaq:/opt/root_scripts

  • .x ConvertDirectory2.C("nom_fichier.raw", true);

• The repository is: https://forge.in2p3.fr/projects/calice/repository/show/analyse/trunk/SiWECAL/root_scripts
  • svn co svn+ssh://svn.in2p3.fr/calice/analyse/trunk/SiWECAL

1. What does an event refer to in this case, we see that acqNumber and Event number changes at same time. It is just a just a counter when acqNumber changes ?

This is a bit complicated by the historic labelling:
An «event» is in fact one readout, or an acquisition spill (≠from SPS spills).
If I am no mistaken «event number» refers to the readout «by DIF», where as AcqNumber is a global numbering of readouts allowing to synchronise the differents DIF's (boards).

2. What is bcid ?

This is the Bunch Crossing ID (number). i.e the clock cycle number since the biginng of the spill (readout), modulo 4096 (2^12).
The clock frequency is 2.5MHz (400ns). The counter can cycle if the spill length is longer than 1.6ms.

3. What is SCA or Columns.

Those are the nicknames of the chip's memory. Chip by chip the self-triggered events (≠readout) are stored in the memory with a BCID.
Synchronisation of a board (and between boards) should be done using the BCID, as noise/cosmics/particle can fill some some Columns in a chip and not the next one.

4. We see that size of chipid is 16, so it has information about one layer. Where is information for other layers stored ? Does different files have different layer information ?

Well... the chip has effectively 16 memory cells. But the first one is filled by noise at the chip start (at the beninning of every spill).
So practically it should be 15. Can you e.g. check if the BCID[0] is the noise or a real event. If is is noise it should have a BCID*400ns≤~1ms.
The information for differents layers (boards) is in different files (DIF0,1,2).

R Framework

The online_monitor program is written in R language (please, see http://r-project.org). For those not familiar with R, it can be used as a GUI tool with a predefined list of distributions and a "Help" page with explanations. For people who know R, it may be used as a working environment to make a full analysis (both online and offline).

The code and installation instructions are available at http://balagura.github.io/online_monitor

If you have any questions, please, do not hesitate to contact Vladik Balagura (balagura@cernNOSPAMPLEASE.ch). Learning R may be difficult in the beginning, but I am sure that if you know it, you'll love it. To me, in a physics analysis it is more efficient than C++ and even python (that's why I've selected R for online_monitor).

The raw/ subdirectory contains raw*{C,hh} files written in C++ and an executable "raw". They give an example of decoding the raw data into several ASCII formats which are then "pipe'd" to the online_monitor.R code. This is done in the load.raw(file) function, which provides an example of raw data analysis in R.

If you want the simplest R environment without any online_monitor graphics, you may start R and copy-paste the following commands:

 
library(data.table)

pedestal.suppression = 0.05
online.monitor.dir = "type here your directory with fev10_chip_channel_x_y_mapping.txt file and raw/raw executable"

map <- fread(paste0(online.monitor.dir,'/fev10_chip_channel_x_y_mapping.txt')) # data.table with chip:channel <-> X-Y mapping
map[,i:=channel]

load.raw <- function(file) {
  ... copy-paste the load.raw() function from online_monitor.R ...
}

After calling load.raw('some raw file'), you should be able to see

 
hits
ev
ev.chip

ntuples (data.tables in R terminology) with the data.

Basic information on SKIROC2 & DIF data structure

Original from from Vladik's slides (https://indico.in2p3.fr/event/12487/contribution/0/material/slides/0.pdf)

• ILC timing: bunches in 1 msec bunch trains, then 199 msec idle time

• In prototype, bunch trains are emulated by “spills” (eg. 4-5 Hz), every period is split into data taking (also called spill) and readout (“dead” time). Eg. for ILC scheme: 1 ms + 199 msec. To increase an event rate at SPS we used much higher duty cycles (eg. 50 msec instead of 199 msec). Note: spill signal is inverted: during data taking the spill generator signal = 0 V, “dead” when =4 V.

• One BX takes 400 nsec (2.5 MHz). BX counter in SKIROC has only 12 bits,after 4096 BX it is recycled to zero. Therefore, only about 1.6 msec can be coded uniquely. Also, the very first BXs are not sensitive. In some runs we were running with such “unique” very short spills.

• SPS spill signal was not used, so both data in AND out of SPS spills have been always accumulated.

• Acquisition number = spill number = spill counter. The spill frequency and duration is available in run configuration *.xml files.

• In SKIROC there are 15 memory slots, called SCA's (or columns), all are used and working well. They are filled in the following order: 1, 2, 3, ... (up to 15). The memories are implemented as capacitors (analog memory). In the previous prototype it was checked, that there is no visible charge dissipation, the response to charge injection is linear with the same linearity slope for all SCAs (including the 1st, which keeps the charge the longest). The only “bad” effect which should always be taken into account: pedestals in different SCA's are different.

Data format

ACQid: number of the spill, increments on start acquisition

CHIPid: number of the chip sending data, increments on transmitON falling edge

nCHIP : total number of chips sending data

SIZE : total number of 16-byte data words

MSB - the most significant word

LSB - the least significant word

section	subsection	word	hex	ascii
SPILL header		marker	FFFC
		ACQid MSB
		ACQid LSB
			5053	SP
			4C49	IL
		blank space	2020
N times	CHIP header	marker	FFFD
		FF+CHIPid	FF..
			4843	CH
			5049	IP
		blank space	2020
	CHIP DATA
	...
	CHIP DATA
	CHIP trailer	marker	FFFE
		FF CHIPid	FF..
		blank space	2020
		blank space	2020
SPILL trailer		marker	FFFF
		ACQid MSB
		ACQid LSB
		00 nCHIP	00..
		SIZE MSB
		SIZE LSB
		blank space	2020

The SPILL header is written when a fast command startSPILL is received. The SPILL trailer is written when the signal end_readout from ROCs is received by the DIF. The CHIP header and trailer correspond to the falling and rising edges of "transmitON", respectively.

CHIP DATA is specific to SKIROC and is described in the following picture.

Note, that, in fact, this is a picture from a SPIROC (not SKIROC) documentation. Both chips have the same data format, except in SKIROC there are 15 SCAs and not 16 as shown in the SPIROC's picture above.

Also note: the Chip ID (8 bits) may be duplicated in the end of the data block (but may be not).

Connection of pixels on FEV10-11

* fev10_chip_channel_x_y_mapping.txt: Table with X-Y chip:channel correspondence. Every chip serves one square, (x0, y0) are the coordinates of its center. (x,y) are the pixel center coordinates. See an example of use in online_monitor.R where this file is converted to the "map" R-table.

The Team after the first analysis meeting

Created by VincentBoudry - 2015-10-27