Allow nuclei PID

[RDupre]

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).

[kkauder]

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?

[RDupre]

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, [ https://github.com/eic/eic-smear/issues/6#issuecomment-696139503 | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/ABUWUOPTOWRIHPKBPC4ALWDSG5NFPANCNFSM4QYL254A | unsubscribe ] .

[kkauder]

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         1   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.

[RDupre]

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 https://github.com/eic/eic-smear/issues/6#issuecomment-696335585, 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