Tags:
create new tag
, view all tags
Vetra_logo.png

VELO Upgrade Software

Vetra

Vetra is a gaudi-based platform used for calibration and special runs handling for Upgrade I silicon detectors, VELO and UT, with optional developing part for detector data emulation.

While Vetra has been present for before the Upgrade I and encompassed various software elements for the detector maintenance and cluster recognition, Vetra in Upgrade I (Run 3, 4) is focused on fast calibration and intelligent monitoring, as those will be critical due to significantly increased number of channels.

Vetra has been equipped with machine learning tools for fitting, data validation and ongoing trend analysis.

A typical usage of Vetra is to run in a standard calibration mode that takes the data from Storck webservice database that originated in WinCC and send them back to Storck so they eventually end back in WinCC calibration recipe. The procedure was intended to be fully automated, although it can be executed by user on demand. Custom and auxilliary sequences in Vetra are run on demand.

In case of any technical issues of the software, feel free to contact me: Pawel.Kopciewicz@cern.ch

In case of more generic questions/suggestions about the software contact Victor.Coco@cern.ch or Tomasz.Szumlak@cern.ch

Installation

The project is built on the lb-stack-setup. The software package is regularly updated under the link:

https://gitlab.cern.ch/rmatev/lb-stack-setup

To install Vetra, please do the following.

1. Make sure the prerequisites are fulfilled. When installing on lxplus or pluscc online clusters, the prerequisities are met by default.

- CentOS 7 machine or docker to CentOS 7

- HEP_OSlibs installed, if not please run the command:

sudo yum install HEP_OSlibs

- CVFMS installed, you can test it with:

ls -l /cvmfs/lhcb.cern.ch /cvmfs/lhcb-condb.cern.ch /cvmfs/lhcbdev.cern.ch /cvmfs/sft.cern.ch

If not, installing instructions can be found here: https://cvmfs.readthedocs.io/en/stable/cpt-quickstart.html

 - A file hssapi.h for distcc:

sudo yum install -y krb5-devel

2. Install the lb-stack setup:

curl https://gitlab.cern.ch/rmatev/lb-stack-setup/raw/master/setup.py | python - Vetra

Make sure python 3 is used, otherwise "FileNotFoundError" error would appear. You may need to replace "python" with python3" in the above line code.

Enter the directory:

cd Vetra

You should see the following.

Vinstall_1.png

3. Optional step. Mainly for developing purposes.

Open the setup-make.py file:

vi utils/setup-make.py

and comment "check_staneless(...)", line 389 in function checkout (the line number might differ if stack is updated)

It will prevent the system to constantly seek updates in the LHCb repositories you cloned. There are usually many, not related to Vetra at all.

4. Download the latest version of Vetra (for the moment stored in VPEmu_dev branch):

git clone --branch VPEmu_dev ssh://git@gitlab.cern.ch:7999/lhcb/Vetra.git

Vetra_git.png

5. Setup the gitlab connection. (step only necessary in the online cluster)

git config --global 'http.https://github.com/.proxy' lbproxy01:8080

6. Run the compilation process.

make Vetra

It can ask you for the git password a couple of times as the compilator is about to download a few different repositories before the actual installation. If you're not on lxplus, in case of any compilation errors/freezes, it might help to rerun the above command typing "make Vetra" again.

7. Vetra is ready to go.

General usage

 After Vetra is installed, go to the main Vetra directory.

On lbminidaq2-09, Vetra is located in /velo/Vetra/Vetra

On the CPU farm, it's located in /group/velo/sw/Vetra_soft/Vetra/

Vetra's main directory contains following files as for 7th March 2022:

Vetra_directory.png

Table that presents directory's purpose in the main Vetra location.

Directory Purpose
build.x86_64* Vetra executable directory to run the software
Options A directory with adjustable option files for Vetra sequences.
VP C++ scripts and python main configuration file (do not change!).
Monitoring A place for monitoring scripts external to gaudi.

1. To run Vetra in a sequence, go to the build directory:*

cd build*

2. And run Vetra. For instance, DecoderDIM.py is the option file for decoding dim-encoded files.

./run gaudirun.py ../Options/DecoderDIM.py

3. Vetra is now running and will print output log in respect to the input files you provided in the option file.

Format of the readout determines the sequence Vetra uses to analyse the data. Available sequences support all VELO data formats, which are .DAT , .FRG, .MDF and .CSV. Regard to needs, a few available variation of each sequence are available and each of them use their own option file.

