-
Notifications
You must be signed in to change notification settings - Fork 615
[PWGHF,PWGJE,Trigger] Divide candidate data model into skimming, reconstruction, aliases #13503
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.
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
Conversation
|
O2 linter results: ❌ 112 errors, |
| /// \author Gian Michele Innocenti <gian.michele.innocenti@cern.ch>, CERN | ||
| /// \author Vít Kučera <vit.kucera@cern.ch>, CERN | ||
|
|
||
| #ifndef PWGHF_DATAMODEL_CANDIDATESKIMMINGTABLES_H_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would refrain from using the term "skimming" to avoid confusion, since in ALICE skimming is referring to the software triggers (I know that we called "skimCreator" our HF vertex finder, but this would also not be a proper name, since we are not skimming anything, but actually adding information to the AO2Ds). I propose to use the TrackIndexSkimCreatorTables.h or something similar, to make it a bit more clear that it refers to the trackIndexSkimCreator task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The name is neither
AliceSkimmingTables.hnorSkimmingTables.h, it'sCandidateSkimmingTables.h. I think that makes the context clear enough. - Why do you say that we are not skimming anything? We are skimming the combinations of track indices which are our decay candidates.
- Is
TrackIndexSkimmingTables.hfine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's not "skimming" because if it was it, it would imply a reduction of the information while in our case we add the information of candidates starting from tracks (so it's vertex finding, similar to the SVertexer in the reconstruction). In any case I think that TrackIndexSkimmingTables makes it less ambiguous, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Renamed
- I always understood the "track index skimming" in the meaning of to read or consider something quickly in order to understand the main points, without studying it in detail, i.e. to scan the track table and save the decay candidate combinations without doing the full candidate reconstruction. I don't know what other meaning, that involves reduction of information, people have in mind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fgrosa Good to merge?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vkucera good for me, thanks!
…nstruction, aliases (AliceO2Group#13503)
…nstruction, aliases (AliceO2Group#13503)
Move parts of
PWGHF/DataModel/CandidateReconstructionTables.hinto:PWGHF/DataModel/CandidateSkimmingTables.hPWGHF/DataModel/AliasTables.hPWGHF/Core/DecayChannelsLegacy.hPWGHF/ALICE3/Core/DecayChannelsLegacy.hThe goal is to factorise header dependencies and to reduce recompilations when modifying parts of the data model.