Page History
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
Achim Czasch <czasch@roentdek.com>
Today, 12:57 AM
Hi Mikhail,
> Does all this means that correction can't be evaluated for QUAD-anode for file with regular events?
> Then for QUAD-anode I do not see any reason to use this library.
The library does 3 things:
a) multi-hit reconstruction
(Important if you have groups/pairs of particels with dT < 100 ns)
This algorithm works with a HEX-detectors and DLD-detectors.
But with a DLD it has much less information.
So the results will not be as good as if you had used a HEX.
b) position dependent correction of the time sums:
This correction is used by the multi-hit reconstruction algorithm.
Sometimes it must reconstruct a missing MCP signal
by using the info from the 4 anode signals. For this it uses the time sums.
So it is a good idea to use the time sum correction. You will end up with
a more accurate TOF for reconstructed MCP-signals.
This correction is possible with a HEX-detectors and DLD-detectors.
c) position dependent correction of the image non-linearity:
This correction is only possible with a HEX-detector.
So the library does a,b,c if you use a HEX and a,b if you use a DLD.
=================================
> However, I had an impression that a couple of correlation plots,
> t1+t2 vs t1-t2 for u and v (x and y) can be used for calibration purpose to bring time sum to constant...
Yes. This is correction 'b'.
It works for DLD and for HEX.
But the correction tables that you get from this calibration can only
be used for the correction of the time sums.
It can not be used for the linearity correction.
The linearity correction produces completely different tables.
In a way you could say that the 2 corrections are orthogonal to each other.
=================================
> Method create_calibration_tables from sort.cpp crashes in case of QUAD-anode, in case of command=3.
> The lines which crash it:
> number_of_columns = sorter->sum_walk_calibrator->sumw_profile->number_of_columns;
sorter->sum_walk_calibrator->sumw_profile
does not exist if you use a DLD
only
sorter->sum_walk_calibrator->sumu
and
sorter->sum_walk_calibrator->sumv
exist.
=================================
> If I fix these lines like:
> number_of_columns = (sorter->use_HEX) ? sorter->sum_walk_calibrator->sumw_profile->number_of_columns : 0;
> the file is saved as
> --------------
> 49 // number of sum calibration points for layer U
> -101 1.10861
> -96.7917 0.857992
> -92.5833 0.607369
> -88.375 1.11123
> -84.1667 1.11032
> -79.9583 1.10941
> -75.75 1.10849
> ...
> 49 // number of sum calibration points for layer V
> -101 1.57853
> -96.7917 1.57853
> -92.5833 1.57853
> -88.375 1.67824
> -84.1667 1.77794
> -79.9583 1.87764
> -75.75 1.97735
> -71.5417 2.07705
> ...
> 0 // number of sum calibration points for layer W (only needed for HEX-detectors)
> 0 // number of pos-calibration points for layer U
> 0 // number of pos-calibration points for layer V
> 0 // number of pos-calibration points for layer W (only needed for HEX-detectors)
> --------------
> with non-uniform corrections for layer U and V.
> Does it make any sense to use this file for QUAD-anode?
Yes, this is correct. This is how it should look like.
Achim |
| Code Block | ||||
|---|---|---|---|---|
| ||||
Achim Czasch <czasch@roentdek.com>
Fri 8/23, 12:05 AMDubrovin, Mikhail
Hi Mikhail,
> I hope they are backward compatible.
You might need some syntax changes on 1 or 2 lines.
But no other big changes.
Just send me the code where you see compiler errors.
> Is it possible to say what has been changed?
Some bugfixes and other improvements.
I recommend the upgrade.
I don't which version you use.
I can send you the list of changes if you tell me your current version number.
> Could you please tell me, what is the gcc compiler version for these files?
The files that I sent to you were compiled with gcc 4.8.5 20150623.
Today I will upgrade my gcc. Then I could send you a new compiled version
if it turns out that you need it.
> If I understood correctly, both waveform-processing algorithm would not work well for strongly overlapped signals.
Yes. Analyzing (de-convoluting) overlapping pulses is extremely difficult.
The problem here is the fact that the shape of the signals is a function
of the position on the detector where they were generated.
So if you want to do a deconvolution using a standard minimization algorithm
you don't know which shape to feed in (because at this point you don't know
where the signal was generated).
We have done this here in our group. But only as part of PhD-projects
where the student develops a very personal relationship with his/hers data set.
We have not yet found a way to write an algorithm that can do that with all data
sets without extensive guidance from the user.
Achim |
References to download software:
...
Overview
Content Tools