Note that only option files should be changed, even though they only modify the main large configuration file in VP/Vetra/python/... . Every option file should contain following libraries:

from GaudiConf import IOHelper
from Configurables import CondDB, LHCbApp, ApplicationMgr
from Gaudi.Configuration import
from Configurables import Vetra
from Configurables import LHCbConfigurableUser, LHCbApp
import glob

In case the gaudi-specific algorithm has to be modified, such as EventSelector, it can be accessed via option file as well. Although, the default option files cover most of the functionalities one could change them in respect to the purpose they were created for.

Decoders

Vetra has 3 different decoders (DIM, FRG, MDF) built-in that can be used as sequence elements and 1 decoder (CSV) that can be called as a method.

A table below presents available decoder sequences to execute in Vetra.

Input origination Format Sequences available
WinCC dim writer DIM DecoderDIM.py
GWT, MDF raw banks MDF DecoderMDF.py
GWT counters FRG DecoderFRG.py
Vetra, SPIDR CSV None (uses VPDecodeCSV)

DIM Decoder

DIM files come from DIM reader/writer placed externally in WinCC environment to read out data coming from VeloPix ECS stream.

DIM format is a 6-byte format that needs the value mapping to be deciphered. It includes a header in a commissioning format that is constructed in WinCC VELO library, and is passed as an argument to dim writer when the data are read and sent to Storck. Header contains the necessary information of the scan and the run itself. Header detailed documentation can be found in:

https://codimd.web.cern.ch/-LDkHKFaQHyp7Ld3rBl1_Q#

A header is a binary word of 78 bytes. Headers appear in every file that comes in/out to/of Vetra.

CSV files have the header in the readable version, taking the 1st line of each file. Exemplary format of a header in the readable version found in CSV files looks as follows:
Mod1VP12 ASIC17 trim0 type1 2021-10-27_10-00-31 (1635321631) pkopciew elog1 runs0 90 5 20000 1100 1550 0 0 0 0 0

The option file for DIM Decoder is Options/DecoderDIM.py and contains the following self-explanatory configurables:

#Sequence type
Vetra().Usage="Decoder"

#Input files
Vetra().Input_format = "DIM"
Vetra().Input_files = glob.glob("../../../VeloPix_testing/TScan5/.dat")

#Output files
Vetra().Output_directory = "T5_decoded/"

Input files disk path takes an user-defined output directory. Input_files uses glob to grab all files that meet certain condition, in this case all files from given directory ending with .dat.

The console display for the decoding contains mostly the metadata from the header (see figure below). The header in readable format is also saved in the 1st online of each produced CSV file.

DIM_Decoder.png

As previously articulated, documentation on the header and its readable version can be found in https://codimd.web.cern.ch/-LDkHKFaQHyp7Ld3rBl1_Q#

DecoderDIM is a sequence element intended to be the first in the line. Produced files are raw_scan CSV files that can be used to manually run other sequences that are based on the CSV format input. Raw_data format is the old SPIDR format that has 256x256 pixel matrices saved on top of each other for consecutive DAC steps. In case only one threshold was measured, the produced CSV file is a 256x256 array of numbers corresponding to the VeloPix ASIC, with addition of the 1 line at the beginning designed to contain the readable version of the header.

MDF Decoder

MDF is a raw data format originated in Run 1 and 2 and contains raw data banks (raw events) in a gaudi scope. The format is fully binary and can be decoded used a special decoder. Vetra has such decoder as a sequence element with option file DecoderMDF.py. Since no format is defined for the pure decoded MDF file, the decoded data are not saved but printed in the console after certain condition in the option file is ticked on. MDF files usually come from other gaudi applications such as Boole. The flow of raw events is managed via gaudi EventSelector and is done on the Python-to-C++ level. Hence, the scripts that read raw banks and construct raw events are placed out of Vetra and in fact are part of core LHCb gaudi project.

MDF format features a 48-bytes lhcb-style header hardly documented anywhere. To have a basic view, first 12 bytes are the byte-length of the MDF-file, next 4 bytes are hashed length (checksum) that can't be simulated in a python way but the requirement of checking the checksum is currently disabled when using IOHelper. The compression byte, header type (55), data type, spare and the last 28 bytes not used in VELO processing.

