With a loose reconstruction cut, there can be several reconstruction candidates in a single event. I am undecided on how to store such info in TTree.
Putting recon candidates into a clonesarray in an event entry seems infeasible since most tools are designed to work with one row per recon candidate; and clonesarray cannot be nested.
Putting events and reconstructions into two different trees (tables) is what a general database would do, but tree formula cannot handle joins between trees.
Currently I use two trees and copy any needed variables from the event tree to the candidate tree when reading event variables or putting event cuts. Is there any better way?
Another question: is there any usage guide on how to use TTreeFormula/TTreeFormulaManager? (are they supposed to be used by general users?)
[quote]Putting recon candidates into a clonesarray in an event entry seems infeasible since most tools are designed to work with one row per recon candidate; and clonesarray cannot be nested. [/quote]From your description, I do not understand where a nesting of TClonesArray would appear …
[quote]Putting events and reconstructions into two different trees (tables) is what a general database would do, but tree formula cannot handle joins between trees. [/quote]There is a simple mechanism to join 2 TTree using one index. See TTree::AddFriend and TTree::BuildIndex.
[quote]Currently I use two trees and copy any needed variables from the event tree to the candidate tree when reading event variables or putting event cuts. Is there any better way?[/quote]A TTree Friend(ship) might also be helpful.
[quote]Another question: is there any usage guide on how to use TTreeFormula/TTreeFormulaManager? (are they supposed to be used by general users?) [/quote]There is a few example of use here and there. See the TSelectorDraw class and the implementation of TTreePlayer::ScanSelect.
[quote]There is a simple mechanism to join 2 TTree using one index. See TTree::AddFriend and TTree::BuildIndex.
[/quote]
Suppose I use exp/run as major and minorname as index. For each analysis job, I save one recon candidate tree and one event tree into a file, both trees having the exp/run branches. To do analysis in ROOT, I create two TChains, one with recon trees and one with event trees, and want to build an index for the event trees. Should I build the index at the TChain level, instead of TTree for each event tree?
If I build an index for the event chain and make it friend of recon chain, do TTreeFormula and TCuts works as expected? eg.
recon_chain->Draw("recon_var:event_var","recon_var > 0 && event_var > 0");
I am just being cautious and want to make sure tree index works as expected, such that RooFit and TMVA behaves correctly with these formulae and cuts.
[quote]From your description, I do not understand where a nesting of TClonesArray would appear …
[/quote]
Sorry for being unclear. Since I already use TClonesArray to save some info for each recon candidate, putting recon candidates into a TClonesArray for each event would make a nesting.
I have found that filling and resetting branches in friend trees which are put into a TChain rather difficult. TChain::Branch doesn’t create branches for its trees and saving a TChain doesn’t save its tree. If I want to fill new variables calculated from the main TChain into a friend TChain, I have to individually open each friend file and fill each friend tree. It would be nice if TChain can simply pass variable filling into its tree.
[quote]Should I build the index at the TChain level, instead of TTree for each event tree?[/quote]You can do either on the completed chain or on each and every tree individually. Either way, the index need to be build on the right hand of the friendship (i.e. in mytree->AddFriend(myfriend); the buildindex is to be done on myfriend.
[quote]If I build an index for the event chain and make it friend of recon chain, do TTreeFormula and TCuts works as expected?[/quote]Yes, this is exactly the idea
[quote]I have found that filling and resetting branches in friend trees which are put into a TChain rather difficult. TChain::Branch doesn’t create branches for its trees and saving a TChain doesn’t save its tree. If I want to fill new variables calculated from the main TChain into a friend TChain, I have to individually open each friend file and fill each friend tree. It would be nice if TChain can simply pass variable filling into its tree.[/quote]This is intentional, a chain is only a collection of existing trees. Note that your can befriend a TTree to a TChain (and vice et versa) as long as the have the same total number of entries.
I have a thought about chain index. The chain index requires the index ranges in the list of trees to be in order. IMO this requirement is unnessary; requiring the index ranges not crossing each other would be enough to allow finding the right tree index to search in. All we need is to add, in the sorted array of index ranges, an extra field equals to the tree number in chain (instead of currently using the array index as the tree number, forcing the tree number to be in the same order as sorted index range).
I my case, I want to make a chain which is the inclusive sum from several different background decay modes. I would add these background decay chains in a inclusive chain; while the background modes has non-overlapping index range (by assign a majornumber to each mode), their ordering is not gauranteed and logically unnessary. Also, user generated MC set may use a non-strict numbering scheme.
Of course it would still work if I take care to make up an ordering scheme and make sure files are in order. But a simple patch for TChainIndex to handle random order would be no more difficult. Though the later option is only valid if the patch is acceptable.
[quote]I have a thought about chain index. The chain index requires the index ranges in the list of trees to be in order. IMO this requirement is unnessary;[/quote] The advantage of requiring the list of tree to be ‘ordered’ is that it avoids having to open all the tree before starting to process.
[quote] But a simple patch for TChainIndex to handle random order would be no more difficult.[/quote]Yes as long as this does prevent the ordered case to work without having to open all the TTrees (and be the default behavior).
