TPySelector usage problems

ROOT
1

Hi all,

I am trying to use a TPySelector in one of my codes and I can’t get around to make it work. What I want to to is execute a function on the selector, execute the Process function and retrieve the results. Somthing like

selector = MyPySelector()
selector.MyConfig()
tree.Process(selector)
selector.RetrieveOutput()

It doesn’t work for me:

TypeError: none of the 2 overloaded methods succeeded. Full details:
Long64_t TTree::Process(const char* filename, Option_t* option = “”, Long64_t nentries = 1000000000, Long64_t firstentry = 0) =>
could not convert argument 1 (expected string or Unicode object, Plotter found)

Plotter is derived from TPySelector. I don’t know how to fix this… Any suggestions?

Thanks,
Albert

2

Hello, Albert,

didn’t you try to leave the tree processing syntax as it is shown in the example at root page? I mean something like:

MyPySelector().MyConfig() 
tree.Process("TPySelector","FileName")
MyPySelector().RetrieveOutput()

where “FileName” is the name of the file, containing your TPySelector class. At least it works for me…

Regards, Dasha

3

Hi Dasha,

the problem is I want MyConfig to set some internal variables of the class:

[code]from ROOT import *

class Selector( TPySelector ):
def Begin( self ):
print ‘py: beginning’
def SlaveBegin( self, tree ):
print ‘py: slave beginning’
self.h = TH1F(“m12”,“m12”,100,0,250)
def MyConfig(self, coef):
“”"
Gets the current coefficient values and deletes the histograms
created during the previous iteration
“”"
self.coef=coef
def Process( self, entry ):
“”"
Fills the histograms from a tree
“”"
mytree=self.fChain
mytree.GetEntry( entry )
if((entry%1000)==0):
print ‘py: processing’, entry
print coef
self.h.Fill(coef*mytree.m12)
return 1
def SlaveTerminate( self ):
print ‘py: slave terminating’
def Terminate( self ):
print ‘py: Terminate’[/code]

And then

[code]>>> from ROOT import *

myf = TFile(‘KaliPi0_Tuples.root’)
tree = myf.Get(‘KaliPi0/Pi0-Tuple’)
from Selector import *
Selector().MyConfig(2)
tree.Process(“TPySelector”,“Selector”)
py: beginning
py: slave beginning
py: processing 0
Info in TPySelector::AbortProcess: global name ‘coef’ is not defined
py: slave terminating
py: Terminate
py: beginning
py: slave beginning
TFile::Append:0: RuntimeWarning: Replacing existing TH1: m12 (Potential memory leak).
py: processing 0
Info in TPySelector::AbortProcess: global name ‘coef’ is not defined
py: slave terminating
py: Terminate
Traceback (most recent call last):
File “”, line 1, in
TypeError: none of the 2 overloaded methods succeeded. Full details:
global name ‘coef’ is not defined
Long64_t TTree::Process(void* selector, Option_t* option = “”, Long64_t nentries = 1000000000, Long64_t firstentry = 0) =>
could not convert argument 1[/code]

Maybe I should use global variables, but I would like to avoid that if possible.

Any solutions?

Cheers,
Albert

4

Hi,

which version of ROOT are you working with? If memory serves me ,the ability to pass a specific “MyPySelector” to TTree::Process has been added (it still requires the module name for the worker threads as well, though).

Cheers,
Wim

5

Hi Wim,

I am using ROOT 5.22/00, so maybe upgrading would help… I will try it and get back to you

Cheers,
Albert

6

Albert,

yes, 'fraid so. When I first wrote TPySelector based on a PROOF example given to me, I wasn’t aware of the possible use directly through TTree::Process. The newer code is in v5.26.

Cheers,
Wim

7

Hi Wim,

I am having problems right now installing v5.26 on MacOSX with the precompiled binaries,

I should probably post in ROOT Support. I will get back as soon as this is done.

Cheers,
Albert

8

Albert,

is this perhaps a 64b vs. 32b issue? I.e. that the python interpreter that you run is 64b, but the installed library (as per the target name) is 32b?

Cheers,
Wim

9

Hi Wim,

I don’t think so, everyhting is 32bit. I think it is something related to the way the binaries have been compiled… It seems it is going to AFS to try to find some files!!

Cheers,
Albert

10

Try adding /System/Library/Frameworks/Python.framework/Versions/Current to your DYLD_LIBRARY_PATH

I think this is because libPyROOT.so in this build depends on Python instead of libpython.dylib (which is a symlink to Python but is in an expected library path).

11

It worked, thanks a lot! Now I will try all the solutions proposed.

Cheers,
Albert