MDF format contains the ODIN bank on top of 208 Velo banks stacked one after each other. The arising Run 3 ODIN documentation can be found here https://edms.cern.ch/ui/#!master/navigator/document?D:100350539:100350539:subDocs .The step number is stored as 15th byte (14 counting from 0) when reading it in the Little Endian style.

The Velo bank has the following structure:

Bytes Predefined Meaning
0-1 0xCB 0xCB Significator (magic number)
2-3 12 if empty Size in bytes
4-5 8, 2 Velo bank number, version
6-7 0-624 source ID
8-11 or more   (multiple) GWT word

A 4-byte GWT word is defined for every event in a Super Pixel as shown below:

GWT_word_pure.png

(first bits were ICF for clustering that got removed from the GWT word, hence its only 30 bits in size).

Since no format of data is defined for pure decoded MDF data, DecoderMDF does not produce any output files but optionally prints the decoded events in the console. Its main purpose is to stand ahead of any GWT/MDF sequence that would further produce data in a format specifically defined for the sequence. DecoderMDF is a multi-purpose sequence element that can be used in and off Vetra, for instance, it acts a sandwiched element that stands between simulation and Monet for the simulation hit monitoring (that will be described further in this documentation).

The option file for MDF Decoder is Options/DecoderMDF.py and contains the following options:

#Sequence
Vetra().Usage="Decoder"

#Input file
Vetra().Input_format="MDF"
Vetra().Input_files=["../Pix16_0.mdf", "../Pix16_15.mdf"]

#Display
Vetra().Print_events_in_console = True

The option Print_events_in_console allows to print the basic information of the decoded data, such as on the example below.

VDecoderMDF.png

The printed run number and step number come directly from the ODIN bank, the pixel information from decoded VELO banks.

FRG Decoder

The decoder for FRG frames is used to decode GWT counters data. FRG files do not currently feature any header with scan parameters but that can change in the future.

The firmware is not yet ready to produce a real data so the sequence still has to be debugged.

The GWT counters byte format is presented in the following scheme:

GWT_counters.jpg

It reads 4 Super Pixels at a time as 256-bit words (32 bytes) are read out to decode pixel and counters information.

The option file is fairly simple and should contain:

#Sequence type
Vetra().Usage="Decoder"

#Input files
Vetra().Input_format = "FRG"
Vetra().Input_files = glob.glob("../.frg")

Unlike the MDF, the FRG decoder is able to produce CSV files but cannot reproduce a header, so the saving functionality is disabled for the pure decoder. Though it can be possible when running FRG decoder in a sequence of ThresholdScan or Equalisation.

Threshold Scan

Vetra has 4 different recipes how to process a threshold scan (DIM, FRG, MDF, CSV). They can be used as immediate sequence elements or the ending elements if the threshold scan does not stand as part of larger analysis.

A table below presents available threshold scan sequence elements to execute in Vetra.

Input origination Format Sequences available
WinCC dim writer DIM ThresholdScanDIM.py
GWT, MDF raw banks MDF ThresholdScanMDF.py
GWT counters, bypass FRG ThresholdScanFRG.py
Vetra, SPIDR CSV ThresholdScanCSV.py

WinCC / Vetra decoders

A sequence for DIM format is a combined sequence of DecoderDIM and ThresholdScanECS. The option file is ThresholdScanDIM.py.

A sequence for CSV format is a ThresholdScanECS. The option file is ThresholdScanCSV.py.

Scan information is read through a binary/readable header for DIM/CSV format, where all elements of scan information are stored.

For example, following readable header indicates that a threshold scan was taken via the ECS fast readout (type1) and the DAC parameters were 1100 and 1500 for bottom and upper threshold scan boundaries, respectively.
Mod1VP12 ASIC17 trim0 type1 2021-10-27_10-00-31 (1635321631) pkopciew elog1 runs0 90 5 20000 1100 1550 0 0 0 0 0

Threshold scan for DIM format, ThresholdScanDIM.py, should contain following configurables:

#Sequence type
Vetra().Usage="ThresholdScan"

#Input files
Vetra().Input_format = "DIM"
Vetra().Input_files = glob.glob("../../../VeloPix_testing/TScan5/.dat")

#Output files
Vetra().Output_directory = "ThrScan_T5/"

And in case of CSV input, ThresholdScanCSV.py, of following configurables:

#Sequence type
Vetra().Usage="ThresholdScan"

