I am analysing data with this version and if I use TRestRawSignalChannelActivityProcess, it removes all the signals, so my events are empty. This shouldn’t happen, and it was working fine with former versions.
Checking the process I saw that in TRestRawSignalChannelActivityProcess::Initialize (link here) we have fSignalEvent = new TRestRawSignalEvent(). However, in TRestRawSignalAnalysisProcess (here) it is fSignalEvent = NULL. So I tried setting it to NULL but it still doesn’t work.
I had the idea to add the process TRestRawSignalChannelActivityProcess to the validation pipeline, inside the trexdm data processing chain. So that the problem shows on the main validation line.
In principle this process does nothing to the event data, and if we printout the event just before return fSignalEvent, the event data seems to be there, as expected.
However, as @CMargalejo mentions, when accessing the ROOT file, the events are empty, with no signals. @CMargalejo was using that process on a previous version of 2.2.X, without problems.
No, it is not posible, the TREX-DM pipeline fails after adding the TRestRawSignalChannelActivityProcess to the processing chain, I added it at one of the latest commits.
The commit:
The pipeline execution output:
Kaixiang must be right now on Chinese holidays. @nkx Happy New Lunar Year!
I have looked into TRestRawSignalChannelActivityProcess and find the problem. It is because we didn’t update the class data member fSignalEvent in ProcessEvent(). Instead, we use a temporal fSignalEvent inside the method. This makes REST wrongly determine the output event at the stage of test run(In test run, it uses TRestEventProcess::GetOutputEvent() to get output event, so the determined output event is TRestRawSignalChannelActivityProcess::fSignalEvent, but the actual used event is the returned event of TRestRawSignalChannelActivityProcess::ProcessEvent()). Then the created event tree is also with wrong event.
I have updated both the code of TRestRawSignalChannelActivityProcess and TRestThread to fix this problem.
This check would be too strict, I guess. I prefer doing the check at TRestThread, and just prompt a warning if the returned value is different in GetOutputEvent() and ProcessEvent()
Right. Otherwise there will be memory leak, the newed event can never be deleted. Still it is not a big problem. Each process will produce just one “lost” event, it is not a big leak.
