VELO commissioning software / software commissioning

This is the coordination page for software activities related to the VELO commissioning. I've tried list all the related topics, but if you come up with something more please add it.

Can the people who have worked on the different topics please fill in links for talks and other relevant documentation in the fields below!

Each topic has a priority indicator:

no star This is a long term project.
Must be done.
This is crucial for the commissioning.

I've put "preliminary" priority levels on all topics at the moment, they are of course open to discussion.

Update history

  • 12/12-2007. Updates to item descriptions and status (Aras Papadelis)
  • 4/10-2007, TELL1 meeting. Updates made to the topics that were discussed. (Aras Papadelis)
  • 2/10-2007, TWiki page created (Aras Papadelis)

-- ArasPapadelis - 04 Oct 2007

Handy links

The VELO software commissioning meeting 30 March 2007

TELL1 algorithms

Download Guido's thesis with info about all the TELL1 algorithms.

Header correction

To do:
  • To compare the header correction on TELL1 and emulation one can take data with a TELL1 only, with a generated "cluster" on the first and second channel of each link. Take data with and without header correction. For the correction: set the 8 header correction values to different values and take take data with header correction on. Then compare this to the emulation. This should be straightforward.
  • Next step is to calibrate the headers with noise data/tp data from different modules.
People involved: Karol Hennessy, Tomasz Szumlak with students. Status: Implemented in emulation and on Tell1 board. Under testing.
Links: Karol's analysis talk The header correction Doxygen documentation  
Description: To correct for cross-talk from the header bits to the first two channels of each analog link, a header correction is done by the TELL1.
It's very simple: 8 values in total per sensor are allowed at the moment. 4 for channel 0 and 4 for channel 1 in a Beetle analog link. The 4 different values are for the header combinations 00, 01, 10 and 11. The correction value is subtracted from the ADC value (negative correction values mean addition)

FIR correction

To do:
  • We have four scenarios at the moment, in increasing order of complexity:
    • 5 coefficients (2 forward/2 backward channels) for the entire sensor
    • 5 coefficients (2 forward/2 backward channels) per link
    • 5 coefficients (2 forward/2 backward channels) per channel.
    • 9 coefficients (4 forward/4 backward channels) per channel.
  • Jeremie will investigate the performance of these 4 and report back in a VELO meeting.
  • UPDATE 12/12-07
    • Jeremie pointed out in his talk from 12/10 Velo meeting, a 5 or 3 coefficient per link FIR correction is the most sensible.
    • FIR coeff calulation tools released in Vetra v5r1.
People involved: Jeremie, Lars, Kazu , Seb Status: Work ongoing...
Description: To correct for cross talk we will be using a so called FIR-filter. The filter needs N coefficients, where N depends on how many channels away from the signal channel we want to correct.
It has been shown that the cross-talk correction improves the overall performance of the detector. An open question is how many coefficients do we need to get a performance improvement.
There is also the issue whether the FIR correction should be run before or after pedestal subtraction. The consensus from the TELL1 meeting 04/10/07 was that it makes the most sense to run the FIR filter after pedestal correction.

Pedestal following/subtraction

To do:
  • Before we have reached stable operation we want to keep things simple and transparent. Therefore it is not desirable to have pedestal following turned on all the time. The problem is however that we don't want to reconfigure the TELL1 configuration during a run. We have 2 main alternatives to decide upon:
    • Take a dedicated calibration run with pedestal following before the physics run. Then turn pedestal following off and use the converged pedestals for the physics run. This eliminates the need of reading out the pedestal bank during the run. This needs to be automated in a PVSS recipe.
    • Start the run with fixed pedestals from the last run. Run the emulator with pedestal following on the NZS data that is collected during that run and then apply those values for the next run. In this way we never need to "worry" about turning the pedestal following on and off.
People involved: Tomasz, ... Status: More or less finished. Still some decisions to take.
Description: The pedestal following is designed like a low-pass filter and it needs to be trained for O(1000) events before the pedestals are stable.
To ensure a bit-perfect TELL1 emulation the pedestal following should not be turned on constantly but only for N events, maybe at the start of each run. This has to be decided upon.

Linear common mode correction (LCMC)

To do:
  • Do we want to run the LCMC both before and after reording? There are not resources to do it both before and after.
    Update 12/12-07: With the new noise tool and the noise monitor (VeloDataMonitor, from Vetra v5r1) it is straight-forward and easy to make this comparison.
  • Tomasz will run a simulation to investigate this.
People involved: Torkjell, Tomasz, ... Status: ?
Description: The linear common mode suppression corrects for low-frequency "common mode" noise pickup. The correction is calculated on an event-by-event basis and applied to a full analog link.

Reordering and dummy strips

To do:  
People involved: Malcolm, Tomasz, Aras ... Status: The reodering works.
Description: The reordering from Beetle channels to strip channels needs the introduction of dummy strips in the PP-FPGA processing. The dummy strips are masked to make sure that they don't influence the the common mode correction and clustering.

Cluster maker

Cluster maker

To do:
  • There are some problems where strips are excluded from the clustering on the TELL1 but the emulator finds them. Tomasz will work this out with Guido. THIS BUG HAS BEEN SOLVED
  • Kurt will change the position decoding to conform with the cluster maker.
People involved: Tomasz, Aras, Malcolm , Guido Status: Almost finished but some discrepancies remain.
Links: EDMS note Clustering
EDMS note cluster format
Description: The cluster maker...

Seed and low thresholds