#Input files
Vetra().Input_format = "CSV"
Vetra().Input_files = glob.glob("T5_decoded/.csv")

#Output files
Vetra().Output_directory = "ThrScan_CSV_T5/"

Threshold scan sequences can read as many independent files as provided in a single sequence.

In case the threshold scan parameters have to be manipulated, you need to manually change the bytes in the binary file for the DIM format. In case of CSV, changing a readable header in the first line can be done in a text editor.

Output files have the filename's format as given below:

Mod[no. mod.]VP[no. ASIC][no. tile]_[type of the file]_Type[type of scan]_trim[trim]_[date].csv

A successful threshold scan should yield the notifications as follows:

Vthrscan1.png

Produced files are noise, pedestals for CSV input and raw_data, noise and pedestals for DIM input. All produced data are number arrays of 256x256 in a CSV format with a header in the first line.

Raw data / Boole / MDF / Simulation

Threshold scan for MDF is executed in the sequence DecoderMDF, ThresholdScanGWT with ThresholdScanMDF.py option file.

Option file should look like the following:

#Sequence
Vetra().Usage="ThresholdScan"

#Input file
Vetra().Input_format="MDF"
Vetra().Input_files=["../Pix16_15.mdf"]

#Pixels and patterns
Vetra().Pixels_to_plot = [0, 0, 14, 1, 1, 0, 13, 0]  # sensor, ASIC, row, col

#Objectives for threshold scan
Vetra().Objective = [0x0]
Vetra().Range = [1200,1500]
Vetra().Threshold_step = 5

#Data output directory
Vetra().Produce_histograms = True
Vetra().Output_directory = "thr_scan_mdf/"

Objectives have to be filled manually as no calibration header is added on top of the MDF raw banks. Pixels_to_plot contains the list of pixels to be included in a pixel-specific histograms in a root file. There can be multiple pixels given, like there are two in the code block above. Range stands for the threshold scan boundaries and Threshold_step for the threshold scan step.

When successfully executed, it should display as follows:

Vthrscan2.png

Apart of the CSV files with threshold scan results that are produced, there is an auxilliary option Produce_histograms in the option file, which, when ticked on, would produce histograms of the threshold scans. An exemplary histogram, generated for the input data of 8 pixels (one Super Pixel) is presented in the picture below.

Vthrscan3.png

Produce_histograms option is not necessary as the sequences always produces output files in the CSV format, that is used for further data processing software.

GWT Counters

This sequences is very similar to MDF sequence as all scan information must be provided manually in the option file. The relevant option file is called ThresholdScanFRG.py and should contain:

#Sequence type
Vetra().Usage="ThresholdScan"

#Input files
Vetra().Input_files = glob.glob("/home/velo/VeloPix_testing/Calibration_15Nov/*")

#Output files
Vetra().Input_format = "FRG"
Vetra().Output_directory = "Cal_15Nov/"

#Threshold scan options
#... used only when a header is missing! (mostly FRG files)
Vetra().Trim = [0x0]
Vetra().Threshold_boundary = [800, 1650]
Vetra().Threshold_step = 5
Vetra().Number_of_rep = 5
Vetra().ASIC_unique = 122

#Miscellaneous
Vetra().ProduceHistograms = True

Note that the firmware for GWT counters is not yet ready and software would probably need some debugging when the final format data are received.

Equalisation

Similar to threshold scan, Vetra has 4 different recipes how to process the equalisation (DIM, FRG, MDF, CSV). They are usually the ending elements of the calibration sequences.

A table below presents available equalisation sequences to execute in Vetra.

Input origination Format Sequences available
WinCC dim writer DIM EqualisationDIM.py
GWT, MDF raw banks MDF EqualisationMDF.py
GWT counters, bypass FRG EqualisationFRG.py
Vetra, SPIDR CSV EqualisationCSV.py

Equalisation sequence produces enough data to fully calibrate the detector.

WinCC / Vetra decoders

A sequence for DIM format uses the EqualisationDIM.py option file. It is a combined sequence of DecoderDIM, ThresholdScanECS and EqualisationECS.

A sequence for CSV format uses the EqualisationCSV.py option file. It is a combined sequence of ThresholdScanECS and EqualisationECS.

Scan information is read through a binary/readable header for DIM/CSV format, where all elements for scan information are stored. Two additional threshold scan boundaries for higher trims are stored after the former ones.

