Hi! I have a chain made of several root files with a certain tree, in total about 3E9 events. I have to perform an entry-dependent calibration of a certain leaf of the tree. With the explicit loop on chain (i.e. from MakeClass) this is trivially done, but when trying to use the macro from MakeSelector (ie.e the Process command) I got into troubles using a Proof session. I open a Proof session, I build the Chain, I set the Proff values to true and the Process my macro, and indeed it works: it fills spectra, etc…
However, the “entry” variable , which I print out using the class SendAsynMessage of TProofServ.h in the Process part, seems to change erratically, and not to steadily increase up to 3E9, so I cannot do my entry-dependent calibration. Is there any way entry-dependent calibration to do this in Proof ?
Sorry for the late reply.
One thing that PROOF cannot guarantee is the order of processing. This is by construction, so if you send the entry number seen by process with SendAsynMessage you will get messages from the various workers in cahotic manner.
To be frank, I am not sure to understand what you mean by ‘entry-dependent’ calibration or, better, how you would use what SendAsynMessage sends back.
If you can provide a small example or a description of the essential components, I can try to figure out if there is anyway to do that in PROOF.
Dear Ganis,
thank you for your reply. Basically, I have to (re)calibrate a variable, the detector energy, because when I plot it as a function of event number I see a linear shift in time (I do not have a timestamp variable, anyway). So I wanted to correct for this behaviour. With SendAsynMessage I was only trying to print out the entry number from PROOF to see how it is incrementing.
However, from what you are writing me, I see a possible solution may be to to write directly in the tree I am analyzing a branch with the “event number” variable… Am I right ?
Yes, I would say so. The entry number you get in Process does not have an absolute meaning; if you change the order of the files in the TChain you will get a different entry number for the same event. So you should not rely on such a number for calibrations or similar actions.
Having a real event number or a timestamp or any other observable allowing to point to the right calibration is the right way to go, I believe.