Uploaded image for project: 'ROOT'
  1. ROOT
  2. ROOT-10557

Wrong results when using TTree::Draw/Scan on specific entries of vectors of vectors

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.20/00, 6.18/06
    • Component/s: TTree
    • Labels:
      None
    • Environment:

      ROOT 6.18.02 on lxplus7, tested also with root 5.34.18

      Description

      Dear experts,

      we have found a very strange issue when using the TTree Draw/Scan/Projection functions on vectors of vectors.

      In our analysis, we consider large jets that are made up of smaller jets. To represent the kinematics of these small jets in the Tree, we use vectors of vectors, specifically

      vector<vector<float>> * subjet_pt/eta/phi/e
      

      Where subjet_pt[0/1/2] are the vectors of the pt of subjets in the first, second, third large jet.

      For each event, one of these large jets is "tagged" and we store the index of this tagged jet in a branch.

      The issue appears when we try to draw/scan the subjet_pt of the tagged jet (or its length): if we call

      tree->Scan( "subjet_pt[tagged_index]:tagged_index" )
      

      we get wrong results, only for events where tagged_index is != 0. In particular, most of the timesĀ subjet_pt[tagged_index] contains more entries than it should. The additional entries are printed as empty

      The issue doesn't appear when we pass by hand the index of the jet:

      tree->Scan( "Length$(subjet_pt[tagged_index]):Length$(subjet_pt[2])", "tagged_index == 2" )
       

      In this case the column corresponding to subjet_pt[tagged_index] is wrong, while the one corresponding to subjet_pt[2] is correct.

      We attach a code which replicates the issue.

      In this code we build a tree with four branches:

      • subjets_pt which is a vector< vector<int>> containing the pt of the large jets components (filled with meaningless values)
      • tagged_index: the index of the tagged jet (component_pt[tagged_index] is then vector of the pt of the subjets inside the tagged jet);
      • nsubjets: is the number of subjets of the tagged jet, to be used as a cross check
      • njets is the number of large jets

      Within ROOT, this can be run with

      .L Loader.C++
      .L createTree.C++
      run()
      

      and creates a file named AFile.root with a tree named myTree

      Several checks can be performed:

       
      myTree->Scan( "nsubjets:subjets_pt[tagged_index]:tagged_index" )
       

      will show that the number of entries of the subjets_pt[tagged_index] column is equal to nsubjets only when tagged_index is zero.
      This line

       myTree->Scan( "nsubjets:subjets_pt[1]:tagged_index", "tagged_index == 1" )
       

      will show that, when we request explicitly the second element to be tagged (tagged_index == 1) and access explicitly the second element (subjet_pt[1]), the results is correct.

      In summary, everything works well when we pass explicitly the index of the large jet we want to access (subjets_pt[0], subjets_pt[1] and so on); the problems appear when we pass an integer stored in a branch of the same tree.
      In particular, it seems that Length$(subjets_pt[tagged_index]) is equal to Length$(subjets_pt[0]) regardless the actual value of tagged_index. Only the size is wrong: the actual vector seems correct (with blank entries when the actual size is smaller, and "truncated" when the actual size is bigger). Everything works fine when we pass the index by hand.

        Attachments

        1. createTree.C
          2 kB
        2. Loader.C
          0.1 kB

          Activity

            People

            • Assignee:
              pcanal Philippe Canal
              Reporter:
              mromano Marino Romano
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: