-
Notifications
You must be signed in to change notification settings - Fork 11
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
Allow nuclei PID #6
Comments
A few questions/issues (sorry if some seem obvious to you):
|
Hello,
Traditionally, the variables like x, y or W are often calculated using the nucleon mass and the energy per nucleon, not the one of the full nuclei. I would advise to do this way, but with a warning somewhere informing of this convention.
I would assume most people will only be interested in nuclei up to helium-4. Another point that might help, is that I know only of people interested in detecting these in the far forward detector. I do not know if that is relevant for you.
Best,
…---
Raphaël Dupré
Laboratoire de Physique des 2 Infinis Irène Joliot-Curie
CNRS - IN2P3
Université Paris-Saclay
De: "kkauder" <notifications@github.com>
À: "eic/eic-smear" <eic-smear@noreply.github.com>
Cc: "dupre" <dupre@ipno.in2p3.fr>, "Author" <author@noreply.github.com>
Envoyé: Lundi 21 Septembre 2020 16:10:31
Objet: Re: [eic/eic-smear] Allow nuclei PID (#6)
A few questions/issues (sorry if some seem obvious to you):
*
For incoming beams, what are the relevant kinematic variables, and how should they be calculated? i.e., x, Q^2, y, W, ...
*
For outgoing final state hadrons, there will be a problem if you want eic-smear to act smearing on them: Most acceptance functions, such as charge, genre, ... are currently hard-coded to expect a small range of possible pdgs. That either needs a significant refactorization to make use of some pdg data base (thus also expanding the prerequisites of eic-smear), or hand-coded additions to detector scripts. Do you foresee a wide range of ions in the final state, and the need to do fast smearing on them, or is your main interest just in having a root tree of the MC truth?
—
You are receiving this because you authored the thread.
Reply to this email directly, [ #6 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABUWUOPTOWRIHPKBPC4ALWDSG5NFPANCNFSM4QYL254A | unsubscribe ] .
|
Thanks Raphael! To your first point, in that case I do need a designated "beam nucleon" as well. One option: Expand your output format to something like:
Only with correct masses etc. It would be a minor headache in that it deviates from the standard meaning of the first 3-4 lines, but nothing that can't be overcome. Is that a possibilty? To your second point, both of those facts help significantly, either one could be enough to solve. Adding three or four pdgs (D, T, 3He, 4He, am I forgetting something?) to the framework is easy enough, but so would be explicitly adding these as accepted particles to just one group of detectors in the forward region, thus avoiding changes to the actual framework. |
Hello,
That is problematic as in coherent processes, you do not really hit a
defined nucleon. So what you are proposing would be a hack which would
not reflect what is actually in the generator and in my opinion that
could be misleading to users later on. For this, I would rather just
divide the mass of the nuclei by A and use this as the "nucleon" mass.
Looking at the energy and momentum, I just notice in the example, the
beam energy/momentum is "incorrect" since it is given per nucleon. Here
as well some convention has to be taken. Almost every one uses energy
per nucleon for the beam as in the file, but for produced particles I am
less sure this convention is shared as widely... Again, we just have to
be careful to document clearly what convention we are using, for me it
is no problem to change from one to another.
Best,
Le 21/09/2020 à 21:51, kkauder a écrit :
…
Thanks Raphael!
To your first point, in that case I do need a designated "beam
nucleon" as well. One option: Expand your output format to something like:
|============================================ 1 21 1000020040 0 3 0 0 0
109.937 110 3.72744 0 0 0 2 21 11 0 4 0 0 0 -18 18 0.000511 0 0 0 3 21
2112 0 6 0 0 0 109.937 110 3.72744 0 0 0 4 1 11 2 0 0 0.462735
-0.546598 -3.65933 3.72875 0.000511 0 0 0 5 1 22 0 0 0 -0.471998
0.53753 -14.297 14.3149 0 0 0 0 6 1 1000020040 3 0 0 0.00926373
0.00906826 109.893 109.957 3.72757 0 0 0 |
Only with correct masses etc. It would be a minor headache in that it
deviates from the standard meaning of the first 3-4 lines, but nothing
that can't be overcome. Is that a possibilty?
To your second point, both of those facts help significantly, either
one could be enough to solve. Adding three or four pdgs (D, T, 3He,
4He, am I forgetting something?) to the framework is easy enough, but
so would be explicitly adding these as accepted particles to just one
group of detectors in the forward region, thus avoiding changes to the
actual framework.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUWUOOBZ2LUZFUGXMBHQHDSG6VETANCNFSM4QYL254A>.
--
Raphaël Dupré
Laboratoire de Physique des 2 Infinis Irène Joliot-Curie
CNRS - Université Paris-Saclay
|
It would be very helpful to allow for nuclear beam and particles in general. I assume numerous exclusive and tagged processes (coherent and incoherent) on nuclei will need this beam functionality to run tests with the far forward detectors.
The usual PDG code for those is as follow 100ZZZAAA0 (1000020040 for helium-4 for instance).
The text was updated successfully, but these errors were encountered: