Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(low priority) improve passcuts interface? #987

Open
valassi opened this issue Sep 2, 2024 · 0 comments
Open

(low priority) improve passcuts interface? #987

valassi opened this issue Sep 2, 2024 · 0 comments

Comments

@valassi
Copy link
Member

valassi commented Sep 2, 2024

Hi @oliviermattelaer just a low priority reminder.
Maybe useful to review and improve the passcuts interface.

See #983 (comment)
"One final comment for my own sanity, passcuts takes a vecsize_used parameter but is actually mainly a scalar event by event call. The parameter is passed because on the "first" call there is some update_param for a full bunch of events. This part of the code looks really dangerous to me. There is a mixture of local FIRSTTIME and a common CUTSDONE. What should be a simple "momenta in for one event, falg true/false out for one event" becomes something whose state depends on a common which is initialized and reset not clear where? (That said, I even wonder if I introduced some of this myself 2-3 years ago? I ceratinly added the vecsize_used as a parameter, because previously it was a vecsize_memmax from a parameter... but definitely the mix of scalar and vector behaviour with commons was already there). Maybe this could be reviewed als to make sure there are no bugs?"

One option could be to remove the common and instead pass a parameter which means "this is the first in the bunch or not". For instance, even vecsize_used as a aparameter: if >0 then it means it is the first, and do the loop over the bunch of events; if 0 then it means this is the 2nd-nth event in the bunch, no need to initialise, just return the flag whether cuts passed or not.

Anything that removes commons and goes towards pure in/out functions is a good idea in my opinion.

Thanks
Andrea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant