Number of entries and First entry not working on PROOF

ROOT
1

Hi,

We are having problems in our framework setting the number of entries and the first entry. Is this expected to work with PROOF? I have tried the following 2 methods with no success:

TChain::Process(void* selector, Option_t* option = "", Long64_t nentries = kBigNumber, Long64_t firstentry = 0)

TProof::Process(TDSet* dset, const char* selector, Option_t* option = "", Long64_t nentries = -1, Long64_t firstentry = 0)

It works if I use the first method in sequential mode (i.e. not issuing a TChain::SetProof()).

Thanks,

Isidro

2

Hi Isidro,

Which version is this?
I cannot reproduce it with trunk, 5-30-03, 5-28-00g .

Gerri

3

Hi Gerry,

I was using 5.30.00. I will try to check with 5.30.03 and let you know.

Cheers,

Isidro

4

Uhmm … I will be surprised if it would change things.

It is weird, ALICE had a somewhat similar problem when starting from a named dataset (i.e. with TProof::Process(const char *dsetname, …) but that was fixed months ago.

Does it happen for number of events (or first event) corresponding to file changes?

Gerri

5

Difficult to say Gerry. What I have seen with 5.30.00 is that sometimes it processes just the nevents specified, but not always. Compiling 5.30.03 now…

Isidro

6

Hi again,

My checks on 5.30.03 show the following:

  • Setting the first event to be processed worked. It skips those events.
  • Setting the number of events does not work. The funny thing is that the dialog box shows the specified number of events at the beginning and when it goes for the first bunch of data it automatically changes to the whole sample

All the data is in single file (5.2 GB). I checked both PROOF Lite and PoD on our framework. I am sure I am calling:

TChain* tchain = ...
...
Long64_t  nevents    = 100000;
Long64_t  firstevent = 200000;
tchain->SetProof();
tchain->Process(selectorcplus, 0, nevents, firstevent);

If I remove the SetProof() call it goes in “sequential” mode and it works.

By the way, if I try to use the Process call that takes a TSelector* it wil not work giving the following message:

Warning in <TProofChain::Process>: not implemented

Thanks,

Isidro

7

In case it helps. A very simple way of checking this.

  1. Get a file with events and produce a selector:
$ root -l somefile.root
root [0] 
Attaching file somefile.root as _file0...
root [1] TTree* tree = _file0->Get("theTreeName")
root [2] tree->MakeSelector("selector")
root [3] .q
  1. Run this code:
{
  cout << "Create chain... " << endl;
  TChain* chain = new TChain("theTreeName");

  cout << "Add files... " << endl;
  chain->Add("somefile.root");

  cout << "Start Proof..." << endl;
  TProof* proof = TProof::Open("");

  chain->SetProof();


  Long64_t nevents    = 100000; //Or whatever number of events you want to check
  Long64_t firstevent = 200000; //Or whichever event you want to start with
  
  cout<< "Processing " << nevents << " events, starting in " << firstevent
      << endl;
  chain->Process("selector.C+", 0, nevents, firstevent);

}
8

Gerry, have you seen this problem? If so, any idea of when will it be fixed?

Cheers,

Isidro

9

Hi,
I am reporting a similar case here. I use ProofLite and whatever value I set for the number of entries, it always processes all the entries.
What I have also noticed in the Progress Dialog is that, during the initialization phase, the number of entries is shown correctly but just before the processing starts, it changes to the total number of entries.
Details:
Root Version 5.30/03
Ubuntu 32 bit
Thanks,
Samuel

10

Hi,

Yes, I managed to reproduce a somewhat similar case.
But I have not yet finished to debug it.

I hope to have news soon.

Gerri

11

Hi,

I think I have found the reason and a fix.
I need to cross-check that there no side-effects before committing.
I’ll port the fix to 5-30-00-patches and it will be in 5-32 starting from 5-32-rc2 (in two weeks).

I let you know.

Gerri

12

Hi,

Today I have committed in the trunk and 5-30-patches what I expect to be the fix for this problem.
Note that LHCb has requested a new tag on 5-30 so 5-30-04 will be cut in the next days.

Let me know if you manage to try the fix.

Gerri