Reading Tree in PyROOT

Hi guys,

I am a beginner in writing Python in general and in the past few days I was experiencing some issues when
trying to read a TTree from a python script. Looking back at older threads and posts about this issue
I saw that there is an easy way of getting the branch info per event by simply asking for tree.branchname

However, when tried that in a loop I keep getting errors like:

which is the outcome of when trying to read per event the branch :

for event in tree: print tree.branchname

I am getting similar errors when running locally (OSX 10.9.4 + ROOT 5.34.19 + Python 2.7) or on lxplus.
The wierd thing would be that I have cross-checked my script with another user and it seems that it’s working fine for him. So I was thinking that it maybe an issue with exports?

However, I think I have all the correct exports as defined in the pyROOT documentation :

export ROOTSYS=/Users/username/root/root-v5-34-19 export PATH=$PATH:$ROOTSYS/bin export LD_LIBRARY_PATH=$ROOTSYS/lib:$PYTHONDIR/lib:$LD_LIBRARY_PATH export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:$ROOTSYS/lib export PYTHONPATH=$ROOTSYS/lib:$PYTHONPATH export PATH=${HOME}/.local/bin${PATH:+:$PATH}

And they seem to be working fine for every other use appart from reading trees (e.g. I made the file using a similar script) and it contains nothing more special than:

[code]import ROOT
f = ROOT.TFile.Open(“blah.root”, “read”)
t = f.Get(“treename”)

for event in t :
print t.branch[/code]

I do not know if anyone has encountered something similar or it is just a silly mistake from my side. Any input would be appreciated.

Hi,

to read a tree in a file from python using PyROOT bindings you can in your case simply do the following:

import ROOT
f = ROOT.TFile.Open("blah.root")
for event in f.treename :
      print event.branchName.<do something with it>

Cheers,
Danilo

Hi Danilo,

Thank you for your answer! However I get the same typerror.
The idea was simply to make a per event analysis without having all the branches/setbranchadress of the cpp implementation. Therefore, having a simple file like:

import ROOT file = ROOT.TFile.Open('vSet_board00_channel003_09_08.root', 'read') # a file for event in file.vSetInfo_b00_ch003: # loading the tree nyear = event.Year print nyear

It ends up with

user@folder: python readFile.py Traceback (most recent call last): File "readFile.py", line 21, in <module> nyear = event.Year TypeError: attempt to bind ROOT object w/o class

Apologies if I am doing something very silly… :blush:

Cheers,
Nikos

Hi Nikos,

what C++ type is “year”?
could you share your file?

Danilo

Hi Danilo,

I am sorry if I confused you. Year is just the branch name in a simple ntuple I had made (also using Python + ROOT).
What I meant is that probably it would work if I would have defined all variables, branches and made the SetBranchAddress statements as one would do when writing a C++ macro to read the tree, but I was looking for a faster (python-like way) to read the same tree.

Please find the zip file with a 12-event tree and the code from above. Nothing special.

Thanks & cheers,
Nikos

P.S. I guess there is also a way to do this using rootpy but I couldn’t find an example. It should be that trivial :frowning:
pythonRootTest.zip (6.7 KB)

Hi Nikos,

the file and script you sent me work out of the box.
I can even go through all the other branches (Second, Board…): I think something may be wrong with your root setup.

Danilo

Hi Danilo,

Thanks for checking. This is similar to what I described in the first post.

I am trying to run it using the python interpreter by :

implementing importing (Py)ROOT in the script.
I tried to check if there is any executable named pyroot or pyroot.py script.
I checked that there is the library under my $ROOTSYS/lib/libPyROOT.so
and the $ROOTSYS/lib is in the pythonpath no pyroot executable is under the $ROOTSYS/bin

To me sounds a bit wierd, since for example the root file that you checked I had made it using the same ROOT/Python setup from a txt file and run it again as :

Seems that only reading the tree this way raises errors for me.

Cheers,
Nikos

Just for reference, exactly same problem here. (Error when acessing data members of TNtuple)

