1

Summary: TTree branches seem to go missing when running the uproot tutorial.

I have a root file that contains a TTree called 'prod' which has a complicated set of jagged leaves and branches which I can see in the TBrowser in ROOT. I started the uproot tutorial using this root file as the input and receive the following error at the beginning of an interactive session:

>>>import uproot as up
>>> file = up.open('small.root')
>>> file
<ROOTDirectory b'small.root' at 0x025b5e3477c0>
>>> file.keys()
[b'prod;1']
>>> file.classnames()
Traceback (most recent call last):
  File "<pyshell#13>", line 1, in <module>
    file.classnames()
AttributeError: 'ROOTDirectory' object has no attribute 'classnames'
>>> file['prod']
<TTree b'prod' at 0x025b5dd15d00>

Why am I getting an error when trying to get the class names?

Ignoring this and moving on. The next problem is when I try to see what is in the TTree prod

>>> tree = file['prod']
>>> tree.keys()
[b'COSMIC', b'COSMICRES', b'COTNBC', b'COTTIME', b'GLB', b'LUM', b'MET', b'MU', b'PHOTON', b'RESIDUALS', b'TRACK', b'TRKDET', b'VERTEX', b'ZVTX', b'MOM_ntk', b'MOM_pt', b'MOM_px', b'MOM_py', b'MOM_pz']
>>> branches = tree.arrays(namedecode='utf-8')
>>> branches.keys()
dict_keys(['MET', 'MOM_ntk', 'MOM_pt', 'MOM_px', 'MOM_py', 'MOM_pz'])

The uproot tutorial implies that I should get all the branches, but clearly I am missing quite a few of them. In particular, the only branches that were transferred over were the ones that were what I would call 'simple' in the sense that they only had numerical data members.

The other branches contain further items within them. For example, the 'MU' branch has properties of every muon in the event. First the number of such muons and then a further branch of each one of those muon's attributes like it's quality and the track-number associated with it. 'MET', 'MOM_ntk', 'MOM_pt', 'MOM_px', 'MOM_py', and 'MOM_pz' all contain only lists of floating point numbers. MOM_ntk has only one number per event (call it 'alpha'), and the other MOM branches will have 'alpha' numbers in each of them.

The file only has 1000 events and is only about 5MB in total size.

I am wondering where all the other Branches have gone! Where are my friends 'COTNBC' or 'GLB' (that one should have all the run and event numbers in it).

Any advice or help would be appreciated!


Windows 10 PC with 32GB RAM Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz x64 processor

1 Answers1

0

Based on what you're trying to do and the outputs you're getting, it looks like you're expecting Uproot 4, but you have Uproot 3. Until Uproot 4 has feature-parity with Uproot 3, it will be in a package named uproot4 (pip install uproot4 and import uproot4). That lets you use both during this transition.

One of those differences is that Uproot 3's keys() methods did not recurse through subbranches of branches, but Uproot 4's does. (There's a recurse=True/False parameter in both, but the default changed for exactly the reason you're seeing.)

The name change (uproot4uproot and uprootuproot3) will happen before the end of the year. Uproot 4 only needs file-writing before that can happen.

Jim Pivarski
  • 5,568
  • 2
  • 35
  • 47
  • Are you aware of any issues with uproot4 and root files that were made with versions of root older than version 6.0? This particular file was made in ROOT 5.34. – physicscitizen Oct 16 '20 at 14:38
  • uproot4 makes the `file.classnames()` method work on this root file. One needs to also import awkward1 as well to work with uproot4. (Just stating this in case anyone else reads this.) But I encounter (maybe) a new problem. – physicscitizen Oct 16 '20 at 15:34
  • In fact I still have the problem where the more complex tree.keys() like 'MU' appear un-readable as branches. Even with uproot4 and awkward1. – physicscitizen Oct 16 '20 at 15:45
  • Uproot tests (3 and 4) include ROOT files made with 5.23/02, 5.24/00, 5.25/02, 5.26/00, 5.27/02, 5.28/00, 5.29/02, 5.30/00, and 6.08/04 and up. I think 5.34 must have been a bug-fix release for the ROOT 5 lineage. The real issue for compatibility is the version numbers of objects in the file, but we test a contiguous series of TTree, TBranch, and TLeaf version numbers. – Jim Pivarski Oct 16 '20 at 17:55
  • Uproot 4 should be able to read a strictly larger set of data types than Uproot 3, but still there are going to be data types in C++'s type system that Uproot doesn't have a Python translation for. If by "unreadable" you mean there's an UnknownInterpretation exception, then that's what that is. You could request it as a feature on GitHub Issues and include an example file. A strong motivator in that is whether it is strictly required for getting your work done and whether it can be made readable simply by writing the branch in "split" mode. You might find other examples on GitHub Issues. – Jim Pivarski Oct 16 '20 at 17:59
  • This particular data is used in an undergraduate lab. We are able to get along using purely the C++ ROOT framework, but we decided this year we would try to make a more fully 'pythonic' version of the lab. Since this is old CDF data it's not likely we are going to be able to re-run the data structure. I think we are stuck with the structure we have. I will try to find the GitHub area and raise the issue and see if there's interest. We will survive if this isn't solved in quick order. – physicscitizen Oct 17 '20 at 11:21
  • what is the status of uproot 4 now? Is it worth my giving this another go? – physicscitizen Apr 18 '22 at 07:45