Opened 10 years ago
Closed 10 years ago
#9 closed enhancement (fixed)
Fix time offsets in between the pixels
Reported by: | smueller | Owned by: | smueller |
---|---|---|---|
Priority: | major | Milestone: | milestone: |
Component: | component1 | Version: | |
Keywords: | offset time muon | Cc: |
Description
There seems to be a fix temporal offset in between our pixels. The offset is in the order of approx 1/10ns up to 1ns. It was found by Dominik Neise using muon data processed by Max Noethe.
In the branch r18001 we try to implement those offsets to improve the data Monte Carlo agreement.
Attachments (8)
Change History (12)
comment:1 by , 10 years ago
by , 10 years ago
Attachment: | first_144_pixles_without_offsets.png added |
---|
by , 10 years ago
Attachment: | first_144_pixles_without_offsets_zoom.png added |
---|
by , 10 years ago
Attachment: | first_144_pixles_with_offsets.png added |
---|
by , 10 years ago
Attachment: | first_144_pixles_with_offsets_zoom.png added |
---|
by , 10 years ago
Attachment: | HistoDelays.pdf added |
---|
by , 10 years ago
Attachment: | DelaysCameraView.pdf added |
---|
by , 10 years ago
Attachment: | Histo_StdDevTime6.pdf added |
---|
by , 10 years ago
Attachment: | PerPixelDelays.pdf added |
---|
comment:2 by , 10 years ago
This is an Email from Max Noethe:
Hello,
As the delays are relative delays between the pixels, one cannot say that one pixel has no delay.
In the moment the delays are normalised so that the mean is zero. But that is an arbitrary choice.
Calculating the delays for single days is impossible because of low statistics. (You need several thousand muon events).
The delays were calculated with the method developed by Dominik, it involves solving a rather big linear equation system in which the entries are the time differences between two pixels of a muon ring.
Please see our git-repo for details: https://bitbucket.org/dneise/time_mismatch
The input data are 180 hours of data (all files with datacheck that were in Dortmund) processed with facttools. At this time only a fifth of the data is processed. The rest should be done by next week.
Pixels of the same patch don't have the same delays but one can see structures in the patches, see plots below.
Please note that at this points these delays are still preliminary. As only a fifth of the data is processed, we have low statistics (only 4300 Muon Events for the calculation) and we don't now any information about 12 pixels. But this should be resolved with the rest of the data being processed.
cheers,
Max
Preliminary Plots:
- Histogram of the delays in slices
- Delays per pixel
- Camera View (The black ones are the unknown pixels)
- Standard Deviation of Arrival Time in Muon Events.
- Blue: data without drs time calibration
- Green: data with drs time calibration
- Black: data with drstime calibration and delay correction
- Red: muon monte carlo events
comment:3 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
comment:4 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
The fix temporal offsets in between the camera pixels can now be simulated and defined in a text file since r18009. A class called
MMatrix
was added to store floating point number matrices (more precise vectors of vectors of doubles). It has a delimiter separated text file parser to access the data.The pixel delays are stored in such a generic
MMatrix
. In the configuration fileceres.rc
is a key value pair defining the path to the text file holding the delays.One is holding measured delays and the other one, which is the default now, is holding only zero delays to reproduce the behaviour of before this feature.
The new key value pair must be specified in the
ceres.rc
file.