Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Lambda reconstruction in ZDC #1731
base: main
Are you sure you want to change the base?
Lambda reconstruction in ZDC #1731
Changes from 19 commits
93f65f8
e2e011a
6804919
b3477d8
36c0b1a
89c050b
cefdbcb
c435616
ed821c9
a820190
3595a61
0a75b7c
b9886c5
1e89caa
e8f2042
ddb6aac
ef5fafa
061b0b6
5ba6825
24abf91
9c2913c
48e2441
7cdd67e
e51f411
2933e72
05cf862
18c724a
5d9a79b
a23b8de
0bf64b0
4bea111
05bdb57
e3d668d
ad26945
6207ff5
fa38f68
1ee3062
a4053ff
7b96b5d
ab47825
063923a
aed06ff
e1a585d
a999b61
5b143eb
0133331
f4f1849
ebbf118
f1aff47
1c44bb9
96d9d72
b78a524
ed93985
939ef9e
044fea6
8855bbe
45aa86b
c3bbcd2
1400083
e1c8ae7
3a21bf8
a9e5879
ed1cd8f
1b5d0ad
e012ead
c038256
12912b7
450ad62
18e1977
6bdf357
5bd9f90
d11fd82
a505c0c
89b4f95
e8f158a
351f7c4
0c5bc84
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Rather than duplicate collections (since the decay products here will be a subset of the input collections), I think there are a couple approaches that might be more natural here! And this actually raises a point I don't think we've fully discussed with the PWGs: how do we handle decay products in our data model?
The 1st approach (and the one I'd suggest going with now) would be to utilize the one-to-many relations between
ReconstructedParticle
and otherReconstructedParticle
s:The 2nd would be to have a
ReconstructedParticle
-to-ReconstructedParticle
association to keep track of parent-to-decay relations.Sidebar: speaking personally, I'm in favor the 1st approach since I tend to conceptualize identifying resonances as "re-combining" their decay products, and since reconstruction goes in reverse time-ordering in a certain sense (earlier stages of the collision are reconstructed later in the algorithmic chain).
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'd have to think about this. The way this works right now is that we have a collection of neutrons and photons (which I have now merged) in the lab frame, and the output is a collection of lambdas in the lab frame, and a collection of lambda decay products in the lambda CM frame. Is it possible to have the lambda reconstruction modify the particles in the input collection (ie, change their reference point to where the reconstructed lambda decayed, and the momentum direction to point to this point)? Still, I would like some way to store the direction of the neutron in the lambda's CM frame, since that's important for polarization measurements ... not sure the best way to do this.
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.
Ahhh, I see. Unfortunately, you won't be able to modify the input collections since collections are immutable. But I think there's a couple of ways we could go about this!
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 kinematics of the decay products are not the same as the ones from the neutrals reconstruction, since the vertex position is no longer assumed to be at the origin (so the direction of their momenta changes when doing this).
I think I have found a work-around here. I am storing the CM-frame decay products in the same collection as the lambdas, and then adding these particles to the list of particles associated with the lambda.
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.
Please don't do that: that runs counter to all other reconstructed particle collections, and will make things confusing by mixing different levels of information in a single branch (the resonance vs. the decay products).
If you have the production vertex, the original momenta (wrt. the origin) of the decay products, and the lambda momentum, wouldn't it be straightforward enough to do the transformation downstream? Either in an analysis script or in subsequent algorithm?
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.
So I've been mulling it over, and wanted to clarify my thoughts here:
PseudoCluster
)What are your thoughts, @veprbl and @wdconinc? How do the FCC folks typically handle situations like this?