@Wile_E_Coyote I am not sure why it would be related the number of cycles in the original file.
My guess is that in the code:
auto newtree = oldtree->CloneTree();
newtree->SetNameTitle("PolSig", "PolSig");
newfile.Write();
CloneTree does an autosave and/or write of the TTree with its "then current" name (i.e. nominal) so it works ‘as intended’.
The work-around that you provided is ‘correct’ (change the name before cloning it).
If one does not want to change the original tree name, then you can split the operationing:
auto newtree = oldtree->CloneTree(0); // copy just the structure.
newtree->SetObject("PolSig", "PolSig"); // Somehow SetNameTitle is not yet overloded in TTree :( ...
newtree->CopyEntries(oldtree, -1, "fast"); // "fast" is not the default in CopyEntries not in CloneTree :(
@pcanal I did a small test with the “hsmiple.root”. As soon as there are two “cycles” of the “ntuple” (note: you need to increase its number of entries; I tried with 2500000), the problem with “SetObject” appears.
We got a mystery on our hand … I just tried with v6.22/08 and got the same (good) result I got before …
One noticeable difference between your output and mine (in both master and v6.22/08) is the order of the keys in the input file, you get:
KEY: TNtuple ntuple;2 Demo ntuple
KEY: TNtuple ntuple;1 Demo ntuple
KEY: TH1F hpx;1 This is the px distribution
KEY: TH2F hpxpy;1 py vs px
KEY: TProfile hprof;1 Profile of pz versus px
while I get:
KEY: TH1F hpx;1 This is the px distribution
KEY: TH2F hpxpy;1 py vs px
KEY: TProfile hprof;1 Profile of pz versus px
KEY: TNtuple ntuple;2 Demo ntuple
KEY: TNtuple ntuple;1 Demo ntuple
So there is something different between your hsimple.root and mine. Could you send me yours?
const Int_t kUPDATE = 100000;
for (Int_t i = 0; i < 2500000; i++) {
Then:
rm -f hsimple.root # not really needed, of course
root -q hsimple.C # the modified macro which (re)creates "hsimple.root"
root -q hsimple_newfile.cxx # my test macro (output in my previous post)
@pcanal Let me know if you cannot reproduce this problem (I will then send you the “hsimple.root” file that I produced).
depending on the content of the TTree you’re dealing with, the root-cp command from Go-HEP may help you (while the one you get from ROOT/C++ is being fixed).
This one worked for me and did not actually change the name of the tree in the original file.
So now get the first step done. Which means that i can take all the input files and from them produce new ones that only contain the properly renamed “nominal” trees including all cycle numbers.
However now i need to add all of these trees together. And i noticed that hadd always just takes the highest cycle. However, i need to combine all of the cycles from all of the files.
So currently i now have 2 files that contain PolSig;1 and PolSig;2.
One file that containts PolBkg;1 and one that containrs PolBkg;1 and PolBkg;2.
What i needs is one files that contains PolSig and PolBkg that are the sum of the four PolSig’s and three PolBkg’s. I do not care if they are also split into different cycles but i need all events from the input files to be in the merged one. Is there any reasonable way to do that?
So, the behavior is exactly as intended. The flow is:
oldfile.GetObject("ntuple", oldtree);
...
auto newtree = oldtree->CloneTree();
where the request is here “explicitly” to slow copy a TTree named “ntuple”, and which has, in the original case and the modified hsimple case, more entries that the AutoSave limit. This means that during the execution of CloneTree a cycle for the TTree named “ntuple” is (of course) created.
Calling TTree::SetObject (better version of SetNameTitle but same result here), will change the name of the live object (and we see that with the name of the key/cycle written by TFile::Write) but will not (and should not) retroactively change the name of the existing cycles in the file. So
Yes, this is the intent. Lowest cycles are, for all the automatic tools, consider are backup backup that are to be ignored (as they contains redundant information).
So currently i now have 2 files that contain PolSig;1 and PolSig;2.
I am confused. Do you really have 2 completely distinct TNtuple with the same name and PolSig;1 is not a backup/partial-copy of PolSig;2? How did you get there? Why?
For example in the case of the extended hsimple.C from Wile, we ended up with a file containing:
TFile** hs3.root Demo ROOT file with histograms
TFile* hs3.root Demo ROOT file with histograms
OBJ: TNtuple ntuple Demo ntuple : 0 at: 0x7fb4fecd4070
KEY: TH1F hpx;1 This is the px distribution
KEY: TH2F hpxpy;1 py vs px
KEY: TProfile hprof;1 Profile of pz versus px
KEY: TNtuple ntuple;2 Demo ntuple [current cycle]
KEY: TNtuple ntuple;1 Demo ntuple [backup cycle]
where ntuple;1; has 1891734 entries and ntuple;2 has/points-to the exact same 1891734 entries plus an addition 608266 entries for a total of 2500000 entries.
In this case if one were to use bothntuple;1 and ntuple;2, you would be use the first 1891734 entries twice most likely rendering the result wrong.
Unless you are doing something unusual, you should ignore the lowest cycles.
If you are doing something unusual you have to weight the advantage you found in doing so with the fact that the automatic tools will be not recognized this unusual situation and ignore the lowest cycles (which contains usually duplicated/redundant information).