Issues with fInput with TSelector

Hello everyone,

I am fairly new to ROOT forums, so please let me know if my post is lacking any information.

I have run into a strange issue with trying to access fInput in the Begin() vs the SlaveBegin() portions of my TSelector. I have a simple TNtuple that I pass as input to my TSelector via

gProof->AddInput(input_TNtuple);

and which I can properly access inside the Begin() section

client_TNtuple = dynamic_cast<TNtuple*>(fInput->FindObject("input_TNtuple"));
float *client_row_content;
for (Int_t irow = 0; irow < client_TNtuple->GetEntries(); irow++)
    {
      client_TNtuple->GetEntry(irow);
      client_row_content = client_TNtuple->GetArgs();
      client_mean[irow] = client_row_content[0];
      client_std[irow] = client_row_content[1]; 
      cout << client_mean[irow] << "   " << client_std[irow] << endl;
    }

which will output, as intended

-13.1128   0.723721
-18.7225   0.680449
-19.119    0.728703
-18.7981   0.711431

however when I do the identical operation on the slave in BeginSlave()

slave_TNtuple = dynamic_cast<TNtuple*>(fInput->FindObject("input_TNtuple"));
float *slave_row_content;
for (Int_t irow = 0; irow < slave_TNtuple->GetEntries(); irow++)
    {
      slave_TNtuple->GetEntry(irow);
      slave_row_content = slave_TNtuple->GetArgs();
      slave_mean[irow] = slave_row_content[0];
      slave_std[irow] = slave_row_content[1]; 
      cout << slave_mean[irow] << "   " << slave_std[irow] << endl;
    }

I get as output

1.43339e+07   4.56837e-41
1.43339e+07   4.56837e-41
1.43339e+07   4.56837e-41
1.43339e+07   4.56837e-41

or something equally meaningless (isn’t always the same). Both client_TNtuple and slave_TNtuple are declared in my header file

TNtuple *client_TNtuple;
TNtuple *slave_TNtuple;

So it is recognizing the proper number of entries (4), but not accessing the entries properly for some reason. My instinct tells me that there might be some issue moving the input_TNtuple to the slaves properly, but I have no idea how to address that issue.

My system information is:
ROOT Version (6.10/02):
Platform, compiler (CentOS 7.4, gcc4.8.5):

Dear rambrose

That looks very weird indeed.
Will you be able to produce and post a minimal reproducer?

G Ganis

Ganis,

Attached is an identical method I am using, reduced to simply illustrate the issue I am having.

The ROOT data I am using is contained in sample_data.root, but serves no purpose here except to give the Process() something to loop over (only contains 100 entries). The TSelector is stored in TEST.C and TEST.h, where you can see exactly how I call the InputList in Begin() and SlaveBegin(). TEMP.root is where the TNtuple I wish to have available on both the client and slave is stored (note, it must be separate from the data file I loop over due to the nature of our experiment). And lastly the run_TEST script automates the initializing of the Proof-lite, and adds the TNtuple to the InputList of the TSelector.

For reference, simply enter the command

root run_TEST.C

where the TNtuple will be properly output by the client in the terminal. If you select “Show Logs” on the PROOF GUI which launches, select “All” workers, and “Display”, you can see each worker finds (correctly) 4 entries in the TNtuple, but incorrect values. In fact, each worker typically returns different entries for the TNtuple. Additionally, if I try to add the TNtuple to the OutputList from the workers, the code will crash (hence why the line is currently commented out).

R Ambrose

run_TEST.C (391 Bytes)
TEST.h (2.5 KB)
TEMP.root (5.4 KB)
TEST.C (3.8 KB)
sample_data.root (444.5 KB)

P.S. I apologize for the undescriptive file names

If this provides any additional information, if I attempt to call the method

slave_output->Show(irow);

on the slave servers I will receive as output

Error in <TNtuple::Show()>: Cannot read entry 1 (I/O error)

where I read what I expect on the client

client_output->Show(irow);
======> EVENT:0
 Mean            = -13.1128
 Std             = 0.723721

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.