fix: use podio::ObjectID::index in CalorimeterHitDigi #1600
Conversation
github-actions
bot
added
topic: calorimetry
wdconinc
requested review from
a team and
ruse-traveler
and removed request for
a team
|
Capybara summary for PR 1600 |
| merge_map[hid].push_back(ix); | ||
|
|
||
| ix++; | ||
| merge_map[hid].push_back(ahit.getObjectID().index); |
There was a problem hiding this comment.
If the input hit collection is ever becomes a subset collection, e.g. through filtering the hits or merging other collection of hits this will stop working correctly. What could be neater, and safer to cover for these instances, is having a map to a vector of the hits themselves rather than indices?
There was a problem hiding this comment.
We were actually discussing a similar situation in the context of the track-cluster merge/splitter:
#1406 (comment)
So for my own understanding: if an input collection is somehow a subset (particularly if it's from merging other collections), is there a way to access specific members of that subset safely other than just insertion index (e.g. (*input_collect)[index])?
There was a problem hiding this comment.
Using the full objectID should be relatively safe. I am concerned it might stop being unique when we start moving between events/timeframes, particularly when collecting from several JEvents. My preferred alternative approach, which someone might tell me is bad practice, would be to have a map which uses the pointer to the hit itself as the key/value.
In this case e.g.
std::unordered_map<uint64_t, std::vector<edm4hep::SimCalorimeterHit*>> merge_map;
And in #1406
typedef std::map<edm4eic::ProtoCluster*, bool, CompareObjectID> MapToFlag;
I guess some downsides would be that the variable is linked to a type which using the ObjectID isn't. If there are other issues with this approach hopefully someone else can pitch in.
There was a problem hiding this comment.
Podio separates the user layer from the POD layer. Multiple user layer objects can refer to the same underlying POD data, in particular when they are a mutable and immutable user layer object. Storing a pointer to the user layer is therefore maybe not recommended.
|
Closing since pedantic and good arguments against this change brought forward in #1600 (comment). |
Briefly, what does this PR introduce?
Instead of using our own counting index in the loop, we should use the
podio::ObjectIDindex, which is semantically defined as the order in the collection. Reduces locals, but otherwise pedantic.What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
No.
Does this PR change default behavior?
No.