REST version : v2.3.8
REST commit : 4ff2821d
When I include TRestRawCommonNoiseReductionProcess in the processing chain I sometimes get crashes. Two examples are in runs R10463 and R10478 available here: Index of /rawdata. There are other runs in which things work fine… I have been checking the files that crash but I haven’t been able yet to see what’s going on.
The RML I’m using is rawToSignal_debugCommonNoise.rml (5.4 KB)
Hi Cristina,
when trying to reproduce the error I get the following output message:
The lines below might hint at the cause of the crash.
You may get help by asking at the ROOT forum https://root.cern.ch/forum
Only if you are really convinced it is a bug in ROOT then please submit a
report at https://root.cern.ch/bugs Please post the ENTIRE stack trace
from above as an attachment in addition to anything else
that might help us fixing this issue.
===========================================================
#5 0x00007ff1b046a589 in TRestRawSignal::IsACDSaturation(int, int) () from /media/storage/home/jgalan/rest-framework/install/lib/libRestRaw.so
#6 0x00007ff1b046f5bf in TRestRawSignalAnalysisProcess::ProcessEvent(TRestEvent*) () from /media/storage/home/jgalan/rest-framework/install/lib/libRestRaw.so
#7 0x00007ff1ca5d3a78 in TRestThread::ProcessEvent() () from /home/jgalan/rest-framework/install/lib/libRestFramework.so
#8 0x00007ff1ca5d4988 in TRestThread::StartProcess() () from /home/jgalan/rest-framework/install/lib/libRestFramework.so
#9 0x00007ff1c7a44b2f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x00007ff1c77d0fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#11 0x00007ff1c77014cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
===========================================================
It seems it is complaining about the method TRestRawSignal::IsACDSaturation.
When producing a bit of output at that method I found out that at some point the value of GetMaxPeakBin is 480. Then, it crashes.
Bool_t TRestRawSignal::IsACDSaturation(int Nflat, int OverThres) {
// GetMaxPeakBin() will always find the first max peak bin if mulitple
// bins are in same max value.
cout << "Nflat: " << Nflat << endl;
cout << "OverThresh: " << OverThres << endl;
int index = GetMaxPeakBin();
cout << "Index: " << GetMaxPeakBin() << endl;
bool sat = true;
if (index + Nflat <= fSignalData.size()) {
for (int i = index; i < index + Nflat; i++) {
cout << "i: " << i << endl;
if (fSignalData[index + i] > OverThres && fSignalData[index] == fSignalData[index + i]) {
} else {
sat = false;
}
}
}
...
Then, inside the loop the first element is int i = index, so that inside the if comparison it is trying to access fSignalData[960] which it is likely out of range.
Not sure what it is exactly doing this method, but there is likely something wrong, @nkx?
It should probably be written as follows?
for (int i = 0; i < Nflat; i++) {
if (fSignalData[index + i] > OverThres && fSignalData[index] == fSignalData[index + i]) {
Additionaly, if index+Nflat > fSignalData.size() nothing happens. It should not just re-define the value of Nflat so that it checks the points up to fSignalData.size()?
I found that I shouldn’t be using the common noise reduction process in these files because for the process to work properly it needs the signal of all channels, but in these runs I only have the information of the channels above threshold. Thus the signals after the noise reduction are ugly, and probably this is part of the problem?
If I don’t apply this process I don’t get any crash, so that’s whay I think these kind of signals may be causing some issues.
Yes, I believe the negative signals have a GetMaxPeakBin of 480, so that in that scenario it might cause that the array at the IsACDSaturation method gets out of range. This will need correction.
Still, it is very strange how your event is changing after applying common noise reduction, why that would happen? Thew common noise reduction should improve/reduce the baseline noise letting the signals untouched.
In principle, common noise reduction should be applied only when all channels are active, it seems is not the case here? @ddiez
I believe the bug on IsACDSaturation helped you identify another problem.
Exactly. But in this case only hit channels were saved. So the process runs but the ouput makes no sense because it takes one signal, the one that we see that ends up being flat at 0 ADC, and it subtracts its value to all the signals. It was my mistake to apply it. I’m sure David can explain it better than me, but I think this is the concept,
If you have runs where events have all channels and runs where only hit channels were registered, and you want to use the same RML, perhaps it could be added a parameter that requires a minimum number of signals present in the event in order to apply the correction. So, for example, if we know that the total number of channels is 512, we apply the corrections to those events where we observe at least 500 channels.
Somehow, this would require to add a new metadata parameter at the common noise reduction process, and in case that there is less channels than the value given at this parameter, then the common noise process returns the event pointer without doing nothing.
Nice! I believe this post will resolve 2 problems!
Exactly, the process was written for events with all signals recorded. @CMargalejo explained it well, it subtracts the median value for each bin so if only good signals are recorded, half of them will be pushed downwards and the middle signal will be flat. So we have to avoid this behaviour, adding the metadata parameter as you suggested @jgalan to process all files with the same rml will be straight forward.
