rest-for-physics / rest-for-physics/detectorlib
Avoid invoking hardcoded process names when accessing analysis tree observables
@nkx111 is already working on this.
Since Apr 19, 2022.
- Dominant language
- C++
- Stars
- 2
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Description
As it was pointed out at rest-for-physics/tracklib#13 the process TRestDetectorSingleChannelAnalysisProcess access the analysis tree this way:
map<int, Double_t> sAna_max_amplitude_map =
fAnalysisTree->GetObservableValue<map<int, Double_t>>("sAna_max_amplitude_map");
map<int, Double_t> sAna_thr_integral_map =
fAnalysisTree->GetObservableValue<map<int, Double_t>>("sAna_thr_integral_map");
Double_t sAna_PeakAmplitudeIntegral =
fAnalysisTree->GetObservableValue<Double_t>("sAna_PeakAmplitudeIntegral");
Double_t sAna_ThresholdIntegral = fAnalysisTree->GetObservableValue<Double_t>("sAna_ThresholdIntegral");
Double_t sAna_NumberOfGoodSignals = fAnalysisTree->GetObservableValue<int>("sAna_NumberOfGoodSignals");
The process name sAna_ could be eventually changed by the user, or even the data processing chain could evolve and get more complex, implementing more than one TRestRawSignalAnalysisProcess.
I am not sure why this needs to be done at this process, however, being the input event a TRestDetectorSignalEvent (which still keeps the daqId value) it seems that all those map values could be directly extracted/calculated from the input event itself. Isn't? The threshold integral should usually be the same as the total integral, and the number of good signals the total number of signals at TRestDetectorSignalEvent.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.