For example, following readable header indicates that a threshold scan was taken via the ECS fast readout (type1) and the DAC parameters were 1100 and 1550 for bottom and upper threshold scan boundaries for lower trim scan, and 1500 and 1850 for higher trim scan, respectively.
Mod1VP12 ASIC17 trim0 type1 2021-10-27_10-00-31 (1635321631) pkopciew elog1 runs0 90 5 20000 1100 1550 1500 1850 0 0 0

The option file for DIM-mode equalisation should contain:

#Sequence type
Vetra().Usage="Equalisation"

#Input files
Vetra().Input_format = "DIM"
Vetra().Input_files = glob.glob("/home/velo/VeloPix_testing/TScan5/.dat")

#Output files
Vetra().Output_directory = "T5_equalisation/"

#Equalisation options
Vetra().DAC_mask_criterion = 25

While for the CSV-mode equalisation:

#Sequence type
Vetra().Usage="Equalisation"

#Input files
Vetra().Input_format = "CSV"
Vetra().Input_files = glob.glob("T5_decoded/.csv")

#Output files
Vetra().Output_directory = "T5_CSV_equalisation/"

#Equalisation options
Vetra().DAC_mask_criterion = 25

When used correctly, the following processing display should appear:

Veq1.png

 Products of DIM/CSV equalisation are masks, estimated pedestals and calculated trims in the form of 256x256 CSV maps.

Raw data / Boole / MDF

Equalisation for MDF banks is executed EqualisationMDF.py option file in a sequence with DecoderMDF, ThresholdScanGWT, EqualisationGWT.

Option file should look like the following:

#Sequence
Vetra().Usage="Equalisation"

#Input file
Vetra().Input_format="MDF"
Vetra().Input_files=["../Pix16_0.mdf", "../Pix16_15.mdf"]

#Pixels and patterns
Vetra().Pixels_to_plot = [0, 0, 1, 1, 1, 0, 0, 0]  # sensor, ASIC, row, col

#Objectives for equalisation
Vetra().Objective = [0x0, 0xF]
Vetra().Range = [1200, 1500, 1500, 1800]
Vetra().Threshold_step = 5
Vetra().DAC_mask_criterion = 25
Vetra().noise_mask_criterion = 10

#Data output directory
Vetra().Produce_histograms = True
Vetra().Output_directory = "eq_mdf/"

Objective option contains both trim values that were used at the equalisation. It does not necessary has to be the lowest and highest trim possible. Range covers the threshold scan region for both scans in the form of [bottom_lowtrim, top_lowtrim, bottom_hightrim, top_hightrim]. Noise_mask_criterion is a condition playing a role in masking noisy pixels, while DAC_mask_criterion is used to classify the pixels that are out of the equalisation scope.

Display log should show the following:

eq_mdf_log.png

Histogram persistency is optional and available in case .root files output data are needed.

The mask histogram:

eq_mdf_mask.png

Threshold scan and equalisation:

eq_mdf_h1.pngeq_mdf_h2.pngeq_mdf_h3.png

Produced file are .CSV 256x256 maps of masks, estimated pedestals and calculated trims.

GWT Counters

A similar sequence to MDF but with FRG files as input. The relevant option file is called EqualisationFRG.py.

The configuration file should look as follows.

#Sequence type
Vetra().Usage="Equalisation"

#Input files
Vetra().Input_files = glob.glob("/home/velo/VeloPix_testing/Calibration_15Nov/*")

#Output files
Vetra().Input_format = "FRG"
Vetra().Output_directory = "Cal_15Nov/"

#Threshold scan options
#... used only when a header is missing! (mostly FRG files)
Vetra().Trim = [0x0, 0xF]
Vetra().Threshold_boundary = [800, 1650, 1100, 1900]
Vetra().Threshold_step = 5
Vetra().Number_of_rep = 5
Vetra().ASIC_unique = 122

#Equalisation options
Vetra().DAC_mask_criterion = 25

#Miscellaneous
Vetra().ProduceHistograms = True

Objective option contains both trim values that were used at the equalisation. It does not necessary has to be the lowest and highest trim possible. Range covers the threshold scan region for both scans in the form of [bottom_lowtrim, top_lowtrim, bottom_hightrim, top_hightrim]. DAC_mask_criterion is used to classify the pixels that are out of the equalisation scope.

