Skip to content
Open
Changes from all commits
Commits
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
2 changes: 1 addition & 1 deletion Modules/GLO/src/VertexingQcTask.cxx
Original file line number Diff line number Diff line change
Expand Up @@ -215,7 +215,7 @@ void VertexingQcTask::monitorData(o2::framework::ProcessingContext& ctx)
mTimeUncVsNContrib->Fill(nContr, timeUnc);
mBeamSpot->Fill(x, y);

if (mUseMC && mcLbl[i].isSet()) { // make sure the label was set
if (mUseMC && mcLbl[i].isSet() && mcLbl[i].getSourceID() == 0) { // make sure the label was set and to use only the underlying event

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I have some doubts about this: In an O2DPG simulation when using embedding, we will have both SourceID == 0 (the background) and SourceID == 1 (the signal) ... and both might contribute to the vertexing task.

We could however use mcLbl.isNoise() or mcLbl.isValid() or something. ... or directly exclude QED by sourceID != 99.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

we do the same check also twice earlier in the function, when we loop over the labels. So for simulations with embedding, this never worked properly, then, always skipping signal and only filling background?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

or, is background == simulated events and signal == embedded signal in this case? Then we might not want the embedded signal in those histogram?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This particular task extracts the MCHeader multiplicity as a very crude alias of the occupancy, relevant only for the PbPb collision. Assuming that the underlying PbPb event is always source 0, a few tracks coming from the overlaid signal with source>0 should be irrelevant.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If it's only used for PbPb then it's probably fine

auto header = mMCReader.getMCEventHeader(mcLbl[i].getSourceID(), mcLbl[i].getEventID());
auto purity = mcLbl[i].getCorrWeight();
auto mult = header.GetNPrim();
Expand Down
Loading