Same problem here, reading a TTree from a file and accessing tree.EventNumber fails with the same error reported by Nikos:
“TypeError: attempt to bind ROOT object w/o class”

I’m using the following setup on an SLC6 machine:
% which python
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/python/2.7.3-x86_64-slc6-gcc47/sw/lcg/external/Python/2.7.3/x86_64-slc6-gcc47-opt/bin/python
% echo $ROOTSYS
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/root/5.34.19-x86_64-slc6-gcc4.7

The same calls on the same input file succeed on my macbook, slightly older ROOT version.
% python --version
Python 2.7.3 :: Anaconda 1.3.1 (x86_64)
% root-config --version
5.34/14

Please let me know if any other info is required.

Thanks and cheers, Kilian

Hi,

not sure where these use cases are coming from all of a sudden (I don’t know whether it’s due to a change in ROOT I/O or due to the way certain files are written), but the basic problem is that TBranch::GetAddress() returns null if there is a TLeaf of the same name.

This is solved in more recent versions (patch version 20, I believe).

Cheers,
Wim

Hi,
Having the same problem, all my scripts stopped working while I was forced to upgrade to a more recent root version. Using now 5,34/21. I am desparetely waiting for a solution, all analysis work stopped.
thomas

Thomas,

sorry, I’m reading two conflicting messages there … you’re using 21, which works for you, and you need a workaround for 19? Or, you’re using 21, and it does not work for you?

The change that I made was entered in 20 (I believe), but the cause of the problem is deeper in the bowels of ROOT I/O (I have not taken the time to track down where exactly). I haven’t looked into workarounds.

Cheers,
Wim

Hi Tim,
I was working with 17, no problems, worked beautifully, easy access to Tree objects. Yesterday, I had been forced to move to 19, large MC production on a different cluster, which was running 19. But these data can’t be read with 17, because of the class incombatibilities, had to move to 19 too. Then the problem started. With 21, the problem is still there.
Thomas

Thomas,

okay, do you have something that I can run to see the problem? The example code linked above by Nikos runs fine with current ROOT …

Thanks,
Wim

Hallo Wim,
I was afraid to hear this, not sure you can repeat it without the complete environment I am working in, which would mean you need access to the experiment afs pages. Anyhow, i copied a file to my public directory on afs: /afs/cern.ch/user/t/truf/public

f = ROOT.TFile(‘ship.MuonBack-TGeant4.root’)

sTree=f.cbmsim
sTree
<ROOT.TTree object (“cbmsim”) at 0x296ef60>
sTree.MCTrack
Traceback (most recent call last):
File “”, line 1, in
TypeError: attempt to bind ROOT object w/o class

cheers Thomas

Thomas,

yes, I’ll need that environment (or rather I need to have the dictionaries of the classes used). Without those, the error message is valid.

Cheers,
Wim

Dear Wim,

as I am running into the same problems, I took the liberty of preparing a minimum breaking example in

/afs/cern.ch/user/k/kbicker/public/branchProblems

execute this with

./branchProblemBreakingExample.py 1900.1960.genPS.root

gives

Traceback (most recent call last):
  File "./branchProblemBreakingExample.py", line 33, in <module>
    for particle in event.__getattr__(prodKinMomentaLeafName):
TypeError: attempt to bind ROOT object w/o class

The variable I am trying to access is a TClonesArray of TVector3, so no other stuff is involved. I am using root in /afs/cern.ch/sw/lcg/app/releases/ROOT/5.34.21/x86_64-slc6-gcc48-opt/root/bin/thisroot.sh and the standard python from lxplus (“Python 2.6.6 (r266:84292, Jan 23 2014, 10:39:35)”).

I hope you can reproduce the problem. Thank you in advance for your help!

Regards,
e_dude

Hi,

this has been fixed outside the forum with Thomas’ help. It only affects TClonesArray. Fix is in trunk. I checked that your example does indeed work with trunk. The only known workaround is to use SetBranchAddress() directly.

Cheers,
Wim

Btw., /22 is imminent.

Cheers,
Wim

Great, thanks for the update!