Problem in read TTree ROOT

Hello,

I’m trying read the file .root :
crmc_eposlhc_72406074_p_p_3500.root (567.3 KB)

Using the macro.C:


#include "TROOT.h"
#include "TFile.h"
#include "TTree.h"
#include "TBrowser.h"
#include "TH1.h"
#include "TH1F.h"
#include "TH2.h"
#include "TRandom.h"


    void Analise_ROOT_I(const char* fileNameIn="crmc_eposlhc_72406074_p_p_3500.root"){
        
        //Precision:
        cout<<fixed;
        cout<<setprecision(5);
        
        // *******************************************************
        // Open the file that have the object Tree
        // *******************************************************
        TFile *fin = new TFile(fileNameIn,"READ");
        
        // *******************************************************
        // Take the object TTree that be inside of the file .root
        // *******************************************************
        TTree *Particle = (TTree*)fin->Get("Particle"); 
        
        // *******************************************************
        //definition  of variables
        // *******************************************************
        Double_t px, py, pz, E, m;
        Int_t  nPart, pdgid, status;
        
        // *******************************************************
        // Access the leaf of the TTree
        // *******************************************************
        Particle->SetBranchAddress("nPart",&nPart);
        Particle->SetBranchAddress("pdgid",&pdgid);
        Particle->SetBranchAddress("status",&status);
        Particle->SetBranchAddress("px",&px);
        Particle->SetBranchAddress("py",&py);
        Particle->SetBranchAddress("pz",&pz);
        Particle->SetBranchAddress("E",&E);
        Particle->SetBranchAddress("m",&m);

        //read all entries and fill the histograms
        Int_t nentries = (Int_t)Particle->GetEntries();
        
        
        // *******************************************************
        // Create  a window for show the graphic
        // *******************************************************
        TCanvas *c1 = new TCanvas("c1","c1",10,10,700,500);
        //c1->SetFillColor(18);
        c1->SetGrid(1,1);
        c1->SetLogx(0); // 0 == scale without Log, 1 == scale with Log
        c1->SetLogy(0);
        
        
        // create one histograms
        TH1F *hpx= new TH1F("hpx","px distribution",100,-3,3);
        
        
        //Fill the histogram
        for (Int_t i=0; i<nentries; i++) {
            
            Particle->GetEntry(i);
            hpx->Fill(px);
            
        }
        //Draw the histogram
        hpx->Draw();
        hpx->GetYaxis()->SetTitle("dN/dpx [GeV^{-1}]");
        hpx->GetXaxis()->SetTitle("px [GeV]");

    }

Error:

^Candre@andre-QBEX-H61H2-M17:~/ROOT$ root -l macro.C 
root [0] 
Processing Analise_ROOT_I.C...
ERROR leaf:pz, len=1069989368 and max=909
ERROR leaf:pz, len=1068155873 and max=909
ERROR leaf:pz, len=1072372272 and max=909
ERROR leaf:E, len=1078495556 and max=909
ERROR leaf:m, len=1077788337 and max=909
ERROR leaf:pz, len=1070995620 and max=909
ERROR leaf:E, len=1082607030 and max=909
...

Someone have some tip to fix this, Thanks in advanced.

Cheers,
Andre

Hi Andre,

can you share the input file or part of it (a few entries will be enough).

Cheers,
D

@dpiparo Did you get open this input file?
If not, So, I share the input file in the Dropbox folder

Thanks

Cheers,
Andre

using go-hep/rootio’s root-ls:

$> root-ls -t crmc_eposlhc_72406074_p_p_3500.root
=== [/home/binet/Downloads/34af5846a15d060062e2cc30d60d90f6912315b1.root] ===
version: 61103
TTree    Particle          particles produced (entries=100)
  nPart  "nPart/I"         TBranch
  pdgid  "pdgid[nPart]/I"  TBranch
  status "status[nPart]/I" TBranch
  px     "px[nPart]/D"     TBranch
  py     "py[nPart]/D"     TBranch
  pz     "pz[nPart]/D"     TBranch
  E      "E[nPart]/D"      TBranch
  m      "m[nPart]/D"      TBranch

ie: while nPart is indeed an Int_t, the other variables are really variable-size arrays (but cap’d at nPart).

so you should instead use:

const Int_t NMAX = 909;
Double_t px[NMAX], py[NMAX], ...; 