To do:
  • Guido will implement a low threshold for individual strips. At the moment channels on the same processing channel share low threshold. The sum threshold will stay as it is, one per processing channel.
  • Torkjell had some problems with setting the thresholds for some channels. This needs be further investigation. THIS BUG HAS BEEN SOLVED. TO BE VALIDATED BY TORKJELL.
  • The analysis+setting of thresholds must be automated.
People involved: Torkjell, Malcolm Status: Lots of work done, but some problems remain
Links: Torkjell's talk from 070907    
Description: On a strip by strip basis, find a seed threshold and a low threshold.

Parameter scans

Delay scans

To do:
  • To avoid synchronization problems we should avoid using the event number as a time stampt, instead we should pursue the option of alternative time stamps, like the run number or the use of a spare word in the ODIN bank. This has to cleared with the online group (Richard Jacobsson and Clara Gaspar)
    UPDATE: v3 of the ODIN bank contains new space for storing a step number. Will make our life much easier.

  • Olaf has written some software for the analysis.
    UPDATE 12/12-07: The analysis software has not been rewritten yet, but successful datataking and analysis in the pit has been done.
People involved: Olaf, Torkjell, Aras(?) Status: Software implementation lacking
Links: Olaf's time alignment talk    
Description: Find the optimal delay point for each of the many delays from the Beetle to the event builder. A big topic.
These analyses are done with delay scans where the delay is gradually changed for N consecutive events. By time stamping the events and studying signal vs time one can find the proper delay settings.

Beetle parameter scans

To do:
  • This certainly has to be monitored on the long term when the detector gets radiation damage, but it is not obvious at this point that we can't use the "standard" settings that we've used for the past three testbeams.
People involved: Kazu, ... Status: ...
Links: Kazu's pulse shape talk    
Description: By changing the Beetle settings we can tune things like the rise-time, pulse heigt (S/N), spill-over and undershoot.

HV scans

To do:
  • This will become increasingly important as the sensors get radiation damage, but is necessary for the commissioning?
People involved: - Status: long term
Description: By increasing the HV on the sensor step by step one can find the bias where the sensor charge collection efficiency has reached a plateau.

Eta parameter scans

To do:
  • We can't get the actual parameters of the eta correction until we have collected some beam data. What we can do however is to write a calibration program that collects data and splits into datasets depending on track angle and pitch. Then each of these datasets are fitted with a polynomial and the correction parameters are put into the configuration database where they can be accessed by the cluster position tool.
  • For an actual implementation of the correction, an iterative approach is needed where the first iteration gives a track angle and a pitch for each cluster and the second iteration uses the cluster position tool to update the cluster positions and then refits the tracks. When do we do this? Do we have time during reconstruction? This needs to be discussed with the appropriate people (tracking group, commissioning coordinator, physics software coordinator).
People involved: A full time master student? Status: Software to be developed. Correction procedure to be defined.
Description: By correcting for the non-linearity of the charge sharing we can increase resolution drastically, as shown by Thijs Versloot and others.
The cluster position tool is in place and prepared to do the correction, if it gets the proper parameters.

Sensor Efficiency/Occupancy plots

To do:
  • Both JC and Barbara Millan (summer student) have worked on this. What is needed now is an automated procedure to produce the plots for all sensors.
People involved: JC Status: Automation needed.
Description: With this study we can find the optimal clustering thresholds.

Gain correction/calibration

To do:  
People involved: Chris, ... Status: ...
Description: Chris, please write something here...


Monitoring Wish List

Online histogram presenter, histogram database

To do:
  • Our monitoring software has to be slightly modified in order to publish its histograms on a DIM server. We showed already in the ACDC3 test beam that we are capabla of this. Since then project has been in a development phase but as soon as it is stabilizing we can start working on it at our end.
People involved: Peter Samogyi (online group), Aras ... Status: The online group is working on it...
Links: A talk by Peter Samogyi about the online presenter    
Description: The online group are developing an online presenter that communicates with GaudiOnline jobs through the DIM-protocol and shows histograms and counters in real time. The histogram database contains a list of all histograms that the shifter's should be able to see. It has a web based interface and connects to the online presenter.
If we can get this to work with our monitoring software it can become an extremely handy tool during commissioning

High Level Monitoring (clusters, tracks)

To do:
  • In order to work with the online presenter, some modifications still have to be done. Except that, no big changes are expected for now.
People involved: Aras Status: Software exists and is being used.
Description: The VeloClusterDataMonitor and VeloTrackDataMonitor packages contain all kinds of histrograms for cluster and track monitoring.

Low Level Monitoring (noise, common mode pickup, etc)

To do:
  • Complete rewrite of the low level data monitor has been done by Aras and Vanya.
  • Abdi is converting assembly lab macros to python.
People involved: Aras, Torkjell, Vanya, Abdi Status: Almost finished...
Description: The low level monitoring package should use the output from the TELL1 emulator and produce plots on noise, common mode pick-up, cross-talk etc...

Monitoring on the credit card PC.

To do:
  • Reading out the ADC memory bank at the same time as the processing causes problems. Therefore we leave the credit card PC alone for the time being.
People involved: - Status: Project has been binned for the moment
Description: The CCPC has resources to perform simple counting and histogramming on the NZS data. It has direct access to the tell1 memory. Some kind of noise calculation can be carried out on it for example.

The VELO HLT alley

To do:  
People involved: Malcolm Status: Ongoing
Description: A special trigger alley is needed for the closing of the VELO.
Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r10 - 2008-03-13 - KurtRinnert
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

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