Produced file are .CSV 256x256 maps of masks, estimated pedestals and calculated trims.

ECS Test Pulse

Test Pulse scan uses ECS count mode. A sequence defined for the old SPIDR format takes CSV files and the metadata files with headers and scan parameters.

It will be moved for the commissioning to the final WinCC format.

The option file called TestPulseCM.py includes:

#Input files
Vetra().Input_files = (glob.glob("../Ipre160_TP154/testpulseiter*")
+ glob.glob("../Ipre160_TP154/vf.txt")
+ glob.glob("../Ipre160_TP147/testpulseiter*")
+ glob.glob("../Ipre160_TP147/vf.txt")
+ glob.glob("../Ipre160_TP161/testpulseiter*")
+ glob.glob("../Ipre160_TP161/vf.txt")
+ glob.glob("../Ipre160_TP168/testpulseiter*")
+ glob.glob("../Ipre160_TP168/vf.txt"))

#Sequence type
Vetra().Usage="ECS_TPCountMode"

#Scan parameters
Vetra().Threshold_step=2
Vetra().Threshold_bottom=1002
Vetra().Threshold_top=1800
Vetra().Number_of_TP=50
Vetra().TP_Fit_Boundary=[31,41,31,41]

#Output files
Vetra().Produce_histograms =1

#Equalisation files
Vetra().Equalised_Pedestals = ["TrimBest_Noise_Predict.csv"]
Vetra().Noise_sigma = "Width_0trim_Scan_ID.csv"

Number_of_TP defines how much test pulses were sent to pixels. ECS count mode is a 6-bit mode, so the maximal number of test pulses to count is 63. Threshold scan options are the same as in ThresholdScan sequences. TP_Fit_Boundary is an intelligent fitter option that tells the algorithm between which threshold DAC values we are interested to have a fit to. Test Pulse scan requires the equalisation files, so the equalisation has to be executed beforehand.

This sequence will also calculate and produce gain data. To plot this data, we can use a monitoring script in ../Monitoring/TestPulsePlot.cpp:

tp1.pngtp2.png

To plot the gain, you can use a monitoring script in ../Monitoring/GainPlot.py, which will produce following results:

tpgain.png

The Test Pulse / gain sequence can be used for DAC optimization and be executed for different DAC values. This purpose does not have its default option file yet as the procedure is still under development.

ECS ToT readout

A Time over Threshold (ToT) readout is available in WinCC, which produces data in a similar DIM-encoded format like the usual count mode. Such data can be analyzed in DecoderDIM and a ToT sequence, which does not differ from usual count mode sequence too much. Although it is in the final development stage and does not have the deafult option file defined, the ToT-related sequence elements are now functionally.

There is an option file ToTSource.py for Ikrum scans but is not strictly related to the daily operation software and reserved rather for testbeam measures.

Hit Monitoring

Hit monitoring includes integration .digi type files with Monet and is documented temporarily in the working codimd sheet under this link:

https://codimd.web.cern.ch/s/nkfzIGGV8#

Emulation

The optional and still developing part of Vetra includes emulation of the detector calibration data to both debug the software and to have the approximation of the calibration data flow. It mimics the detector when fully operational. There is a few generators written in python and C++ scripts and most complex of them are described in this section.

Unlike the CSV undecoded files, the MDF files require a special encoding that allocates threshold scan data into raw banks and splits them into events. The on-hand emulator and encoder was firstly written in python to give a flexible source of the correct data format to debug Vetra. It has been moved to Vetra special sequence, but its old version is still available in the Vetra's main directory under the name SimThrScan _SingleSP.py. Although its name suggets it yields single SP events, in fact it can produce a whole matrix of SPs but does that unconveniently slowly. It can be used for both debugging or visualisation and monitoring to prepare it for the daily operation tasks.

The exact same but more sophisticated algorithm can be found in Vetra. Its option file named Emulation_EqualisationGWT.py should contain:

#Sequence
Vetra().Usage="Emulation_Equalisation"
#Pixels and patterns
Vetra().How_many_sensors = 1
Vetra().How_many_ASICs = 1
Vetra().SP_at_once = 4
Vetra().Pattern_repetition = 2  # 16 to cover the first column of SPs
Vetra().Pixels_to_plot = [0, 0, 14, 1, 1, 0, 13, 0]  # sensor, ASIC, row, col

