I’m running with head version of RooUnfold (rev 349), while the stable version does not provide Merge functions (so its not usable in proof). In my proof analyzer (written in python) I fill out RooUnfoldResponse objects. Everything seems to run fine, when I do this using proof-Lite. When I switch to a proof session created with ProofOnDemand on a local cluster, calculation ends with following error messages:
Error in <TSelectorList::CheckDuplicateName>: an object with the same name: response_jecDown_jet15 is already in the list
After this printout my output file gets saved, contains objects with names I was using for response objects (e.g. response_jecDown_jet15) but being of TNamed type (and not RooUnfoldResponse as expected). For objects of different then RooUnfoldResponse type (e.g. root histos) I dont get any complains.
Any idea what’s happening/how can I debug this? The root version I’m using is 5.34.10-cms (obviously taken from CMS software )
Is there any unusual message in the worker logs?
The fact that you find objects with the same name but of different Type (TNamed, parent class of RooUnfoldResponse) makes me think that the library defining RooUnfoldResponse does not get loaded on the workers?
thanks for a prompt reply. In logs I don’t see anything suspicious. I have added also a type check for the problematic objects inside the worker code, its ROOT.RooUnfoldResponse (so the library seems to get correctly loaded on the slaves). In the Terminate method (after checkDuplicateName messages) those objects are visible as TNamed. Any other ideas?
Terminate is run locally. How do you load/make available the libraries to the workers? Is this a PAR file or are you loading explicitly by-hand?
This is done by hand - ROOT.gSystem.Load(“libRooUnfold.so”) just after the “import ROOT” statement.
Edit: I have tried also to add
(just after connecting to proof), but it doesnt help.
Sorry for the late reply.
Usually to set up everything correctly we to this either with TProof.Load or TProof.EnablePackage.
In particular, Exec is not run on the master. This may explain the fact that they do not get recognized while transferred back.