RD developments towards September 2024 MD

Overall impact on the bandwidth

Computed from this test that was triggered here on commit 36ceec94.

Goals

Include modifications for the period after the MD happening in September. The internal deadline is set to the 23rd of August. Follows !3536 (merged).

Contributing

If you want to contribute to this MR, please speak first to @mramospe and @matzeni and explain your goals. We should avoid having clashes across different files, so if your line is defined in a module where other lines live, please coordinate among the contributors to the file to avoid conflicts. Once you are given green light to do changes, please do so and include in the description of this MR a little summary indicating the file(s) that you have modified as well as the changes to the lines. If you are changing a lot of different lines, please consider making a MR targeting the rd-devel branch. Note that we will not be able to run the central tests on that MR, but it will facilitate the review and the testing locally.

Any contributions to this MR should be ready by the 23rd of August, in such a way that the impact on the rate, bandwidth and throughput has been studied and is within the thresholds.

The tests must be run using this snippet.

All the additions need to be tested locally, including:

• Impact on the bandwidth and rate: if including new lines, these must be well justified (i.e. the physics case must not be already covered by other existing lines) and have rates and bandwidths below 100 Hz and 10 MB/s, respectively. This must be tested on real data. Follow the instructions at the RD migration meeting for advice on how to proceed. If you are tweaking existing lines the same thresholds apply.
• Impact on the throughput: comparing the time with the execution of 2024-patches with no extra modifications.
• (optional) Determine efficiencies: if there is simulation already available, it will be interesting to know the efficiencies so we ensure that there is no bug in the selections.

Do not rebase or force-push to this branch without the consent of @mramospe and/or @matzeni, since this might lead to losses on the changes

Handling Git conflicts

Since the rd-devel branch is based on 2024-patches, and due to the continuous development state of the latter, we need to do frequent rebase operations to keep it up-to-date. If you are collaborating in an independent branch e.g. username-devel you will need to have as a base rd-devel. You can do so via

git checkout rd-devel
git checkout -b username-devel

Note that if you have been initially basing the branch on 2024-patches at the point of changing the target branch in your merge request you will have a lot of commits from 2024-patches that will be added to rd-devel, which is not desirable (it will just add noise to the set of changes and be a source of potential conflicts). Something similar might happen if we rebase rd-devel; the base commit of username-devel will be lost because the whole history is reorganized during this operation (i.e. the base commit identifier, the hash, will no longer be in the history of rd-devel). In any of these two cases, we recommend to backup your branch with a new name (just in case) and then make use of the --onto argument of git rebase, like:

git branch -c username-devel username-devel-backup
git rebase --onto rd-devel rd-devel@{1} username-devel

This will put your branch username-devel so it is based on the last commit from rd-devel.

Changes

Please follow the same format as in !3536 (merged).

general

• reorganization of the dielectron builders to safely use long, downstream and upstream tracks mixed together in the combiner @mramospe.

rare_tau_decay_lines, rdbuilder_thor @cacochat

• Enable also downstream electrons for the dielectron maker in the 2 tau_to_mugamma lines. !3782 (merged)