WIP: Add RD strange four body HLT2 lines

added RD hlt2 labels

added RTA label

requested review from @msaur, @fevolle, @yafan, @tmombach, @hvc, and @mmulder

@jubermud @sargueda @tmombach Thanks for this contribution.

I am currently restructuring all files in strange folder to follow rest of our code, I will push it tomorrow (still have to run some local tests). For you it will mean just some copy&paste between a few files, nothing significant.

So I don't know what your plans are @msaur (if you just write up your plans here, we can restructure also in this MR), but there are a few things we should do here:

physics-wise: one could play a bit with the PID cuts. The PIDK cut on the pions is probably too tight. Requiring isMuon is also quite strict. Replacing this by PIDmu>0 could be possible as well. The PIDe cuts can be tightened a bit to increase efficiencies.
organisatorial:
- probably the builders and line registration should be split in two files
- the lines have to be added to the RD-level __init__.py
- the ghostprob cuts are supposed to be removed for now. They are organised centrally

Is there a reason why you don't include downstream lines as well? For KS0 decays you should be able to double your yield this way, and the backgrounds will also be lower so you can probably relax some of your cuts. Obviously we won't have downstream tracks for the first part of R3 but perhaps it would be good to have these in as placeholders, even if they are switched off for now?

I agree with Titus that requiring isMuon on all four muons is likely to be rather harsh. One option might be to add a second line that takes three muons satisfying isMuon with a fourth track that fails isMuon (it would need to explicitly fail the cut otherwise you will end up duplicating candidates in the 4mu line). Something like this was done for in the stripping for B0->4mu in R1/R2. In that case signal was swamped by hadronic background from decays like B0->Jpsi(mm)pipi but in your case I imagine it would be less of an issue since KS0->pipimumu is right at the kinematic limit.

right. I added some downstream placeholders, but they have trouble atm (not sure which functor is causing it). So in favour of getting these lines ready now-ish I would prefer to not fiddle too much with the downstream stuff. Indeed probably the PID is not needed for the pipimumu and 4mu because of the kinematic limit

just to add I removed the IsMuon requirement and replaced by PIDmu, which is hopefully more performant for the softer tracks

Hello @tmombach, what exact issue with downstream tracks do you mean? Lifetime functor issue (not converging error message) or general geometry of those decays (absurd track warning)?

Basically the rate and efficiencies are zero, from a sort-of quick check I didn't see error messages pointing me to what is buggy and atm I don't have time to check every individual functor. So I thought it's best to get the long track versions merged first (I definitely want at least one version of these lines in the system, so it's well prepared for the early data), as we won't have downstream tracking for a while. Sorry to not be able to give you more details atm.

@hvc I added the loose line. at the moment looks good, but I think the muon PID bug reported a few weeks ago is still not fixed yet, so the rates are not 100% reliable.

Indeed that is still an ongoing issue.

Thanks @tmombach. It looks good. Happy to approve the merge request on the assumption that some further tweaks may be needed once the muon PID issue is resolved.

After all I noticed that the muon ID for the KS24mu ones can be relaxed to PIDmu>-1 (because of the kinematic edge). In that case the extra line with even looser muon requirements doesn't really add anything. So I'm leaving it out again. Will update the signal efficiencies on simulation in the coming days and then hopefully this can go.