Isospin for photons?

[tamasgal]

The isospin I of photons is returning <2. It's bit confusing since isospin is related to strong interactions and W for example has no entry in the raw CSV file.

The <2 seems to refer to a "weak isospin" which has an unfortunate naming and the same symbol I. Wondering how this could be cleaned up a little bit? For the Julia implementation we try to fix the types and the photon is the only exception.

I guess you also had a discussion before you decided to put a <2 into the CSV I column? 😉

>>> from particle import Particle
>>> g = Particle.from_pdgid(22)
>>> g.I
'<2'

[eduardo-rodrigues]

Thanks for spotting this! The short answer is that it's for sure not meant to be returning <2. The longer answer (with explanations) will have to wait until I get back online with more time … later tonight, I guess ;-).

[tamasgal]

OK, credits for spotting it goes to @8me btw. ;)

[eduardo-rodrigues]

So, the longer explanation. As you've probably seen by now, the package provides a curated version of the PDG .mcd file, with a lot of functionality and goodies. As far as particle information is concerned, we provide extended info making use of an extended file the PDG released back in 2008, see https://github.com/scikit-hep/particle/blob/master/particle/data/mass_width_2008.fwf. Clearly, a lot has changed since then, from particle data to PDG IDs, etc., which explains why we've had to prepare an extension (with bug fixes) to the extended file, see https://github.com/scikit-hep/particle/blob/master/particle/data/mass_width_2008_ext.fwf. Nothing of this matters to the user, of course, given that the user "interacts" behind the scenes with a curated CSV file.
I have no idea why the PDG set the photon isospin to <2. This I'm going to fix asap. I will also try and see if other particles need a hotfix ...

Beyond the hotfix: note that we have it on the to-do list to simplify things, as the extension to the extended file became rather large by now, see #118. As this is gymnastics it's been on a lower priority. I hope to get to this at some point in early 2020 at the latest …

As always, the more eyes and/or users one gets, the better the package 👍 ! Thanks to you and @8me.

[tamasgal]

I see, thanks for the explanation! Starting to get a good overview about the structure, which of course helps a lot to provide a Julia package with similar functionality.
It's also already more than obvious that this is not just a simple CSV -> Python class thingy ;)

I'll definitely add this project as a dependency to our Python framework to have something solid (and to promote it in our collaboration), we only have a dead simple mapping of a few particles (from PDG to Geant), since well... we mostly need photons, neutrinos, and their charged bros and sis ;)

[8me]

Thanks for the explanation from my side, too! 👍

[eduardo-rodrigues]

BTW, there is another issue with the isospin data, which we clearly didn't play much with: the return type is a string, whereas we should be returning a float or None as for example for the spin J. I have a week of meetings so may not be as fast as possible, but will get this sorted urgently/asap.

FYI @henryiii.

[tamasgal]

Yep, not sure if it's interesting for you but we solved it in Julia with the following struct:

struct ParticleInfo
    mass::MeasuredValue{Float64}
    width::Union{Missing, MeasuredValue{Float64}}
    charge::Rational{Int8}
    isospin::Union{Missing, Rational{Int8}}
    parity::Union{Missing, Int8}
    gparity::Union{Missing, Int8}
    cparity::Union{Missing, Int8}
    antiprop::InvProperty
    rank::Int8
    status::PDGStatus
    name::String
    quarks::String
    latex::String
end

[eduardo-rodrigues]

I'll definitely add this project as a dependency to our Python framework to have something solid (and to promote it in our collaboration), we only have a dead simple mapping of a few particles (from PDG to Geant), since well... we mostly need photons, neutrinos, and their charged bros and sis ;)

Cool, that's appreciated. What/where is your framework? BTW, if some of Scikit-HEP ever makes it into the official externals of KM3NeT we would be honoured and super happy to know, to advertise it at http://scikit-hep.org/projusers ...

[eduardo-rodrigues]

Yep, not sure if it's interesting for you but we solved it in Julia with the following struct:

Neat! I have implemented a simple converter following what we have. I will commit later today.

[tamasgal]

Cool, that's appreciated. What/where is your framework? BTW, if some of Scikit-HEP ever makes it into the official externals of KM3NeT we would be honoured and super happy to know, to advertise it at http://scikit-hep.org/projusers ...

Oh yeah!
Here it is: https://github.com/KM3NeT/km3pipe (it's a mirror from our main repo https://git.km3net.de/km3py/km3pipe) it's pretty much tailored to KM3NeT and mostly focuses on specific I/O, database access and pipelines so the main purpose is the bridge to the scientific Python world.

particle fits perfectly fine here and it will definitely be integrated to replace our hackish dictionary 😅 (https://git.km3net.de/km3py/km3pipe/issues/188)

If it's OK for you, you can even mention the connection to Julia-HEP with the particle equivalent Julia package, using your data!

[tamasgal]

Btw. we already work on a small I/O wrapper for our ROOT files, based on uproot, so the it's already a double bond to scikit-HEP ;) https://github.com/KM3NeT/km3io

[eduardo-rodrigues]

Brilliant, I will then keep an eye on this things and will add the info on the website once the updates make it to the official repo. So far I've been asking permission to the experiment computing coordinators to splash the info on the website. Maybe I will need to do the same for KM3NeT …
Thanks for all the info and glad to collaborate!

[tamasgal]

OK nice :) Feel free to drop a mail to Paschal (https://www.km3net.org/about-km3net/collaboration/contact/) and just CC me (tgal@km3net.de).

particle is now used in km3pipe and will also be part of the upcoming KM3NeT bootcamps. As mentioned, uproot is already in use!

[eduardo-rodrigues]

I will do that tomorrow.

Oh, I had misunderstood that uproot is already in use Brilliant. Thanks a lot!

[tamasgal]

Well, I was a bit unclear: it's in early development phase but people are impatient and already using ;) It's versioned and tested, so that's fine (the API will change and many features are missing, but everyone knows this 🙈 )

[eduardo-rodrigues]

Email sent out. Thanks again!