There is a migration from pure signal processes that operated in TRestSignalEvent, that will operate now in TRestRawSignalEvent. Probably, some of the processes that work on TRestSignalEvent may become obsolete soon. I.e. makes no sense to do an FFT at a TRestSignalEvent level.
Processes involved in the chain that may need crosscheck (i.e. to be compared with the ones in V2.2).
TRestHitsToSignalProcess
TRestSignalToHitsProcess
TRestSignalZeroSuppresionProcess (This process needs the sampling as input now)
We may set a common knowledge of the difference between TRestSignalEvent and TRestRawSignalEvent. I am still a little confused about it. The description shall also be added in the class documentation.
A TRestSignalEvent contains an arbitrary set of (t_i, d_i) values. The main purpose of this type is to serve on the event reconstruction using a TRestReadout. TRestHitsEvent <–> TRestSignalEvent. It might serve to apply zero reduction on a TRestRawSignalEvent. A TRestSignalEvent contains a time component measured in physical units, microseconds.
A TRestRawSignalEvent contains a fixed array with N data points d_i. It is more connected to the acquisition electronics. Since it contains a format more similar to the binary data extracted from a detector. Processes related to this type are those connected with extracting data from a binary data file and writing it to a TRestRawSignalEvent, and those processes that serve for signal conditioning; signal unconvolution, adding noise to signal, processes that need usually FFT methods.
It is true that a proper documentation needs yet to be written. But the description on the paper, and the name of the process should be indicative of what it does. If there is any doubt in any process we can raise the discussion here.
A proper documented process should contain if possible:
Two plots, with the input and output event result.
An example of documented process embedding an image is here.
Coming back to the topic of the thread. I think those processes are already updated in V2.2. But just in case is to make people to be aware, and open their eyes when using them.
We will have a meeting soon to discuss these issues, between others.
But I see in TRestHitsToSignalProcess in v2.1.7, the time information is dispersed by fSampling. So TRestSignalEvent looks also DAQ related, which confused me. The only difference is their physical unit of time?
Probably, by dispersed you want to mean discretised?
Yes, TRestHitsToSignalProcess adds a sampling value in Z. This is in general advantageous, because it reduces the size of the final TRestSignalEvent. For example, if you have a million hits, and do not discretise you will end up with a lot of data points on the final TRestSignalEvent.
Since, when transferring from TRestHitsEvent to TRestSignalEvent there is an implicit discretisation in XY given by the TRestReadout granularity, it makes it not very strange to do in a similar way with the Z-coordinate.
Notice that the sampling introduced here might be, or not, related to the electronics samples.
The physics unit of time is an important difference. But another is the fact that in TRestRawSignalEvent the points are always equidistant, while in TRestSignalEvent the time distance between 2 consecutive times is not fixed.
In other words, fSampling is used in TRestHitsToSignalProcess just to be able to integrate the resulting charge. If there is no charge present at the corresponding bin, there will be a gap. While in TRestRawSignalEvent there will be zeros.
Of course, you may chose as fSampling a parameter fine (small) enough to do not loss detail. But we might have an option fSampling=0 to just do not apply any sampling. In case this is needed. I find advantageous that 2 hits which are close in Z and drop in the same channel are integrated in the same (t_i,d_i).