#Objectives for equalisation
Vetra().Objective = [0x0, 0xF]
Vetra().Range = [1125, 1375, 1425, 1675]
Vetra().Threshold_step = 5
Vetra().DAC_mask_criterion = 25
Vetra().noise_mask_criterion = 10

#Pixel properties
Vetra().Pedestal_center = 1250
Vetra().Pedestal_sigma = 20
Vetra().Noise_mean = 7
Vetra().Noise_mean_sigma = 1
Vetra().DAC_per_trim_mean = 20
Vetra().DAC_per_trim_sigma = 0.4

#Data output directory
Vetra().Output_directory = "Emulation_EqualisationGWT_stream/"

Please keep in mind it is still a developing version and does not take into account the geometry of the detector.

The emulation can be pinned directly in the sequence that analyses emulated data in one Vetra run. Obtained results have exact same format as they would originated in the real detector.

Beside the GWT emulation, ../MDFReader.py prints the bytes of the MDF file and GWT_simple_decoder.py decodes the events from the MDF file, which can be very useful at debugging both format of the file and the software.

Monitoring

Local monitoring in Vetra for data quality overview is available. There are many scripts in ../Monitoring/ directory that can be used for this purpose.

For instance, Velo_mask.py and Velo_trim.py would yield following visualisation:

noise.pngtrim.png

The monitoring part is constantly developed as the commissioning is approaching and this section will get bigger in time.

Special scans

If a scan to be taken exceeds the standard calibration procedure, it is considered a special scan. Vetra has a capability to process such special scans when properly configured. This example will show how to use Vetra to process the temperature special scan (i.e. calibration efficiency in the function of chip temperature).

In order to get the necessary data, multiple threshold scans have to be executed in WinCC. After the data are collected, all paths should be specified in ThresholdScanDIM.py option file. Vetra can process multiple independent threshold scans in a one run, using only one option file. After data are processed, the ../Monitoring/Column_noise_temperature.py or ../Monitoring/Column_noise_temperature_Liverpool_format.py can be used.

After specifying conditions in those python scripts, the output would look as follows:

temp_special.png

The plots present the average noise standard deviation in a function of the column ID (on the left) and the average noise standard deviation distribution (on the right).

 

Calibration procedure

When the calibration is decided to be taken, a specific WinCC executable command is called to begin the calibration chain.

It can be also called and accessed manually at the WinCC equalisation panel:

eq_panel.png

To take a scan in WinCC using slice tests, please follow the documentation under this link:

https://codimd.web.cern.ch/AMhb7jCaSe2JynMiB2qCPQ#

When data are collected, they are sent off to Storck, if the User ID and Workspace ID are filled. Note that you can only click "Default" button to set up the predefined Storck server. In slice test or aluminium sandwich, the testing Storck database on CERN Open Stack is used.

WinCC2.png

You can access the Storck testing database (slice tests and aluminium sandwich) under the link (there have recently been issues with Open Stack clusters so it might not work perfect at the moment):

137.138.31.83:8000/view/main

If calibration files were properly uploaded, you should be able to find them at the top of the list in the online client interface:

Storck1.png

 Now you are ready to run Vetra like described in the Equalisation section.

 

Boole for VeloPix

Boole has to be installed through the nightlies (to be up-to-date with recent changes in master).

Assuming you are working on the lxplus, you can install it this way:

lb-dev --platform x86_64-centos7-gcc9-opt --nightly lhcb-head Boole/HEAD
cd BooleDev _HEAD
git lb-use Boole
cd BooleDev _HEAD

Then you can download necessary packages (e.g. package VP from Boole, there are also VeloPix related packages in Lbcom and LHCb) and compile:

git lb-checkout Boole/master VP
source /cvmfs/lhcb.cern.ch/lib/LbEnv
lb-set-platform x86_64-centos7-gcc9-opt
source /cvmfs/lhcb.cern.ch/lib/LbEnv
make

Now you need a config file (option file). You can name it as you want, e.g. VP-config.py but the inside of it should look like following:

from Boole.Configuration import *
from Configurables import Boole

Boole().DetectorDigi=["VP"]
Boole().DetectorLink=["VP"]
Boole().DetectorMoni=["VP"]
Boole().DataType = "Upgrade"
Boole().Outputs = ["DIGI","MDF"] # Test all output types
Boole().TAESubdets=["VP"]
Boole().InputDataType="XDST" #only if your data are XDST; if they are in the SIM format, replace it with "SIM"

