Repository: root-project/root

Issue #14558: [ROOT-4716] TTree merging problems when including empty trees
Created: 2024-02-04T17:58:34Z
Check duplicate issues.

 Checked for duplicates

Description
From https://its.cern.ch/jira/browse/ROOT-4716
Dear Developers,
This problem that I'll describe now was first discussed in
https://savannah.cern.ch/bugs/?98501
But since by now the issue doesn't seem to have anything to do with PROOF and TProofOutputFile, I thought I'd rather continue the discussion in a new thread.
What I originally observed was that in the latest 5.34.XX version some of my PROOF jobs would return me an empty TTree, even though the job reported that it selected some events. For a while I was not able to find a handle on what triggered this problem, as it seemed quite random. (The same job would not always return empty trees.)
I think I now understand what's going on. It has to do with the issue in TFileMerger that was discovered in ATLAS production jobs a long time ago. When TFileMerger is given multiple files, the first of which doesn't have any branches in it, the merged output file will not have any branches either. Even if the rest of the files given to TFileMerger did have some structure.
In my PROOF jobs this happens because my code only sets up the format of its output TTree when it opens its first file. The output TTree format depends a bit on what branches are available on the input, so I can't do this any sooner.
But PROOF in some cases will not process any events in some of its workers. When this happens, it's actually these workers that return their output files to the PROOF master first. Files which hold completely empty TTree-s.
This made my jobs random, as PROOF would not always do this, sometimes (depending on the state of our cluster) it would actually process some events on all of the workers in this job.
The problem can be demonstrated very easily. Attached is a macro that does this. (The macro was first written to demonstrate a problem with merging a file into a file on XRootD, but this issue doesn't depend on where the file is put.)
While I may be able to circumvent the problem in my analysis code for now (by initializing the TTree format earlier in the code), this merging problem would be very good to solve. As I wrote at the beginning, the ATLAS production system also has to have extra code in place which knows not to give files with empty TTrees to hadd as the first file.
Cheers,
Attila
Reproducer
NA
ROOT version
Any
Installation method
Any
Operating system
Any
Additional context
No response

Duplicate issue #12510:  Issue with `hadd` when first file has empty tree
Created: 2023-03-20T15:53:54Z
Describe the bug
It seems hadd is confused by the zero length TTree as a first file. Pls find dummy root files in the attached ZIP to reproduce the issue. In dummyFile0.root, there're 1000 events in the dummyTree; While in dummyFile1.root, the tree is empty. So when hadd 2 files, like
hadd dummyFile01.root dummyFile0.root dummyFile1.root

Everything is okay. While if you do like
hadd dummyFile10.root dummyFile1.root dummyFile0.root

And you open the merged dummyFile10.root to get entries like
root [1] dummyTree->GetEntries()
(long long) 1000

It looks okay. But if you show the first event, like
root [1] dummyTree->Show(0)
======> EVENT:0
 index           = 0
 dummyVariable   = 2.13654e-306

The dummyVariable is definitely non-sense. It should be 0.261287 as it is in the dummyFile0.root. I guess if put the empty tree at the first in merging, ROOT is trying get a variable from an empty pointer?
Expected behavior
root [1] dummyTree->Show(0)
======> EVENT:0
 index           = 0
 dummyVariable   = 0.261287

Setup

ROOT version: 6.26/06
Operating system: macosx64

dummyFiles.zip

Closing comment (2024-02-28T06:32:23Z): Related to #14558 . A good solution is to intervene directly in the Merge function of TTree.