Page MenuHomeHEPForge

Model to generate 4-body phase-space decays in restricted part of the m12-m34 space.

Authored by kreps on Fri, Jan 8, 12:02 PM.



The 4-body phase-space can be rather large and chance to obtain events in the corners of m12-m34 space is rather small. There are specific use cases where one wants to generate only events in the restricted range in m12-m34 plane and as one might want to select only small part or because small probability in the corners, just selecting events from full phase-space decays can be very inefficient. This model solves that by generating only events in wanted part of m12-m34 plane and sets maximum probability appropriately for the given window. Full phase-space can be generated with this model, but might not be best option for that.

Test Plan

In the process of testing, results of this decay model is compared to those from generic PHSP model including cases of restricted window.

Diff Detail

rEVTGEN evtgen
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

kreps created this revision.Fri, Jan 8, 12:02 PM
kreps changed the edit policy from "All Users" to "Restricted Project (Project)".Fri, Jan 8, 12:04 PM
kreps added a project: Restricted Project.
tlatham changed the visibility from "All Users" to "Public (No Login Required)".Fri, Jan 8, 12:54 PM
jback requested changes to this revision.Mon, Jan 11, 4:58 PM

Algorithm looks OK overall, although it would be good if we could try to avoid using double pointers in various functions.


This function can be constant.


I don't think we need to use double pointers here. Just define two phspFactor() functions, where the 2nd one includes q, p1 and p3 as extra arguments?

This revision now requires changes to proceed.Mon, Jan 11, 4:58 PM
kreps added inline comments.Mon, Jan 11, 5:50 PM

I'm not sure I understand. The reason why I use pointers here is that I'm actually returning also individual momenta so I do not have to calculate them twice. An alternative would be to avoid this function completely as it is used just in two places (when searching for maximum probability and at one point in decay).

jback added inline comments.Mon, Jan 11, 6:08 PM

Ok, I see what you mean.

kreps marked 6 inline comments as done.Tue, Jan 12, 3:32 PM
kreps added inline comments.

This is not class member, just standalone function, so const does not apply here.


After a bit of thinking, I decided against removing this function completely as in the search for maximum probability it is used in a few places and that would get a bit messier by repeating several lines every time.

jback accepted this revision.Tue, Jan 12, 4:06 PM

Ok, don't see any showstoppers. Thanks for writing this model, Michal.

This revision is now accepted and ready to land.Tue, Jan 12, 4:06 PM

I'm afraid I don't have time right now to really fully review the physics. But hopefully your tests should have covered that. If we think it's necessary, perhaps we can ask the analysts who were requesting this to do some further validations?
I've added a follow-up on the issue of the various double* arguments - in short I'm also not a fan but let's leave them as they are for now.
I've also added one other small question on initialisation of member variables.
I don't see any other problems.


I see you've given the last 3 of these initial values. Can we give the others sensible initial values as well?


I'm also not a fan of this sort of construct. There are some alternatives, such as returning an array of 4 doubles or a tuple of 4 doubles.
I note that similar arguments are present in generatePairMasses, generateRectangle and generateTrapezoid.
However, since these are all private functions, I would say that this is a sufficiently minor detail that we can revisit it in a future modernisation sweep, e.g. after we've adopted C++17 as a minimum so we can use structured bindings to simplify the unpacking of the multiple returns.

kreps updated this revision to Diff 183.Wed, Jan 13, 6:56 PM
kreps marked 2 inline comments as done.
  • Few small improvements in coding style thanks to Tom
tlatham accepted this revision.Wed, Jan 13, 10:05 PM

Looks great, thanks Michal!

This revision was automatically updated to reflect the committed changes.