TRestRawVetoAnalysisProcess not working in v2.2.13_dev

CMargalejo · November 20, 2019, 5:22pm

REST version : v2.2.13
REST commit : a6ee9e11

Hello,
After moving to v2.2.13, the new process TRestRawVetoAnalysisProcess is not working properly. From the two observables, the maximum peak time bin is always 0, and the amplitude of the maximum peak is many times negative.

I attach the .rml file I’m using and the relevant .xml files
run.xml (857 Bytes) globals.xml (1.6 KB) rawToSignal.rml (4.8 KB)

I also attach the output of restManager PrintMetadata outputFile.root. PrintMetadata_output.txt (18.1 KB)

Finally, the output of PrintTrees outputFile.root is:

Any ideas?

Regards,
Cristina.

jgalan · November 21, 2019, 8:49am

Hi Cristina,

I am a bit surprised that your veto observables come after the sAna observables.

Inside your PrintMetadata_output.txt your baseline definition goes in the range from (20,200). Perhaps it is too large?

To try to understand if the values found for PeakTime and MaxPeakAmplitude are reasonable, could you plot the event and share it in the forum?

restRoot file.root
run0->GetEventWithID(1)
TCanvas c;
ev0->DrawEvent();

Also, try to get some output from TRestRawSignal::GetMaxPeakBin to check the values of the range are properly assigned.

CMargalejo · November 21, 2019, 10:38am

The baseline is large in order to comupte the energy threshold in the analysis process. I’m using the same it was used in IAXO-D0, but I think I can reduce it a little bit if necessary.

The veto baseline range is (10,100). I don´t know why it doesn’t appear in the metadata (it did in V2.2.12).

The event is:

To get the value of MaxPeakBin I may be doing something wrong because I get a segmentation violation. This is what I’m doing:

TFile *f = new TFile(“file.root”)
TRestRawSignal s =(TRestRawSignal)f->Get(“sAna”)
s->GetMaxPeakBin()

CMargalejo · November 21, 2019, 10:46am

Probably this gives you the information you want. It’s the output from run0->GetEventWithID(1)->PrintEvent(). I only include the data regarding the muon veto peak: PrintEvent.txt (1.1 KB)

jgalan · November 21, 2019, 10:50am

If you want to read the event data, and get the calculations manually, you may do something as this

Open the file containing the TRestRawSignalEvent.

restRoot file.root
run0->GetEventWithID(1)

First, check the return value is true

ev0->signalIDExists(4322)

Then, get a pointer to the corresponding signal

TRestRawSignal *sgnl = ev0->GetSignalById(4322)

Then, you need to define the baseline and range.

sgnl->SetBaseLineRange(20,200);
sgnl->SetRange(200,500);

And then get the values of MaxPeakBin

sgnl->GetMaxPeakBin( )
sgnl->GetMaxPeakValue( )

jgalan · November 21, 2019, 10:52am

Be careful, you need to create a ROOT file without the Veto process, because the Veto process will remove this signal from the event data.

jgalan · November 21, 2019, 10:54am

After executing new TFile you may use command .ls to get a list with the contents inside the ROOT file.

sAna is not in the list, we do not directly store a TRestRawSignal object named sAna. Thats why when you do TRestRawSignal s =(TRestRawSignal )f->Get(“sAna”) you will get a NULL pointer, and in the next call s->GetMaxPeakBin() you get a segmentation fault.

jgalan · November 21, 2019, 11:30am

You should push that change to the v2.2.13_dev branch. Probably it was a change you introduced only locally.

You must be already at v2.2.13_dev because you are at the latest commit a6ee9e11, but just make sure using git status.

CMargalejo · November 21, 2019, 1:58pm

I did it before reading this post and the signalID exists, so I suppose it’s not being removed. I did it also without the veto process just to test it and I got the same result:

sgnl->GetMaxPeakBin()
(int) 263
sgnl->GetMaxPeakValue()
(double) 1545

jgalan · November 21, 2019, 3:10pm

Ok, I identified a couple of errors that have been already fixed and committed to branch v2.2.13_dev.

One error was affecting the range definition in TRestRawSignalEvent::SetRange.

The other was affecting to the RemoveSignalWithId method. The call to this method was not removing the right signal id. After the fix, the veto signal will not be there.

These errors were always present, so it is imposible the problem was not there in v2.2.12. Check fixes at https://lfna.unizar.es/ commits.

CMargalejo · November 22, 2019, 9:47am

Hi Javier,

The veto process now works, thank you!

However, all the obervables from TRestTrackAnalysisProcess are now either 0 or 6.91984e-310. I think this has happened before, but I don’t remember how it was solved. I’ve been playing around but I haven’t been able to fix it myself.

jgalan · November 22, 2019, 10:08am

It is really all the observables? How are you defining that on the RML? Please, share also the result from restManager PrintTrees file.root

Not sure if it comes from here, but may be related to the fact that we call SetObservableValue after a return NULL, from a previous post with @nkx I believe we should avoid to do this in a process? This is a bit dangerous in fact.

@CMargalejo Do you have fEnableCuts true? I believe in a future we should also avoid applying this kind of filters and separate that to dedicated processes.

CMargalejo · November 22, 2019, 11:50am

I attach the output: PrintTrees.txt (4.9 KB)
The RMLs I’ve used are SignalToTrackCAST.rml (3.7 KB) and processes.rml (22.2 KB)

I’ve checked and it’s set to false.

jgalan · November 22, 2019, 12:12pm

hitsAna is also affected, does it help if you remove/comment out your hitsAna observables and add observables="all" in your process definition?

<TRestHitsAnalysisProcess name="hitsAna" title="Hits analysis template" verboseLevel="silent" observable="all">

@nkx Perhaps this is related to the fact the it is being processes in two phases? Launching the processing executing two RMLs, one after the other.

CMargalejo · November 22, 2019, 12:43pm

Yes, if I do that in TRestHitsAnalysisProcess it solves the hits analysis part, although the hits related observables in the tree now appear after the track observables! PrintTreesHitsObservablesALL.txt (4.8 KB)

If I also set observables="all" in TRestTrackAnalysisProcess, this also solves the track observables. I still have some 0 but it looks much better. Now, the observables appear in the right order. PrintTreesHits&TrackObservablesALL.txt (5.6 KB)

The veto observables should be the first but they still appear after sAna in every case.

nkx · November 22, 2019, 4:24pm

I remember a previous bug that all the manual observables (specified in the rml) are in error value, while the automatic observables (set with observable="all" option) are correct. This bug was solved previously. Can you try with the latest commit on v2.2.13_dev?

For the problem of observable sequence, It is actually not a bug. It is because that all the manual observables are added before automatic observables. This related to the observable adding logic, and I think it is normal.

CMargalejo · November 22, 2019, 4:41pm

I am on the latest commit (9091c350). When I started the thread I was not, that’s why a different commit is written there.

OK, I understand now, thanks!

jgalan · November 22, 2019, 8:11pm

So, I dont understand, it is the problem solved after moving to the latest commit?

CMargalejo · November 23, 2019, 8:28am

No, it’s not solved. I moved to the latest commit to solve the veto issues that @jgalan fixed. This was solved but as I added new processes I found this manual obsevables problem.

So all my posts about this second problem are in the latest commit.

Sorry, I know it’s a bit confusing, maybe I should have started a different thread for the observables problem.

jgalan · November 25, 2019, 6:39pm

Yes, probably is better if you open a new topic, describing accurately what are the observables that are affected, i.e. those giving not appropriate values.

Try to go step by step. First check, which HitsAnalysis observables are not giving the right values?