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

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

Details

Reviewers

tlatham
jback

Commits

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

Summary

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

Repository

rEVTGEN evtgen

Branch

4bodyPhsp

Lint

No Lint Coverage

Unit

No Test Coverage

Build Status

Buildable 126
Build 126: arc lint + arc unit

Event Timeline

kreps created this revision.Jan 8 2021, 12:02 PM

Harbormaster completed remote builds in B121: Diff 177.Jan 8 2021, 12:02 PM

kreps changed the edit policy from "All Users" to "Restricted Project (Project)".Jan 8 2021, 12:04 PM

kreps added a project: Restricted Project.

tlatham changed the visibility from "All Users" to "Public (No Login Required)".Jan 8 2021, 12:54 PM

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

src/EvtGenBase/EvtKine.cpp
135	This function can be constant.
src/EvtGenModels/EvtFourBodyPhsp.cpp
41	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.Jan 11 2021, 4:58 PM

kreps added inline comments.Jan 11 2021, 5:50 PM

src/EvtGenModels/EvtFourBodyPhsp.cpp
41	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.Jan 11 2021, 6:08 PM

src/EvtGenModels/EvtFourBodyPhsp.cpp
41	Ok, I see what you mean.

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

kreps added inline comments.

src/EvtGenBase/EvtKine.cpp
135	This is not class member, just standalone function, so const does not apply here.
src/EvtGenModels/EvtFourBodyPhsp.cpp
41	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.

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

This revision is now accepted and ready to land.Jan 12 2021, 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.

EvtGenModels/EvtFourBodyPhsp.hh
71–87	I see you've given the last 3 of these initial values. Can we give the others sensible initial values as well?
src/EvtGenModels/EvtFourBodyPhsp.cpp
41	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.