Inconsistent results with TTree::Draw()

ROOT
1

Hello,

I’m attempting to use TTree::Draw with various cuts and the results that I obtain are dependent on the ordering of the conditions. If I use:

DATA->Draw(“ThSCAT:X1pos>>hThSCATvsX1”,“ThSCAT>0 && CUTpad1pad2 && CUTpad1tof”,“col”)

I get (Long64_t)17843 entries.

If I do (changing the order of the ThSCAT from the first entry to the last entry):

DATA->Draw(“ThSCAT:X1pos>>hThSCATvsX1”,“CUTpad1pad2 && CUTpad1tof && ThSCAT>0”,“col”)

I get (Long64_t)0 entries.

CUTpad1pad2 and CUTpad1tof are both TCutGs that are loaded from external macros.

This is obviously somewhat concerning. I’ve tried to have a look at how the selection expression is compiled in TFormula.cxx and TTreeFormula.cxx but can’t find any obvious point where things go awry.

This issue exists in the 5.34 version I’m currently using but an old installation of 5.20 on one of the machines in the lab doesn’t have this issue.

I can’t find any documentation on the ROOT site which suggests that ordering of cuts is important and I can’t diagnose the problem myself so I’m posting it on here in the hopes that someone can point out what I’ve been doing wrong. It’s also possible that it has been fixed but I can’t find anything to that effect on the site.

N.B. This isn’t my code. I was asked to look into what was going wrong and, having got stuck, have come here. If there are problems with how the TTrees have been created, then I’ll need to go back to the guy who made them. Also, I’m having problems attaching files. I’ll try to give people a download link if people would like to try running examples of the code.

Many thanks.

2

Yes, that will be useful …

3

Sorry. On experiment. Chaos just broke loose.

The .tar.gz in npg.york.ac.uk/download/pa541/PR193_diagnosis/ should provide everything that you need.

Run load_and_draw.cpp to get trees and cuts loaded.

Thanks.

4

Oh… and I apparently left the runfile in rootfiles gzipped. That’ll need to be unzipped before you can run things. Sorry.

5

If I draw CUTpad1pad2 and CUTpad1tof I can see that they are completely separated from each other, they do not have any common area. So an empty histogram seems to be the right answer.

But like you I can see that changing the order gives me different results.

I will ask our TTree expert to look at it.

6

CUTpad1pad2 and CUTpad1tof are on different variables so, whilst they have no common area, there should be events which can pass both.

The spectrum produced when we use the ordering which works is consistent with what we expect, and is consistent with what we see from version 5.20.

7

Hello,

Has there been a resolution to this issue or is it still being investigated?

Thanks.

8

Our expert TTree expert is quite busy these days.
He will look at this soon.

9

OK. Thanks very much.

10

may the best is to post a JIRA ticket here:
sft.its.cern.ch/jira/browse/ROOT

to keep track…

11

[quote=“couet”]may the best is to post a JIRA ticket here:
sft.its.cern.ch/jira/browse/ROOT

to keep track…[/quote]

Done.

12

Hi,
This problem has been resolved in the master and the v5.34 patch branch (v5-34-19 and above).

See ROOT-6332

Cheers,
Philippe.