TWiki> LHCb Web>LHCbVELO>VELOCommissioningSoftware (revision 7)EditAttachPDF

VELO commissioning software

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:

Symbol
Priority/Status
no star
This is a long term project.

Must be done.
This is crucial for the commissioning.
Finished

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

Update history

  • 4/10-2007, TELL1 meeting. Updates made to the topics that were discussed.
  • 2/10-2007, TWiki page created

-- 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, Glasgow master students?
Status: Implemented in emulation and on Tell1 board. Tested?
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.
People involved:
Jeremie, Lars, Kazu , Seb
Status: Work ongoing...
Links:


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.
Links:


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.
  • Tomasz will run a simulation to investigate this.
People involved:
Torkjell, Tomasz, ...
Status: ?
Links:


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.
Links:


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.
  • 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.
  • 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)
  • Olaf has written some software for the analysis. We need to take data now!
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
Links:


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.
Links:


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.
Links:


Description: With this study we can find the optimal clustering thresholds.

Gain correction/calibration

To do:
People involved:
Chris, ...
Status: ...
Links:


Description: Chris, please write something here...

Monitoring

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.
  • Some changes to the Cluster Position Tool interface requires some changes in the monitoring algorithms.
People involved:
Aras
Status: Software exists and is being used.
Links:


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:
  • Torkjell has converted the VeloFullDataMonitor package from the "assembly lab style" noise and pedestal calculation to using the output of the emulator. However, the package is still organized in an akward way, where one has to run a separate instance of the monitoring algorithm for each TELL1. The software needs to be rewritten to automatically work with all TELL1s but the option can be kept to only produce plots for a specific TELL1 (to save memory).
  • A new version of the interface of VeloTELL1Data requires changes to VeloFullDataMonitor.
  • Revise assembly lab macros for commissioning.
People involved:
Torkjell, ...
Status: Ongoing...
Links:


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
Links:


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
Links:


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 | Raw edit | More topic actions...
Topic revision: r7 - 2007-10-09 - ArasPapadelis
 
    • 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