Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: use podio::ObjectID::index in CalorimeterHitDigi #1600

Closed
wants to merge 2 commits into from
Closed

fix: use podio::ObjectID::index in CalorimeterHitDigi #1600

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
35f1f59
fix: use podio::ObjectID::index in CalorimeterHitDigi
wdconinc Aug 24, 2024
80042ee
fix: iwyu, reap what you sow
wdconinc Aug 24, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 2 additions & 4 deletions src/algorithms/calorimetry/CalorimeterHitDigi.cc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,7 @@
#include <algorithms/service.h>
#include <edm4hep/CaloHitContributionCollection.h>
#include <fmt/core.h>
#include <podio/ObjectID.h>
#include <podio/RelationRange.h>
#include <algorithm>
#include <cmath>
Expand Down Expand Up @@ -130,16 +131,13 @@ void CalorimeterHitDigi::process(

// find the hits that belong to the same group (for merging)
std::unordered_map<uint64_t, std::vector<std::size_t>> merge_map;
std::size_t ix = 0;
for (const auto &ahit : *simhits) {
uint64_t hid = ahit.getCellID() & id_mask;

trace("org cell ID in {:s}: {:#064b}", m_cfg.readout, ahit.getCellID());
trace("new cell ID in {:s}: {:#064b}", m_cfg.readout, hid);

merge_map[hid].push_back(ix);

ix++;
merge_map[hid].push_back(ahit.getObjectID().index);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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])?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see! Thanks for the clarifications @simonge and @wdconinc!

}

// signal sum
Expand Down
Loading