Adding generic methods for signal analysis inside framework

[juanangp]

New namespace for generic signal analysis inside framework, it implements different methods:

• Different methods for baseline calculation
• Signal smoothing
• Methods for signal analysis (risetime, width, points over threshold, triple max, integral,...)
• Methods for signal fitting (gaus, landau, aget)

Related PR:

• Moving to generic methods inside TRestRawSignal rawlib#100
• Adding the possibility to perform smoothing on TRestRawToDetectorSignalProcess connectorslib#27
• Implementing generic analysis methods inside detectorlib detectorlib#75

[jgalan]

I understand it is much cleaner to create this dedicated class, however, I still believe the right place for it is at the rawlib.

Only in rawlib it will make sense to calculate baselines, or does it make sense in any other existing or future library?

Thus, I suggest to rename this class to TRestRawSignalAnalysis and place it at rawlib.

[jgalan]

If new types (other than Short_t) are introduced for rawsignals, those types should be added somehow also inside rawlib.

Please, share in case that you foresee another use-case where you will need a library for raw signal processing that it is outside rawlib.

[juanangp]

Please, share in case that you foresee another use-case where you will need a library for raw signal processing that it is outside rawlib.

I think this topic is discussed on #353.
Personally, I think that signal analysis methods should be generic and doesn´t have to be linked to any library. From my understanding rawlib holds raw signal data but it doesn't mean that all the signal processing has to be done in this library.
For instance, I was attemting to perform the analysis of the smoothed signal which was difficult with the current code design, this is actually implemented on under a related PR rest-for-physics/connectorslib#27.
In addition detectorlib currently holds several methods for signal processing, despite signal smoothing or baseline calculations, there are several methods such as GetMaxLandau(), GetMaxGauss() or GetMaxAget() that are used inside TRestDetectorSignalToHitsProcess.
On the other hand, I don't see any issue to perform the signal analysis on a ´TRestDetectorEvent´.

[juanangp]

@lobis and @jgalan can you approve or give me feedback in the related PR? I cannot merge otherwise.

• Moving to generic methods inside TRestRawSignal rawlib#100
• Adding the possibility to perform smoothing on TRestRawToDetectorSignalProcess connectorslib#27
• Implementing generic analysis methods inside detectorlib detectorlib#75

[nkx111]

If I remember correctly you cannot write the implementation of the template methods separately in the cxx file, unless you #include this cxx file like a .h file. I don't know why it works as the pipeline is green...

[juanangp]

If I remember correctly you cannot write the implementation of the template methods separately in the cxx file, unless you #include this cxx file like a .h file. I don't know why it works as the pipeline is green...

As far as I know, template specializations can be defined in the source file https://stackoverflow.com/questions/115703/storing-c-template-function-definitions-in-a-cpp-file
I think it is cleaner to do the implementation inside the source file. The code compiles and works properly.

[juanangp]

Note that the following submodule PR needs to be merged together with this one:

• Moving to generic methods inside TRestRawSignal rawlib#100
• Adding the possibility to perform smoothing on TRestRawToDetectorSignalProcess connectorslib#27
• Implementing generic analysis methods inside detectorlib detectorlib#75

[nkx111]

Could return std::vector<std::pair<Int_t, T> >?

[juanangp]

I guess this is related to rest-for-physics/rawlib#100 (comment)
I will try to implement a more generic method.