Access to event weight

[davo417]

I'm using this package as a front end for PYTHIA8 event generation and it have being great, but I can't find the event weight nor sum of weights for the run. This is information exposed by the pythia instance and not the event in the original c++ implementation and the official python bindings.

Is this in the roadmap? If not, I think it's an important part of every event generator.

[afedynitch]

Thanks @davo417 for the suggestion. Indeed.

@HDembinski , couldn't we include the original Info (${cpp_dir}/pythia83/plugins/python/src/Info.cpp) in our Python module? It has too many different methods exposed to put them all by hand, and it is not performance critical.

[HDembinski]

I think we probably technically can mix the original autogenerated and the handwritten optimized interface, but that's pulling in 350 lines of API which does not follow our style conventions. The original interface is not pythonic and uses camelCase instead of snake_case.

[HDembinski]

The alternative is to just expose what users request.

[afedynitch]

I see and I agree that there are too many. There are so many parameters exposed for different use-cases/user-groups that it will be hard to decide which ones. But since we're already exposing some maybe we can try that and see how it works down the line. If it becomes to tedious to maintain we could parse the file into something more compatible with our style convention.

@davo417 Could you list the elements from Info you would like us to expose? These are listed here in the manual and here.

[HDembinski]

Here is another idea that I could live with. If we decide to expose the full API, we could make it available in a special property, e.g. event.pythiaAPI.info to separate it clearly from our own bindings. Using pythiaAPI would then come with the disclaimer that these are just the original Pythia Python bindings, which we provide as a fallback where our nicer bindings are missing. By doing this, we keep the option to also provide our own API that may be nicer/faster/easier to use than the original API.

By that I mean we could have event.info with our own info API and simultaneously event.pythiaAPI.info as a fallback.

[afedynitch]

Oh, cool. Indeed a good idea. Does it work automagically with pybind or do we need to fork Pythia's bindings?

[davo417]

Great to see a prompt response!!

From the official python bindings docs The constant Pythia::info member is available as Pythia::infoPython. Note, this creates a new instance of the Info class, and so needs to be called each time the information might be updated.

Which may hurt performance when processing many events. I'm aware that you only access the event weight once and potentially transverse the event "particle tree" many times, so it may not be super performance critical, but I don't know how slow the official api is.

This is still a nice fallback while a proper api is developed.

And this is a common use case for other event generators as well, they all try to generate unweighted events but that is not always possible. So we need weights in our analyses, plus they offer a more reliable "prior" for Bayesian methods than uniform weights (I think).

Regarding the rest of event information exposed by pythia I personally don't think they are of much use in analyses, I've rather use it in custom veto logic and user hooks (which is also available in the official bindings, e.g main10.py).

But that is, AFAIK, a Pythia specific use case and not the aim of this project. In the other hand, event weights are essential for analyses and x-section calculations almost universally.

[davo417]

Some run info is already available via Pythia8._pythia and is used for x-section data here

[davo417]

In the c++ side the Info is extracted here so event weight (and weight sum) could be exposed in the same way, they are just doubles so no extra pointer management is needed.

IDK when the info is extracted:

• once, only when accessed (lazy)
• every time is accessed (hole object)
• every time is accessed (just the property)

The last one is ideal 'cause the x-section data is only useful at the end, but event weight updates are needed and the rest can be ignored.

[HDembinski]

@davo417 I will check, but our Python object is wrapping the internal reference inside the Pythia class, so what we access as Info in Python should be a view into the original C++ object. In other words, when you access info, you get the current state of the C++ instance.

[HDembinski]

@davo417 I think you did not answer Anatoli's question:

@davo417 Could you list the elements from Info you would like us to expose? These are listed here in the manual and here.

[davo417]

@davo417 Could you list the elements from Info you would like us to expose? These are listed here in the manual and here.

I need Info::weightSum() and double Info::weight() to be exposed.

[davo417]

👀

[davo417]

👀

[davo417]

👀

[afedynitch]

Good point.

@jncots Can have a look at how to include this in #174?

[jncots]

Ok. I will check.