BandQ Run3 sprucing lines with too high rate

We have two sprucing lines with a too-high rate

| SpruceBandQ_ccbarToPpPmDetached       | 1615.00 |
|---------------------------------------|---------|
| SpruceBandQ_BdToEtacKpPim_EtacToHHHH  | 1148.00 |

DPA colleagues suggest us to optimize the selection to lower down the rate, otherwise there could be a risk that we have too prescale these lines and loose physics opportunities on relevant studies. Relevant issue: https://gitlab.cern.ch/lhcb-dpa/project/-/issues/243#note_6554127

If I remember correctly I am the author of SpruceBandQ_BdToEtacKpPim_EtacToHHHH line, which was implemented in !1225 (diffs) . I will take care of this line.

For the SpruceBandQ_ccbarToPpPmDetached line, I remember that it was implemented in !1148 (merged) by @vyeroshe . I would kindly invite @vyeroshe to tighten some selections.

This is related to B&Q sprucing line tuning, so I would forward the message to @zexu @squ and kindly invite you to organize relevant activities :)

added BandQ label

assigned to @mengzhen, @zexu, and @squ

changed the description

mentioned in merge request !2357 (merged)

Hello, @vyeroshe . May I ask if there's any plans for reducing the rate of the SpruceBandQ_ccbarToPpPmDetached sprucing line ?

If we do not take actions to tighten the selections, we may have to finally prescale the line to meet the rate requirement .

For my sprucing line, I created !2357 (merged) to reduce the rate using a simple prescale for now, to help DPA colleagues having a better global picture about the final bandwidth cost. I plan to tune the selection later and remove the prescale factor. You may consider a similar solution if it looks OK for you :)

Hello @mengzhen, cc @bertol. I see that this is marked as a blocker for https://gitlab.cern.ch/lhcb-dpa/project/-/issues/243. Can you provide an update, thanks?

Hello Eduardo, one of the line has been prescaled as a temporary solution.

For the other line, according to the discussion here: https://gitlab.cern.ch/lhcb-dpa/project/-/issues/243#note_6845810 , @abertoli and I think we can leave it as it is for now, and do some further actions (for example a strong prescale) if this line is found to generate trouble for the data processing. @abertoli could you please kindly confirm my understanding is correct ? After getting your greenlight we could close this issue and consider it as resolved.

@mengzhen fixed himself one of the two lines and told me he pinged several times the proponent of the line SpruceBandQ_ccbarToPpPmDetached but he never got a replay

so as we can not wait forever we can decide to try to keep it but be ready to take strong actions in case the line will cause any issue

the other option being to disable it as we did not get any feedback from the line proponent

being B2OC MiCo I know that it is often not easy to get feedback from proponents ...

I see, thank you both. I have no numbers at hand but since @abertoli is suggesting we play it kind for now and see how first data goes, that seems fine to me. In nominal data taking we will have to be stricter and if line proponents do not respond we will have to switch them off, which seems correct.

Now we have the explanations and I agree with you(s) that we close this :-).

closed