Event records in simulation

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 @swenzel,
yes, this is what I mean: they have the same orbit and bc.

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

Hi,
You’ve uploaded the o2sim.root, while I need the collisioncontext.root …

Hi @shahoian,
sorry about that: I’m sharing the full directory, so that you should have everything (including the collisioncontext):
https://cernbox.cern.ch/index.php/s/Fujl4VG8VfuG1S3
Thanks!

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.