juliaphysics / corpuscles.jl Goto Github PK

I am trying to access a spin of particle, but it does not seem to the in the structure

fieldnames(typeof(Particle(4222)))

gives

(:pdgid
:mass
:width
:charge
:isospin
:parity
:gparity
:cparity
:antiprop
:rank
:status
:name
:quarks
:latex
:glyph)

not sure what is the rank is

We already discussed this but somehow forgot to create an issue (let alone implement it 😉): helper functions like in the particle Python package, cf. https://github.com/scikit-hep/particle/blob/92610e8a73667b000906084a1bba3410ebc55d91/src/particle/particle/particle.py#L740 or https://github.com/scikit-hep/particle/blob/master/src/particle/pdgid/functions.py

Those helper functions are members of the Particle class or implemented in the pdgid submodule as simple functions of PDG IDs. For Julia we should rather go the functional way and focus on tiny helper functions which take Particle as input, like is_meson(p::Particle).

Let's collect and implement those functions. Suggestions are welcome!

Here is a list of some of the functions particle provide. I think we should try to adhere the naming convention to increase the interchangeability:

• is_quark
• is_lepton
• is_hadron
• is_meson
• is_baryon
• is_diquark
• is_nucleus
• is_pentaquark
• is_gauge_boson_or_higgs
• is_sm_gauge_boson_or_higgs
• is_generator_specific
• is_special_particle
• is_Rhadron
• is_Qball
• is_dyon
• is_SUSY
• is_technicolor
• is_composite_quark_or_lepton
• has_down
• has_up
• has_strange
• has_charm
• has_bottom
• has_top
• has_fundamental_anti
• charge
• threecharge
• A
• Z
• J
• S
• L
• jspin
• sspin
• lspin
• isvalid (PDGID)

I believe the units of the masses are not defined correctly.
Consider the following:

using NaturallyUnitful
using Corpuscles
Particle(211).mass.value + 0.5u"GeV/c^2"

This gives an error.

DimensionError: 139.57039 MeV and 0.5 GeV c^-2 are not dimensionally compatible.

Stacktrace:
 [1] +(x::Quantity{Float64, 𝐋^2 𝐌 𝐓^-2, Unitful.FreeUnits{(MeV,), 𝐋^2 𝐌 𝐓^-2, nothing}}, y::Quantity{Float64, 𝐌, Unitful.FreeUnits{(c^-2, GeV), 𝐌, nothing}})
   @ Unitful ~/.julia/packages/Unitful/JwSBO/src/quantities.jl:137
 [2] top-level scope
   @ In[64]:1
 [3] eval
   @ ./boot.jl:360 [inlined]
 [4] include_string(mapexpr::typeof(REPL.softscope), mod::Module, code::String, filename::String)
   @ Base ./loading.jl:1090

The unit of mass is not MeV, however, it's MeV / c^2, regardless of whether c^2 is one or not.

It is convenient to get particles by their string name rather then id
it would be nice to store the charge in the text identified.

For example:
I would like to call Sigma(c)(2455)+, Sigma(c)(2455)++, or Sigma(c)(2455)0.
Now, all of them are "Sigma(c)" in the list

filter(p->occursin(r"Sigma\(c*\)", p.name), particles())

I get a

WARNING: Method definition parse(Type{Base.Rational{T}}, AbstractString) where {T<:Integer} in module Base at rational.jl:98 overwritten in module Corpuscles at /user/.julia/packages/Corpuscles/0GLbd/src/Corpuscles.jl:32.
│    ** incremental compilation may be fatally broken for this module **

when Corpuscles.jl precompiles (Julia v1.9), because of

function Base.parse(::Type{Rational{T}}, val::AbstractString) where {T <: Integer}

in Corpuscles.jl:32 (which is obviously blatant type piracy :-) ).

@8me I invite you to join me writing a short JOSS paper for Corpuscles. This will go hand in hand with the release on Zenodo.

The SciKit-HEP guys also offer a nuclei table: https://github.com/scikit-hep/particle/blob/master/src/particle/data/nuclei2020.csv

We should add that.

The Python package particle combines everything into a single dataset, so that you can search via

from particle import Particle
Particle.findall()  # lists >6400 particles, including nuclei

I think we should put those in nuclei() or so, but I am not sure, since that makes things a bit more complicated when searching for a particle. We could however also do something like

isnuclei(p::Particle) = ... # 
nuclei() = filter(isnuclei, particles())

but this will re-execute the filter every time.

Can we change the names of charged pions to "pi+" and "pi-", and the neutral pion to "pi0"?
At the moment all three are "pi".

The behavior of Base.isless between a MeasuredValue and a Quantity is currently discussed, as its definition can lead to confusion in our eyes (@8me and @tamasgal).
The idea of the current implementation says, that the comparison has to be definitely correct to return true. In the following example

julia> p = Particle(-319)
Particle(-319) K(4)*(2045)

julia> p.mass
2048.0 MeV + 9.0 MeV - 8.0 MeV

it means

julia> p.mass > 2050u"MeV"
false

because the within the limits the particle can be greater (up to 2057MeV), but it is not sure. This handling leads on the other hand to:

julia> p.mass < 2050u"MeV"
false

because it is also within limits and no clear statement can be made. One option (beside not touching the current behavior) could be, to compare it directly to the mass value of the catalog and ignore the limits. But from my point of view there is a reason, why the values are coming with the limits .... so ... let the games, i.e. the discussion, begin! 😉

This seems not to work properly yet:

julia> filter(p->p.mass ≈ Particle(2212).mass, particles())  # using \approx
ERROR: MethodError: no method matching isapprox(::Corpuscles.MeasuredValue{𝐋^2 𝐌 𝐓^-2}, ::Corpuscles.MeasuredValue{𝐋^2 𝐌 𝐓^-2})
Closest candidates are:
  isapprox(::Missing, ::Any; kwargs...) at missing.jl:90
  isapprox(::Unitful.Quantity, ::Corpuscles.MeasuredValue) at /home/tgal/Dev/Corpuscles.jl/src/Corpuscles.jl:74
  isapprox(::Corpuscles.MeasuredValue, ::Unitful.Quantity) at /home/tgal/Dev/Corpuscles.jl/src/Corpuscles.jl:78
  ...
Stacktrace:
 [1] (::var"#55#56")(::Particle) at ./REPL[64]:1
 [2] filter(::var"#55#56", ::Array{Particle,1}) at ./array.jl:2347
 [3] top-level scope at REPL[64]:1

How to reproduce:

Particle(Int32(11))
KeyError: key PDGID(11) not found

Stacktrace:
 [1] getindex at ./dict.jl:467 [inlined]
 [2] Particle at /afs/desy.de/user/j/jstrube/.julia/packages/Corpuscles/1A3m1/src/Corpuscles.jl:121 [inlined]
 [3] Particle(::Int32) at /afs/desy.de/user/j/jstrube/.julia/packages/Corpuscles/1A3m1/src/Corpuscles.jl:122
 [4] top-level scope at In[55]:1
 [5] include_string(::Function, ::Module, ::String, ::String) at ./loading.jl:1091

I think the problem is that the constructor is defined as ::Integer instead of ::N where N<:Integer or something like that, but I'm not exactly sure.

Somehow the linking of the stable documentation points to 1.1.0 since I changed the CI to use GitHub instead of Travis. I could not figure out yet if it's a misconfiguration on our side or some kind of a bug in Documenter.jl, so I also opened an issue there: JuliaDocs/Documenter.jl#1488

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

We should submit a tiny entry, in case anyone finds this useful and considers an entry, in far future 😉

https://joss.theoj.org/papers/new