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

Problem w/#pragma read and split branch

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 5.34/00
    • Fix Version/s: None
    • Component/s: I/O
    • Labels:
      None
    • Environment:

      Debian GNU/Linux 'sid', GCC 4.8.2

      Description

      Hi there,

      I want to set-up some backward compatibility code for reading in an object of the class AliAODForwardMult. In the old version, it contained some information that should be moved into a new separate class called AliAODForwardHeader. For backward compatibility I set-up the new version (6) of AliAODForwardMult to be able to create an AliAODForwardHeader object from the information in the old version (5) of that class. I accomplish this by using the relatively new feature of #pragma read - a very cool and useful feature btw.

      For all the details, please see the attached tar ball.

      tar -xzf pragma_read.tar.gz
      cd pragma_read

      (Old version of code is in sub-directory v1 , and new in v2)

      Now, if I write an object of the old class AliAODForwardMult-5 to a file and read that back using the new class AliAODForwardMult-6 everything is dandy. To see this, do

      make test

      which produces the output

      root -l -b -q v1/Test.C(0)
      root [0]
      Processing v1/Test.C(0)...
      === Creating old-style object ===
      TH1.Print Name = forwardMult, Entries= 2, Total sum= 0
      Ipz: -5cm valid
      Triggers: NSD
      sNN: 2760GeV
      System: PbPb
      Centrality: 30%

      === Wrote to file ===
      === End of Test ===
      root -l -b -q v2/Test.C(0)
      root [0]
      Processing v2/Test.C(0)...
      === Reading new style object ===
      Reading AliAODForwardMult object in streamer
      Info in <AliAODForwardMult::>: Creating header
      === Read from file ===
      TH1.Print Name = forwardMult, Entries= 2, Total sum= 0
      N_ch(eta,phi): (200,-4-6)x(20,0-6.28319)
      sNN: 2760GeV
      System: PbPb
      Ipz: -5cm valid
      Triggers: NSD
      Centrality: 30%
      N_cluster: 0

      === End of Test ===

      Now, if I on the other hand write the object of class AliAODForwardMult-5 to a branch with splitlevel!=0 and read it back with AliAODForwardMult-6 then none of the #pragma read code is executed, and consequently I cannot retrieve the legacy information from the old object.

      To see this, do

      make test TREE=1

      which produces the output

      root -l -b -q v1/Test.C(1)
      root [0]
      Processing v1/Test.C(1)...
      === Creating old-style object ===
      TH1.Print Name = forwardMult, Entries= 2, Total sum= 0
      Ipz: -5cm valid
      Triggers: NSD
      sNN: 2760GeV
      System: PbPb
      Centrality: 30%

      === Wrote to file (in TTree) ===
      === End of Test ===
      root -l -b -q v2/Test.C(1)
      root [0]
      Processing v2/Test.C(1)...
      === Reading new style object ===
      === Read from file (in TTree) ===
      TH1.Print Name = forwardMult, Entries= 2, Total sum= 0
      N_ch(eta,phi): (200,-4-6)x(20,0-6.28319)
      sNN: 2760GeV
      System: PbPb

      === End of Test ===

      (if the branch is made with splitlevel=0 then everything is dandy).

      I tried flagging the class AliAODForwardMult-6 to have a custom streamer - in the hope that it would trigger `branch unsplitting' - but it didn't. Try

      make test TREE=1 CUSTOM=1

      with the same output as above.

      So I think that there's something wrong with the #pragma read functionality when it comes to TTree I/O and split branches. From reading this document I understand that it takes some special precautions when reading back from split branches. It is not clear to me from the cited document whether this is expected to work or not.

      Perhaps one way to make this work would be, when ever reading in an object of a class with some version captured by a #pragma read, to `force unsplit' the branch and always invoke the user defined code. Just my 2ยข

      Yours,

      Christian

        Attachments

          Activity

            People

            • Assignee:
              pcanal Philippe Canal
              Reporter:
              cholm Christian Holm Christensen
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: