[PWGJE] Task for hadron-jet correlations in O-O collisions #8688
Conversation
KotliarovAr
requested review from
alibuild,
maoyx,
nzardosh,
fjonasALICE,
mfasDa and
mhemmer-cern
as code owners
PWGJE/Tasks/jetHadronRecoil_OO.cxx
Outdated
| bool skipEvent(const Collision& coll) | ||
| { | ||
| /// \TODO: Do need !jetderiveddatautilities::selectTrigger(collision, triggerMaskBits) flag to skip an event? | ||
| return !coll.selection_bit(aod::evsel::kNoTimeFrameBorder) || !jetderiveddatautilities::selectCollision(coll, eventSelection); |
There was a problem hiding this comment.
hi Artem, isnt the NoTimeFrameBorder cut already included in sel8?
For this one selection this means that you are not fully using the derived data and are instead relying on the evsels table which we should find a way of avoiding. If the timeframe border cut is not included we can add this as a selection in the jet framework that can be accessed with jetderiveddatautilities::selectCollision
There was a problem hiding this comment.
Hi Nima,
It seems you are right, we should have the kNoTimeFrameBorder flag in the sel8 selection (slide 9: https://indico.cern.ch/event/1425820/contributions/6139628/attachments/2946808/5179269/2024Oct14_AnTutorial_AOT.pdf)
The same cut actually is used in the Trigger QA task. Is it a critical issue? Should I fix it immediately or in the next PR?
There was a problem hiding this comment.
If you could fix it now it would be great, because i think this way if you remove the need for it then you can remove the dependency on the Event selection tables and then you can run directly on the JE derived data
PWGJE/Tasks/jetHadronRecoil_OO.cxx
Outdated
| std::tuple<double, bool> isRecoilJet(const Jet& jet, | ||
| double phi_TT) | ||
| { | ||
| double dphi = fabs(TVector2::Phi_mpi_pi(jet.phi() - phi_TT)); |
There was a problem hiding this comment.
for this use the RecoDecay::constrainAngle function
There was a problem hiding this comment.
Added
Interesting to know why we should use RecoDecay::constrainAngle instead of TVector2::Phi_mpi_pi?
There was a problem hiding this comment.
recodecay is the official place where these operations are done so the recommendation from O2 is to use that where possible. @vkucera can comment more
There was a problem hiding this comment.
@KotliarovAr O2 is C++ code, not ROOT code. There is no reason to use ROOT features if equivalents exist in standard C++ or O2.
|
Error while checking build/O2Physics/o2 for 06a4913 at 2024-12-05 07:30: Full log here. |
|
My final comment is, why do you call this task OO? In principle it can be used for any system right? It would be good to rename it |
You are right, the code can be also used for pp collisions. However, there is a similar code for h+jet analysis written by Danny and Jaime, which analyses in addition WTA jet axis. So, renaming could confuse. |
It would be good if we could find a different name than OO though to make them distinct. |
A new task designed to study hadron-jet correlations in the upcoming OO collisions.
Dear @nzardosh,
Could you review the code? Also, I want to ask 2 questions:
we discussed some time ago that the JE framework does not contain functionality to estimate rho background for particle level MC. Do we plan to add such functionality?
when we want to get a weight for MC detector level simulations, we use
auto weight = collision.mcCollision().weight(). There is a function that checks whether a collision has an associated MC collision:collision.has_mcCollision(). So, not all detector-level collisions have associated particle-level collisions? Are we protected from the output not being garbage due to the absence of the associated MC collision when callingcollision.mcCollision().weight()? Should we also introduce a check (collision.has_mcCollision()) that discards the MC detector level collisions, which do not have associated MC particle level collisions?