Add long-form names

[maxnoe]

Would be handy and intuitive (I just tried and was surprised this doesn't work), it also is inconsistent sometimes (I guess due to not requiring greek letters as input?):

In [30]: Particle.from_name('electron')
---------------------------------------------------------------------------
ParticleNotFound                          Traceback (most recent call last)
Cell In[30], line 1
----> 1 Particle.from_name('electron')

File ~/.local/conda/envs/cta-dev/lib/python3.11/site-packages/particle/particle/particle.py:1003, in Particle.from_name(cls, name)
   1001     return particle
   1002 except ValueError:
-> 1003     raise ParticleNotFound(f"Could not find name {name!r}") from None

ParticleNotFound: Could not find name 'electron'

In [31]: Particle.from_name('proton')
---------------------------------------------------------------------------
ParticleNotFound                          Traceback (most recent call last)
Cell In[31], line 1
----> 1 Particle.from_name('proton')

File ~/.local/conda/envs/cta-dev/lib/python3.11/site-packages/particle/particle/particle.py:1003, in Particle.from_name(cls, name)
   1001     return particle
   1002 except ValueError:
-> 1003     raise ParticleNotFound(f"Could not find name {name!r}") from None

ParticleNotFound: Could not find name 'proton'

In [32]: Particle.from_name('gamma')
Out[32]: <Particle: name="gamma", pdgid=22, mass=0.0 MeV>

[eduardo-rodrigues]

Hi. This would not be so helpful, actually. What you call long names, or "names as we refer to some particles as we speak", are only possible for the most common particles, which are the proton, neutron, electron, muon and tau. Already here some people talk about the tauon - maybe a detail - and such a name would say nothing about the charge. If you would go ahead and add a new "property" long_name, what would that be for the bosons and in particular for all the excited mesons, etc.? Think of a D(s2)*(2573)+ or alike. For that we actually define literals, which can be programmatic names and sort of solve the problem for all particle names ...

You have to recall that the various names we define either are defined by the PDG, and we hence need to abide to that, or else are extensions for very needed names in programs, as the EvtGen names. Here are a few examples for those common particles you seem to be interested in:

In [11]: for p in Particle.finditer(lambda p: p.pdgid.is_lepton):
    ...:     print(f"name={p.name} \t pdg_name={p.pdg_name}")
    ...:
name=e-          pdg_name=e
name=e+          pdg_name=e
name=nu(e)       pdg_name=nu(e)
name=nu(e)~      pdg_name=nu(e)
name=mu-         pdg_name=mu
name=mu+         pdg_name=mu
name=nu(mu)      pdg_name=nu(mu)
name=nu(mu)~     pdg_name=nu(mu)
name=tau-        pdg_name=tau
name=tau+        pdg_name=tau
name=nu(tau)     pdg_name=nu(tau)
name=nu(tau)~    pdg_name=nu(tau)
name=tau'-       pdg_name=tau'
name=tau'+       pdg_name=tau'
name=nu(tau')    pdg_name=nu(tau')
name=nu(tau')~   pdg_name=nu(tau')

In short, you cannot add long names for just the 1% of the particles (much less if you include the nuclei) and I do not see anything reasonable or useful anyway. Can you tell me the motivation?

Feel free to close if you agree with my analysis. Thanks anyway; always good to discuss with users :-).

[eduardo-rodrigues]

I forgot to say - "gamma" works because it is the name and PDG name (typically a short version with no charge) for the photon. BTW, this exemplifies even further the issue because then you would also want to allow for the name "photon".

On the other hand would the long name of the Z boson be "Z-boson", or "Z boson"? You would be opening a can of warms, really, for no real use/gain.

[maxnoe]

Can you tell me the motivation?

Nothing more complex than a naive user trying to do Particle.from_name("proton") and expecting it to work.

are only possible for the most common particles

Which is 99.9% of the particles people would like to use Particle.from_name for I guess.

I couldn't figure out any way to get the proton and the neutron with Particle.from_name, which is I have to say, more than just mildly frustrating.

[eduardo-rodrigues]

Maybe the issue is more about the documentation? Again, some special particles are, well, special, but then do you say tau ,tauon, tau lepton, tau-lepton (just picking one example of another popular particle) ;-).

Would it help if I updated the name property docstring from "The nice name, with charge added, and a tilde for an antiparticle, if relevant." to for example "The particle name as in the PDG, with charge added, and a tilde for an antiparticle, if relevant.",?

[maxnoe]

I think the issue is not about the doc-string, but about user's expectation when seeing a very general sounding method like from_name. I think it's natural to expect that to support the most commonly used name for one of the most important particles.

If it was from_pdg_name, the expectation would probably be that it only has support for some very particular naming scheme.

[eduardo-rodrigues]

I couldn't figure out any way to get the proton and the neutron with Particle.from_name, which is I have to say, more than just mildly frustrating.

It can be frustrating but funny enough I never got the issue raised in all these years. I will reply on that one soon, though Hans already sourced the issue. I agree one should have a special handling for the 2 only special particles that can be defined with 2 PDG IDs, since particles and also nuclei.

[eduardo-rodrigues]

If it was from_pdg_name, the expectation would probably be that it only has support for some very particular naming scheme.

Life is never so easy - if you want to be consistent then from_pdg_name, which I agree sounds nice, would not be OK because the PDG name does not have the charge included! I either have to be consistent, and have features as this one you raise, or be inconsistent with the PDG, which I think is not viable. You need to look from both perspectives, not just from the side of a "naive user", and a naive user needs to be educated to be less naive and understand what they are dealing with, and why things are the way they are.

[maxnoe]

Maybe a bit more context on what this triggered: we are thinking about representation of particles in CTAO data models and chose the pdgid. This leaves us to figure out interfaces to the software using different schemes, e.g. CORSIKA 7 (using the scheme now also implemented here) and just plain text configuration files using mostly

• proton
• gamma
• electron
• muon (not really clear if that should be mu+ or mu-, but that's an issue for us...)
  and names for the most common nuclei.

My first tries for adding the conversion from strings were to do Particle.from_name, which lead me to the discovery of the issues with the proton...

[eduardo-rodrigues]

One could easily add some special code to make from_name("proton") work (and others), but then "proton" would not appear as a Particle name/property, and special cases would be needed for other methods as well. I just don't see this viable.

[eduardo-rodrigues]

Now, for example my experiment, LHCb, also has some "funny" naming scheme - I never understood why - that departs for EvtGen names (these are very important for flavour physics) and PDG names. There is a little lhcb specific module for that, because it did not make sense to expose something sort of internal to everyone. You could have something special if there is need ...

[eduardo-rodrigues]

I now see better your needs. I won't claim that the conversions are the best possible (in fact there are suggestions around for improvements around this "area" - #427) but that might be a good option to you?

[eduardo-rodrigues]

I will reply to the rest of your issues by the end of the week. Let me know if you see any possible route here, else we close and sort the other feature, which is important. Thanks.

[maxnoe]

One could easily add some special code to make from_name("proton") work (and others), but then "proton" would not appear as a Particle name/property.

You mean that:

>>> p = Particle.from_name("proton")
>>> p.name
"p"

?

That might be confusing, yes.

[eduardo-rodrigues]

Yep, exactly.

[eduardo-rodrigues]

I think this is now settled, hence closing. (But please reopen if you see a path forward.)