[ROOT-5831] Problem w/#pragma read and split branch Created: 11/Dec/13  Updated: 17/Dec/13  Resolved: 17/Dec/13

Status: Closed
Project: ROOT
Component/s: I/O
Affects Version/s: 5.34/00
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Christian Holm Christensen Assignee: Philippe Canal
Resolution: Fixed Votes: 0
Labels: None
Environment:

Debian GNU/Linux 'sid', GCC 4.8.2


Attachments: File pragma_read.tar.gz    
Development:

 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



 Comments   
Comment by Christian Holm Christensen [ 17/Dec/13 ]

Bumping severity in the hope of a response (and, it is actually somewhat important to get some resolution on this).

Comment by Philippe Canal [ 17/Dec/13 ]

> 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.

Unfortunately this is not possible (and would only be work-around the actual deficiency) as the read rule is (unlikely) to be present at the time of writing (which is the only time we can effect the split level).

Cheers,
Philippe

Comment by Philippe Canal [ 17/Dec/13 ]

> So I think that there's something wrong with the #pragma read functionality when it comes to
> TTree I/O and split branches

Yes, there is. The rule execution is associated with the last branch of the object and in your example is somehow (incorrectly) set not to be read ¿

Cheers,
Philippe.

Comment by Philippe Canal [ 17/Dec/13 ]

Hi,

This problem has been fixed in the v5.34 patch branch and in the trunk.

Cheers,
Philippe.

Generated at Wed Sep 18 16:00:32 CEST 2019 using Jira 7.13.1#713001-sha1:5e06076c2d215a6f699b7e5c90ab2fae7ba5a1ce.