to read in the data.

… And that’s exactly why we recommend the use of TTreeReader and TDataFrame! You might want to give those a try, they make reading a TTree much simpler.

Cheers, Axel

Hi,

just for the sake of completeness: ROOT natively provides an ls-like tool to explore ROOT files from command line, rootls.

Cheers,
D

Hi Andre, all,

and now the macro which uses TDataFrame to accomplish the same goal of the one above:

void ana() {

  // 2 lines for the analysis
  ROOT::Experimental::TDataFrame d("Particle","crmc_eposlhc_72406074_p_p_3500.root");
  auto hpx = d.Histo1D({"hpx", "px distribution", 100, -3, 3}, "px");

  // The rest for the drawing
  auto c1 = new TCanvas("c1", "c1", 10, 10, 700, 500);
  c1->SetGrid(1, 1);
  c1->SetLogx(0); // 0 == scale without Log, 1 == scale with Log
  c1->SetLogy(0);
  hpx->DrawClone();
  hpx->GetYaxis()->SetTitle("dN/dpx [GeV^{-1}]");
  hpx->GetXaxis()->SetTitle("px [GeV]");
}

Cheers,
D

indeed.
but ROOT’s rootls has 2 major deficiencies IMHO:

  • hyphenation is wrong (but that’s great: I can then use the correct one for my tools :P)
  • it’s, like other ROOT6-linked binaries, very slow to start up (OK, rootls is a PyROOT script but still)

I’ve notice this very irritating behaviour since a few ROOT6 releases.
there seems to be some kind of cache/re-JIT-ing? effect that goes on that makes running ROOT6-linked binaries very slow to start for binaries that one hasn’t used for a while.

see:

$> time rootls -t crmc_eposlhc_72406074_p_p_3500.root > /dev/null

real 0m2.771s
user 0m0.791s
sys  0m0.185s

$> time rootls -t crmc_eposlhc_72406074_p_p_3500.root > /dev/null

real 0m0.733s
user 0m0.657s
sys  0m0.075s

compared to a completely statically linked Go binary:

$>  time root-ls -t crmc_eposlhc_72406074_p_p_3500.root >/dev/null

real 0m0.005s
user 0m0.003s
sys  0m0.003s

on a day-to-day basis, it’s super irritating. (on the plus side, I can bask in the blazing-fast side of Go :P)

Sebastien, please stay reasonable. How does language matter here? Of course we could write the same 0.005s binary also in Javascript and it would be at least as relevant…

We’ll look into the slow startup, that’s of course broken - and it wasn’t like that for the last releases:

So thanks for the report! Which exact version, which platform are we talking about, how was ROOT built / configures and most importantly what kind of filesystem / hardware is ROOT being loaded from? (And shouldn’t this have gone into a separate topic, Sebastien?)

Cheers, Axel.

(I’ll answer here partly and will create another thread for the requested details)

First of all, I just happen to use Go, right, and I am enthusiastic about that but the interesting part here is “statically linked [compiled] binary”.
it’s just easier to produce completely statically compiled binaries in Go.
you could do the same in C or Fortran. or JavaScript+Emscripten+Rust. or just Rust. (you could also try to do the same in C++)

the language doesn’t matter here, just the mechanism by which you get the binary.

I don’t think I am being unreasonable.
I am just talking about a different implementation of the ROOT file format (that happens to be written in Go), that works at a different point in the n-dimensional phase space of all quantities that matter for the set of all possible programs and use cases in the known universe.
this implementation has pros and cons wrt the C++/ROOT implementation.
it strikes a different compromise, one that better suits my needs.
For small command-line executables that need to be executed quickly, for which loading gazillions of .so completely dwarfs the command’s runtime, it hits the sweet spot.

here is the report:

cheers,
-s


PS: I must say I was actually surprised to find out rootls was actually a ~1K lines PyROOT script.
I thought it was a simple C++ application (but the same slow startup behaviour does happen for my own C++ ROOT reading files benchmark applications.)

Whatever the issue I am positive that this is not the reason: shared lib loading doesn’t take a second. Thanks for opening the other post!

Axel.

Thanks All, and special to @sbinet and @dpiparo

The program is working very well! Now I’m going to use more TTreeReader and TDataFrame classes, that is most more simple.

Great job, ROOT Team.

Cheers,
Andre

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