Dear @swenzel ,
During the digitization I loop over the entries in the event records and for each entry, I run over the parts.
If I understand correctly, the parts are made of signal and bkg. in the same event.
On the other hand, I would expect that different event records correspond to different interactions.
However, it seems that this is not always the case. For a small fraction of events, I have that: irecords[collID] = irecords[collID - 1]
where: auto& irecords = context->getEventRecords();
Is this the expected behaviour?
If so, can we assume that the records belonging to the same interaction are placed one after the other in the eventRecords or they can be non-sequential?
Thanks in advance,
best regards,
Diego
Do you mean irecords[collID] == irecords[collID - 1] aka you see the same interaction time assigned to both of them?
I think the requirement is that the records must be monotonically increasing in bunch crossing, time, etc. Maybe it is not required to be strictly increasing and equality just means extreme pileup. @shahoian can comment more.
Hi @dstocco
Since I wrote the interaction sampler, let me answer. entries in the std::vector<o2::InteractionTimeRecord> provided by the getEventRecords() are supposed to be unique and ordered in increasing time. Once in a while one can have 2 InteractionTimeRecord with same orbit/bc (i.e. same bc pile-up), but the time ( irecords[collID].timeNS) should differ as they are randomly drawn from the normal distribution of with sigma 200 ps around nominal BC.
If you observe 2 identical records, please send me the file.
Cheers,
Ruben
Hi @shahoian,
thanks for the info.
You can find an example file in: https://cernbox.cern.ch/index.php/s/VqjR1gAw1okZdey
I generated it with: o2-sim -g fwmugen -m MID -n 1000
on a MacOS 10.15.1 system.
The duplicated events are:
toLong timeNS
182222 4.54658e+06
340358 8.4922e+06
460360 1.14863e+07
514186 1.28293e+07
566716 1.414e+07
592624 1.47864e+07
691652 1.72573e+07
735222 1.83444e+07
Thanks!
cheers,
Diego
OK, I’ve generated it myself with your settings but what I see is the same BC pile-up with realistic collision time distribution around BC (in increasing order, as expected):
root [0] TFile *_file0 = TFile::Open("collisioncontext.root");
root [1] auto rr = (o2::steer::RunContext*)gFile->GetObjectUnchecked("RunContext");
root [2] auto& irv = rr->getEventRecords();
root [3] for (int i=1;i<irv.size();i++) { if (irv[i]==irv[i-1]) printf("%4d:%4d: Same BC %4d Orbit %4d (Long: %ld) | times(ns): %.9e %.9e %e\n",i-1,i, irv[i].bc, irv[i].orbit, irv[i].toLong(), irv[i-1].timeNS, irv[i].timeNS, irv[i].timeNS-irv[i-1].timeNS);}
211: 212: Same BC 458 Orbit 51 (Long: 182222) | times(ns): 4.546581803e+06 4.546582175e+06 3.724296e-01
398: 399: Same BC 1778 Orbit 95 (Long: 340358) | times(ns): 8.492199256e+06 8.492199333e+06 7.672119e-02
528: 529: Same BC 604 Orbit 129 (Long: 460360) | times(ns): 1.148634314e+07 1.148634337e+07 2.341604e-01
590: 591: Same BC 970 Orbit 144 (Long: 514186) | times(ns): 1.282934407e+07 1.282934432e+07 2.565887e-01
663: 664: Same BC 40 Orbit 159 (Long: 566716) | times(ns): 1.414000843e+07 1.414000890e+07 4.708687e-01
710: 711: Same BC 1000 Orbit 166 (Long: 592624) | times(ns): 1.478643369e+07 1.478643374e+07 5.304623e-02
832: 833: Same BC 236 Orbit 194 (Long: 691652) | times(ns): 1.725725995e+07 1.725726019e+07 2.371614e-01
885: 886: Same BC 1038 Orbit 206 (Long: 735222) | times(ns): 1.834436609e+07 1.834436618e+07 9.204638e-02
Hi @shahoian,
ok, I see: I was comparing the toLong() of the two records, but they actually have the same. When I printed the timeNS I got the same values, but it was just because the difference is very small and I did not print out enough digits.
In any case I think that the MID cannot distinguish the in-bunch pileup, so I will treat the events occurring in the same orbit+bc as if they were 1 single event.
Thanks a lot for the checks and info: it is clearer now!
OK, but they still will have different vertex, while all parts shipped for the single interaction record have the same vertex.
BTW, InteractionTimeRecord::operator==() inherits from InteractionRecord, which obviously compares orbit/bc only.