-
Notifications
You must be signed in to change notification settings - Fork 85
Open
Labels
bug (unverified)The problem described would be a bug, but needs to be triagedThe problem described would be a bug, but needs to be triaged
Description
Hello,
When trying to read a TTree with branches filled with custom classes in uproot, some branches are properly loaded while some failed with a cursor check error.
I assume it's a bug, but it may just be a limitation of uproot, I couldn't find documentation about uproot and custom classes.
You can find here the tests I did:
Python 3.10.14 (main, May 6 2024, 19:42:50) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import uproot
>>> uproot.__version__
'5.6.2'
>>> f = uproot.open("dummy.root")
>>> f["dummy"].keys()
['HKDummyV2.', 'HKDummyRecoV1.', 'HKDummyCollectionV2']
>>> f["dummy"]["HKDummyRecoV1."].array()
<Array [{m_vertex: {...}, ...}, ..., {...}] type='10 * HKDummyRecoV1[m_vert...'>
>>> f["dummy"]["HKDummyV2."].array()
...
uproot.deserialization.DeserializationError: while reading
HKDummyV2 version 1 as uproot.dynamic.Model_HKDummyV2_v1 (12 bytes)
HKDummy version 1 as uproot.dynamic.Model_HKDummy_v1 (6 bytes)
(base): <HKObject (version 1) at 0x782477548a00>
Base classes for HKDummy: (HKObject)
expected 6 bytes but cursor moved by 8 bytes (through HKDummy)
in file dummy.root
in object /dummy;1
>>> f["dummy"]["HKDummyCollectionV2"].array(library="np")
array([<STLVector [] at 0x72ebdadd3af0>, <STLVector [] at 0x72ebdadd39a0>,
<STLVector [] at 0x72ebdadd3340>, <STLVector [] at 0x72ebdadd39d0>,
<STLVector [] at 0x72ebdadd3f40>, <STLVector [] at 0x72ebdadd3430>,
<STLVector [] at 0x72ebdadd3d90>, <STLVector [] at 0x72ebdadd3df0>,
<STLVector [] at 0x72ebdadd3eb0>, <STLVector [] at 0x72ebdadd3e80>],
dtype=object)
The main difference between HKDummyReco and HKDummy is that HKDummyReco has some ROOT dependencies while HKDummy doesn't:
>>> f.file.show_streamers("HKDummyRecoV1")
ROOT::Math::Cartesian3D<double> (v1)
fX: double (TStreamerBasicType)
fY: double (TStreamerBasicType)
fZ: double (TStreamerBasicType)
ROOT::Math::DisplacementVector3D<ROOT::Math::Cartesian3D<double>,ROOT::Math::DefaultCoordinateSystemTag> (v1)
fCoordinates: ROOT::Math::Cartesian3D<double> (TStreamerObjectAny)
HKRecoBaseDirection (v1): HKObject (v1)
m_direction: ROOT::Math::DisplacementVector3D<ROOT::Math::Cartesian3D<double>,ROOT::Math::DefaultCoordinateSystemTag> (TStreamerObjectAny)
m_direction_goodness: double (TStreamerBasicType)
HKObject (v1)
HKRecoBaseVertex (v1): HKObject (v1)
m_vertex: ROOT::Math::LorentzVector<ROOT::Math::PxPyPzE4D<double> > (TStreamerObjectAny)
m_vertex_goodness: double (TStreamerBasicType)
HKDummyReco (v1): HKRecoBaseVertex (v1), HKRecoBaseDirection (v1)
HKDummyRecoV1 (v1): HKDummyReco (v1)
>>> f.file.show_streamers("HKDummyV2")
HKObject (v1)
HKDummy (v1): HKObject (v1)
HKDummyV2 (v1): HKDummy (v1)
m_a: int (TStreamerBasicType)
m_b: double (TStreamerBasicType)
m_c: double (TStreamerBasicType)
m_d: double (TStreamerBasicType)
HKDummyCollectionV2 is a vector of std::unique_ptr, uproot can deserialize the vector without issue but doesn't understand the std::unique_ptr, which I assume is expected.
What I assume is a bug is that reading HKDummyV2 fails whereas HKDummyRecoV1 seems to be read properly.
Metadata
Metadata
Assignees
Labels
bug (unverified)The problem described would be a bug, but needs to be triagedThe problem described would be a bug, but needs to be triaged