Wishlist of improvements/bugs to be fixed for the RD Hackathon 2024

Improvements and bugs to be tackled during the RD Hackathon 2024 and targeting the 2025 data-taking period. Tasks should be kept general, so please comment or modify the description of already-existing tasks if they cover the improvement/bug that you want to refer to.

added RD label

assigned to @matzeni and @mramospe

Flag to turn ON or OFF PID selections in all the RD lines: It can be useful when running on simulation, to be modified with a bind when running the reconstruction.

The attempt from SL in doing it !3822 (closed) . Unclear if this has to be handled by WGs or centrally differently

Sorry to jump in, but probably would be best to have an agreement on how to name this specific flag and then let PWGs to implement it in their code as code differs quite a lot between various PWG.

Have we enforced a coherent naming scheme for isolation variables? : good to keep notations consistent.

Limits due to PID calibration are considered in trigger lines?: If our PID lines do not cover certain regions might be useless to select those events.

Inclusive cut-based line: will it stay for 2025? Originally meant to cross-check MVA inclusive lines.

not all MVA lines are actually cutting on an MVA This naming scheme should be avoided.

Redundancy between TURBO and Spruce: it is time to remove it?

Fake electron lines in btosll decays: can we lower some of the thresholds in 2025?

Performance of isolation based on 2024 Is there any study of this? We need this working for next year.

Obsolete lines Removal of things like b_to_kstarmumu.py

All modules must have authors

Could we reduce some of the rescales by improving the selections

added #855 (closed) as child task

removed child task #855 (closed)

added #859 (closed) as child task

removed child task #859 (closed)

mentioned in issue #804 (closed)

mentioned in issue #521 (closed)

mentioned in issue #710 (closed)

changed the description

changed milestone to %RD developments towards 2025 data-taking

I guess this BPV->OWNPV change (#868) is also something to be taken care off during the hackathon, right?

good point! Thanks for the reminder!

Indeed, it's something we'll need to tackle

Hi all, unless I'm mistaken this seems to have already been done? !2886

Hi @jagoodin, simple answer no, it is not merged and it will not be merged. They have the issue (#868) to track it for all working groups. But you can take the MR as a reference. If you follow the discussion on the MR, they came to the conclusion that each WG is supposed to do it by themselves because it would be a too big thing to change it all at once through out the whole project. e.g. read here !2886 (comment 8453372)

But we could at least use Wouter's script to make the replacement consistently throughout RD: !2886 (comment 8454945)

Bug fixes for SS lines in RpK_lines ? SS atm is only on hadron system, not on lepton. More generally- revise with proponents the SS-logics on lines with dileptons. [ in Run1/2 we had mixtures of same sign hadronic and same sign leptons. Needs to be clean-up and bug fixed if needed. For example Rpk_lines do SS on hadrons only.

Is this comment out of place by chance ? Is it a proposal?

:) not sure, i am just trying to tuple some of the SS lines and Bs->emu same sign and found 2 bugs in turbo lines.... i think we need to engage people needing those lines for control to ensure they do the right things... (forwarding parent_id arguments to builders, use and forwarding of flags as same_sign , see !4022 (merged) !4021 (closed)

A generic : bug fix on lines item is missing so far

I think we should start thinking on how to tackle these developments, because I have the impression that we will soon start having a lot of tiny MRs modifying similar files with tons of overlaps. From my perspective, it would be better if !4022 (merged) and !4021 (closed) were promoted to more generic MRs based on the builders and topologies that they target. I was thinking that the best approach here would be to have a bunch of separate MRs based on the topology, so we ensure that the modifications are restricted to a bunch of well-defined python modules.

In other words, I would wait till the final synchronization between 2024-patches and master happens, and then create a rd-devel branch based on master. Afterwards we would be having one MR per topology: rd-strange-devel, rd-xll-devel, rd-radiative-devel, ... What do you think @rquaglia, @matzeni?

THis is fine, another bug found affecting all sprucing 24c2,3,4 vs 24c1, The turbo line HpHmHmMuMu_Inclusive, expected to cover all hadron types, but turned out ot be just a KKK, due to PID cuts. @nsahoo if you have time this must be fixed if you want to do analyses with KpiK or KKpi or pipipi for Bc. If line is expected to be used for R(Kpipi) as well, this might be a problem and we need to implement a sprucing line for 3 hadron channels.

Hi @mramospe, @matzeni, @rquaglia (cc: @fabudine, @fpolci, @yusong for the b->xtaul decays), I was working last week on retuning some lines for the SL group, and I was having a look at the hadronic \tau lines.

In particular, we found that one potential discriminating variable could be the radial distance of the tau from the BPV (functor: F.BPVVDX*F.BPVVDX+F.BPVVDY*F.BPVVDY), which has already been used in some analyses of Run 2 (like R(D*)). This helps, in particular, to reduce the total number of candidates per event in the SL lines with the hadronic tau.

This is a comparison between MC and data produced from block 2. (caveat: MC is produced running the sequence without UT, so it does not reproduce data 100%)

I thought it could be interesting also for the RD case, maybe something else to look at.

Thanks for the study @tfulghes. There should be a F.BPVVDRHO right? So the requirement could be applied straight away.

Yes I suppose also OWNPVVDRHO could be used

Yes, that's even better

Has this been checked on other decays like B_s^0\to\tau^+\tau^- or B_s^0\to K^{*0}(892)\tau^+\tau^-?

For the Hackathon, I would like to have a common selections for \tau, and simply call them e.g. make_tau_to_electron, make_tau_to_muon, make_hadronic_tau...

No it should be checked across the various decays, I was working on SL decays, which do not have tautau.

In principle, it should work, but for detached taus (I guess prompt taus could have a different cut).