Retroactively handling multiple Class versions in ROOT files

ROOT
41

I see the origin of the problem. The TClonesArray’s streamer is currently ignoring the hand set class name (and WCSimRootTrigger_v2 was not calling Initialize). I am looking of a solution.

42

thanks again. :bowing_man:

43

With https://github.com/root-project/root/pull/3987 and example.update.002.tar.gz (611.7 KB)
I am getting better results:

Processing script.C...
Warning in <TClass::Init>: no dictionary for class WCSimRootEvent is available
Warning in <TClass::Init>: no dictionary for class WCSimRootTrigger is available
Warning in <TClass::Init>: no dictionary for class WCSimRootGeom is available
Warning in <TClass::Init>: no dictionary for class WCSimRootPMT is available
Warning in <TClass::Init>: no dictionary for class WCSimRootOptions is available
Warning in <TClass::Init>: no dictionary for class WCSimRootEventHeader is available
Warning in <TClass::Init>: no dictionary for class WCSimRootPi0 is available
Warning in <TClass::Init>: no dictionary for class WCSimRootCapture is available
Warning in <TClass::Init>: no dictionary for class WCSimRootTrack is available
Warning in <TClass::Init>: no dictionary for class WCSimRootCherenkovHit is available
Warning in <TClass::Init>: no dictionary for class WCSimRootCherenkovHitTime is available
Warning in <TClass::Init>: no dictionary for class WCSimRootCherenkovDigiHit is available
Info in <TBufferFile::ReadObjectAny>: Using Converter StreamerInfo from TObjArray to TObjArray_wrapper
Info in <TBufferFile::ReadObjectAny>: Using Converter StreamerInfo from TObjArray to TObjArray_wrapper
Info in <TBufferFile::ReadObjectAny>: Using Converter StreamerInfo from TObjArray to TObjArray_wrapper
This entry had 1 triggers
Trigger time : 0
Number Primary Vertices : 1
Primary vertex 0 was at (-1.58819e-23, -1.58819e-23, -1.58819e-23)
Num Tracks: 3
Num Digits: 1935
Num Photons: 1935
    Track 0{ Flag: -1 | PDG: 11 | ParentPDG: 0 | sProc:  | eProc: NuIntx }
    Track 1{ Flag: -2 | PDG: 2212 | ParentPDG: 0 | sProc:  | eProc: NuIntx }
    Track 2{ Flag: 0 | PDG: 11 | ParentPDG: 0 | sProc:  | eProc: Cerenkov }
      digit 0 at time -0.417573ns has charge 1.49149 from 1 true photons
        digit 0, photon 0 has truetime 6.05443
      digit 1 at time 1.67687ns has charge 0.694754 from 1 true photons
        digit 1, photon 0 has truetime 5.41446
      digit 2 at time 2.0762ns has charge 1.27331 from 1 true photons
        digit 2, photon 0 has truetime 5.39229
      digit 3 at time 2.35291ns has charge 0.099146 from 1 true photons
        digit 3, photon 0 has truetime 5.22537
      digit 4 at time 3.14034ns has charge 0.767604 from 1 true photons
        digit 4, photon 0 has truetime 5.27153
      digit 5 at time 3.20434ns has charge 1.63413 from 1 true photons
        digit 5, photon 0 has truetime 5.44086
      digit 6 at time 3.57768ns has charge 1.11406 from 1 true photons
        digit 6, photon 0 has truetime 5.40951
      digit 7 at time 3.92938ns has charge 1.46568 from 1 true photons
        digit 7, photon 0 has truetime 5.27193
      digit 8 at time 4.32783ns has charge 1.11076 from 1 true photons
        digit 8, photon 0 has truetime 5.3451
      digit 9 at time 4.37274ns has charge 1.14471 from 1 true photons
        digit 9, photon 0 has truetime 5.18689
44

Thanks again, i’m hoping to try this ASAP, but i’m having some memory leak issues right now so things are a little up in the air. I’ll get back to you as soon as I’ve given it a try.

45

Hi Philippe,
I gave this a go and indeed I can reproduce what you’ve posted.

Unfortunately it seems there are still some differences with the expected output; for example the primary vertex is reported incorrectly, and the stopping energy and vertices of Tracks seem to be incorrect. Looking at the below word-diff between the obtained and expected output:

@@ -6 +5 @@ Number Primary Vertices : 1
Primary vertex 0 was at [-(0, -14.4649, 168.1)-]{+(-1.58819e-23, -1.58819e-23, -1.58819e-23)+}
@@ -10 +9 @@ Num Photons: 1935
    Track 2{ Flag: 0 | PDG: 11 | ParentPDG: 0 | sProc:  | eProc: Cerenkov | Start E: 500.511 | End E: [-500.278-]{+168.1+} | Start Vtx: [-(0,-]{+(208.814,+} 0, -14.4649, 168.1) | End Vtx: [-(0.00423116, 0.739235, -17.365, 208.814)-]{+(1.4013e-45, 0, 0, 0)+} }

You see the expected primary vertex is (0, -14.4649, 168.1), but the reported vertex is (-1.58819e-23, -1.58819e-23, -1.58819e-23)
(I would also accept (0, 168.1, 168.1) if the typo in WCSimRootTrigger_v2::Print()::253 isn’t fixed :slight_smile: )

Similarly, an example endpoint energy is : End E: [-500.278-]{+168.1+}
i.e. the stopping energy is expected to be 500.278, but is instead reported as 168.1 (which happens to be the primary vertex z position, incidentally), and the endpoint vertex is also different.

It’s very close! But, sadly, not quite close enough… :sob:

I also noticed that you (necessarily, it seems, else I get a segfault) added a call to Intialize() in the WCSimRootTrigger_v2 default constructor. As a comment in that default constructor points out:

// WARNING : default constructor for ROOT : do not allocate memory
// inside it or upon re-reading the object there will be a memory leak

so this doesn’t seem like something we would like to do… ?

48

@pcanal Any word? As before, not in a hurry, but it would benefit our analysis if we could support it.

49

Keep alive bump… :no_entry_sign: :coffin: