TTime saved to a TTree in ROOT5 and ROOT6

ROOT
,
1

Hi,

while reading ROOT files created with different versions of ROOT(5.34.36 and 6.26.06 respectively) with uproot, I stumble upon a problem reading out the fMilliSec value of the TTime object. In my specific case I have a class having a TTime object as one -private- data member, but I post here below a minimal example to show the problem. I used this simple macro (I do not care about filling meaningful values or more entries for the moment):

void create_tree_ttime(TString outname){
    TTime *mtime = new TTime();
    TFile f(outname.Data(),"recreate");
    TTree *t3 = new TTree("Events","Time");
    t3->Branch("MTime", &mtime);
    for (Int_t ev = 0; ev <1; ev++){
        t3->Fill();
    }
    f.Write();
    t3->Print();
}

So, if I run this under ROOT 5.34.36 I get:

******************************************************************************
*Tree    :Events    : Time                                                   *
*Entries :        1 : Total =            1499 bytes  File  Size =        588 *
*        :          : Tree compression factor =   1.00                       *
******************************************************************************
*Branch  :MTime                                                              *
*Entries :        1 : BranchElement (see below)                              *
*............................................................................*
*Br    0 :fMilliSec : Long64_t                                               *
*Entries :        1 : Total  Size=        588 bytes  File Size  =         86 *
*Baskets :        1 : Basket Size=      32000 bytes  Compression=   1.00     *
*............................................................................*

while for ROOT 6.26.06 I get:

******************************************************************************
*Tree    :Events    : Time                                                   *
*Entries :        1 : Total =             989 bytes  File  Size =        476 *
*        :          : Tree compression factor =   1.00                       *
******************************************************************************
*Br    0 :MTime     : TTime                                                  *
*Entries :        1 : Total  Size=        597 bytes  File Size  =        100 *
*Baskets :        1 : Basket Size=      32000 bytes  Compression=   1.00     *
*............................................................................*

Because of this, in the case of ROOT6 I cannot read out directly the value of fMilliSec using uproot. I did not see any visible change in the class TTime. What is the reason of the different way the ROOT files are created in this case? Is it possible to “recover” the ROOT5 behavior in ROOT6?

Best,
Alessio

2

Welcome to the ROOT forum.

@pcanal should know the answer to your problem.

4

This seems to be unintended side-effect of an unrelated improvement. In v6, the I/O properly respect the fact that a class has a custom Streamer (assuming because the default I/O is not sufficient for that class) and ensure that such custom Streamer are called whenever those objects are stored. In practice this means that some class that were stored in split mode, thus skipping the call to the Streamer function are no longer split.

In the case of TTime, the dictionary generated is requesting the ‘very’ old I/O for the class TTime. In practice this means that not only it can no longer be split but it also does not record the description of the TTime classes. As is uproot would need to add explicitly support for this class to be able to read.

Now, it also turns out that there does not seems to be any good reason to use the very old I/O (and thus a sort of custom Streamer) for this Class. So this is a bug that we need to resolve.

5

So, this is a case of a “backward compatibility” problem.
Probably it also appears for other classes (@pcanal, can one get a list of them?).

@sharingan It should be reported to the “uproot” developers.

I guess @sbinet could be interested, too.

6

@Wile_E_Coyote @pcanal Thank you for the insight! I was asking in the uproot forum already in parallel this morning, see Getting information from TTime fMilliSec member · scikit-hep/uproot5 · Discussion #859 · GitHub . There is a temporary solution to read out the values with uproot. I guess the main point of the other discussion is:

It’s always been difficult to figure out the right Interpretation for a TBranch, particularly with including or not including these headers. Some TBranches have headers at all levels, some have them at some levels, and some don’t have them at all, and it’s unclear (to me) where that information can be found.

so maybe some input can be given to Jim about the point he is raising?

7

Yes. On it. (but it is slightly off the point for that class).

8

Thanks for the mention but I think GoHEP isn’t relevant (anymore?).

9

Note that this is fixed in the upcoming v6.30 (i.e. current master branch) (see Allow splitting of TTime objects by pcanal · Pull Request #12499 · root-project/root · GitHub)

10

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