LHCbApp().CondDBtag = "upgrade/sim-20180530-vc-md100"
LHCbApp().DDDBtag = "upgrade/dddb-20170301"

Now you need a data file. You can download an exemplary file like this one:

lhcb-proxy-init
lb-run LHCbDIRAC dirac-dms-get-file LFN:/lhcb/MC/Upgrade/XDST/00032857/0000/00032857_00000735_1.xdst

You also need a python file with the path of your data file, you can name it VP-data.py and it should contain:

g.py but the inside of it should look like following:

from Configurables import Boole
from Configurables import LHCbApp

inputFiles = ['00032857_00000735_1.xdst'] # put here a name of your file

from GaudiConf import IOHelper
IOHelper('ROOT').inputFiles(inputFiles)

Now you can run Boole:

./run gaudirun.py VP-config.py VP-data.py
Topic attachments
I Attachment Action Size Date Who Comment
PNGpng DIM_Decoder.png manage 19.1 K 2022-02-25 - 16:53 PawelKopciewicz  
JPEGjpg GWT_counters.jpg manage 31.1 K 2022-03-08 - 10:49 PawelKopciewicz  
PNGpng GWT_word.png manage 23.0 K 2022-03-08 - 10:49 PawelKopciewicz  
PNGpng GWT_word_pure.png manage 9.6 K 2022-03-08 - 10:51 PawelKopciewicz  
PNGpng Seq1.png manage 30.4 K 2022-03-08 - 17:06 PawelKopciewicz  
PNGpng Storck1.png manage 30.7 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng VDecoderMDF.png manage 9.0 K 2022-03-07 - 19:27 PawelKopciewicz  
PNGpng Veq1.png manage 15.5 K 2022-03-08 - 14:52 PawelKopciewicz  
PNGpng Vetra_directory.png manage 13.6 K 2022-02-26 - 16:07 PawelKopciewicz  
PNGpng Vetra_git.png manage 20.9 K 2022-03-08 - 21:32 PawelKopciewicz  
PNGpng Vetra_logo.png manage 24.5 K 2022-03-08 - 16:09 PawelKopciewicz  
PNGpng Vinstall_1.png manage 14.4 K 2022-03-07 - 15:07 PawelKopciewicz  
PNGpng Vthrscan1.png manage 15.1 K 2022-03-08 - 13:11 PawelKopciewicz  
PNGpng Vthrscan2.png manage 19.4 K 2022-03-08 - 13:46 PawelKopciewicz  
PNGpng Vthrscan3.png manage 30.8 K 2022-03-08 - 13:53 PawelKopciewicz  
PNGpng WinCC1.png manage 11.5 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng WinCC2.png manage 33.2 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng eq_mdf_h1.png manage 8.9 K 2022-03-11 - 13:17 PawelKopciewicz  
PNGpng eq_mdf_h2.png manage 8.4 K 2022-03-11 - 13:17 PawelKopciewicz  
PNGpng eq_mdf_h3.png manage 6.9 K 2022-03-11 - 13:17 PawelKopciewicz  
PNGpng eq_mdf_log.png manage 17.4 K 2022-03-11 - 13:06 PawelKopciewicz  
PNGpng eq_mdf_mask.png manage 75.8 K 2022-03-11 - 13:17 PawelKopciewicz  
PNGpng eq_panel.png manage 140.1 K 2022-03-09 - 14:57 PawelKopciewicz  
PNGpng equal_monit.png manage 16.5 K 2022-03-08 - 17:09 PawelKopciewicz  
PNGpng masks.png manage 20.7 K 2022-03-08 - 17:09 PawelKopciewicz  
PNGpng noise.png manage 174.1 K 2022-03-08 - 17:09 PawelKopciewicz  
PNGpng pedestals.png manage 110.2 K 2022-03-08 - 17:09 PawelKopciewicz  
PNGpng temp_special.png manage 86.1 K 2022-03-09 - 14:48 PawelKopciewicz  
PNGpng tp1.png manage 14.6 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng tp2.png manage 14.9 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng tpgain.png manage 16.2 K 2022-03-08 - 17:07 PawelKopciewicz  
PNGpng trim.png manage 129.3 K 2022-03-08 - 17:09 PawelKopciewicz  
Topic revision: r16 - 2022-03-11 - PawelKopciewicz
 

TWIKI.NET
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback