scikit-hep

[DavidMStraub]

@peterstangl, in feedback from a talk at PyHEP, scikit-hep's https://github.com/scikit-hep/decaylanguage and https://github.com/scikit-hep/particle have been mentioned as projects that flavio could profit from. Would be interesting, e.g. to get rid of this.

[eduardo-rodrigues]

Thanks for this follow-up. I'm happy to help. BTW, I'm working on improving Particle so you should let me know what you need in case there are things not there yet ... (Probably the biggest change to come is that I'm adding "all" particles for which the PDG does not give info in their downloadable file, so BSM, etc. A lot is there in a way, but not via the trivial and common usage.)

[eduardo-rodrigues]

BTW, great PyHEP 2020 presentation with many thoughts straight to the point. I think you hit the right mode for such a keynote presentation. Thanks again for participating!

[peterstangl]

@DavidMStraub thanks for the suggestion! It looks like the Particle package would really be a perfect replacement for the functions currently used for reading particle masses and widths from the PDG.
@eduardo-rodrigues thank you for offering your help! One thing I was wondering is whether Particle always provides the most recent PDG data or if it is also possible to get older PDG data, e.g. from a given year. This would be useful if we want each version of flavio to use a fixed set of input parameters (in order to facilitate reproducibility).

[eduardo-rodrigues]

Hello @peterstangl. By default Particle provides the most recent PDG data file, which is presently the one from 2019, see https://github.com/scikit-hep/particle/tree/master/src/particle/data. I now checked and the 2020 PDG file is actually available, see http://pdg.lbl.gov/2020/mcdata/mass_width_2020.mcd, hence I will make it soon available in Particle.

This being said, the package internally uses an extended file prepared by us, which contains more info than what the PDG .mcd file contains. That's the particleYYYY.csv file under the same location. The standard user never has to care about or interact with the CSV file(s).

I did a clean-up recently and only left in the package the data corresponding to 2018. We could provide older files for convenience ... Just let us know.

In any case, it is easy to do a custom loading. For a standard usage do for example

In [1]: import particle
In [2]: particle.__version__
Out[2]: '0.10.0'
In [3]: from particle import Particle
In [4]: Particle.table_loaded()
Out[4]: True
In [5]: Particle.table_names()
Out[5]: ('particle2019.csv', 'nuclei2020.csv')

If you want the 2018 just do

In [1]: from particle import Particle, data
In [2]:  Particle.load_table(data.open_text(data, "particle2018.csv"))
In [3]: Particle.table_names()
Out[3]: ('C:\\home\\sw\\Anaconda3\\lib\\site-packages\\particle\\data\\particle2018.csv',)
In [4]:  Particle.load_table(data.open_text(data, "nuclei2020.csv"), append=True) # I still want nuclei info
In [5]: Particle.table_names()
Out[5]:
('C:\\home\\sw\\Anaconda3\\lib\\site-packages\\particle\\data\\particle2018.csv',
 'C:\\home\\sw\\Anaconda3\\lib\\site-packages\\particle\\data\\nuclei2020.csv')

I realise that not everything is presented in the README nor in the notebook, but there's a lot that one can do ;-).

Let's keep in touch. I would love to see flavio use Particle, thereby connecting better the work that's being done by HEP theorists and experimentalists.

[peterstangl]

@eduardo-rodrigues thank you very much for your detailed answer! I think the custom loading as you describe it is exactly what we need. I don't think we would need older files, I just wonder how long a given file would be included in Particle. In any case, I would implement the custom loading with a try and except and issue a warning if one tries to use a too old version of the PDG that is not supported by the then current version of Particle anymore.

Another thing I was thinking about is the naming of particles. flavio uses its own names, which are translated from the PDG names using a simple dictionary:

flavio/flavio/parameters.py

Lines 101 to 125 in b91383c

	# dictionary translating PDG particle names to the ones in the code.
	pdg_translate = {
	'B(s)': 'Bs',
	'B(c)': 'Bc',
	'D(s)': 'Ds',
	'B(s)*': 'Bs*',
	'D(s)*': 'Ds*',
	'D*(2007)' : 'D*0',
	'D*(2010)' : 'D*+',
	'J/psi(1S)': 'J/psi',
	'K(L)': 'KL',
	'K(S)': 'KS',
	'K*(892)+': 'K*+',
	'K*(892)0': 'K*0',
	'phi(1020)': 'phi',
	'rho(770)0': 'rho0',
	'rho(770)+': 'rho+',
	'f(0)(980)': 'f0',
	"eta'(958)": "eta'",
	'omega(782)': 'omega',
	'Lambda(b)' : 'Lambdab',
	'Lambda(c)' : 'Lambdac',
	'Higgs' : 'h', # this is necessary for the 2013 data file
	'H' : 'h',
	}

I saw that Particle also implements conversions between names used in different codes. So I was wondering whether it could make sense to add the flavio names directly in Particle or if it would be better to do the conversion inside flavio. An argument for the latter option would be that flavio only defines names for a small subset of the particles in the PDG data.

[eduardo-rodrigues]

By default I think it is reasonable to have in any given release the latest (year) file as default and also keep available the file from the year before. For some previous years it would not quite make sense to make them available because of changes upstream by the PDG, such as changes in PDG IDs - it would be messy and potentially confusing for users.
Now, within our capacities, it is clear that we will keep files available as long as they are requested by users, especially if the "users" are in fact packages users. So do feel free to list your needs ...

As for the special particle names: I would also prefer not to have those flavio-specific names in Particle just because they are only defined for a very small subset of particles. That's different from other conversions we provide.

BTW, you may have your reasons to have slightly modified names but be aware that Particle provide various names, as seen below. I also noticed some inconsistency in the names you give above in the dictionary: in some cases the key is the PDG name but in other it's not - remember the PDG name does not contain the charge. Just to exemplify what I mean:

In [1]: from particle import Particle

In [2]: for p in Particle.findall('B(s)', particle=True):
   ...:     print(p.name, p.pdg_name, p.evtgen_name, p.programmatic_name)
   ...:
B(s)0 B(s) B_s0 B_s_0
B(s)*0 B(s)* B_s*0 B_sst_0

In [3]: for p in Particle.findall('K*(892)+', particle=True):
   ...:     print(p.name, p.pdg_name, p.evtgen_name, p.programmatic_name)
   ...:
K*(892)+ K*(892) K*+ Kst_892_plus

I hope these things prove useful to you. By all means do not hesitate to post on the Particle repository "issues" for what you need, including new functionality or requests for information/clarifications ...

[DavidMStraub]

in some cases the key is the PDG name but in other it's not - remember the PDG name does not contain the charge.

That's right, here the choice was that the charge only shows up in cases where it's not unique, e.g. for rho it shows up since there are charged and neutral ones, while for Lambda it doesn't since it's always neutral.

But this dictionary is only used for translating the PDG mass/width table, so if it's replaced by Particle and this dictionary removed, the keys of it don't show up anywhere in the code.

[peterstangl]

@DavidMStraub now that particle is used by flavio, do you see also other possibilities for making use of scikit-hep or should we close this issue?

[eduardo-rodrigues]

Hello! Allow me to chime in. From the Scikit-HEP side let me just say that we have some other packages that may be of interest to you (e.g. histogramming?) and we are as always more than happy to collaborate and exchange ideas and information. Plenty of communication channels are listed at https://scikit-hep.org/getting-in-touch :-).

[peterstangl]

Thank you @eduardo-rodrigues!

One thing I now remember that could be interesting is to use uproot for implementing a function that can import root files containing experimental likelihoods given in terms of TH1D, TH2D, or TH3D histograms. @renqgl90 and me have actually started implementing something like this a while ago and maybe we should open a PR at some point.

[eduardo-rodrigues]

Hi. Contributions are most welcome! At this stage you should focus on https://github.com/scikit-hep/uproot4 which is a better/... version of the good-old uproot3. Jim is getting lots of feedback and that helps shaping the package as per requirements.