TPySelector usage problems

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

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

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

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

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

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

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

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

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

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).

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

Cheers,
Albert