Default magnet polarities depend on what was taken in data
Without specifying the magnet-polarities
key, the old behaviour was to give both MagUp and MagDown regardless of the data-taking period. Since ion runs tend to be MagDown only (plus a few proton runs), LbMCSubmit can be a little bit smarter about which polarities are available by default per data-type and collision-type combination. Additionally, the 2024 pp "blocks" are one polarity each.
A dictionary in src/LbMCSubmit/lumi.py
keeps track of the percentage split of the luminosity by magnet polarity. When unrolling the loop over years/polarities/etc, if the list of polarities is empty, the ones that have a >0 value in this dict will be included. The numbers are not currently used to split the number of events proportionally, but this is an option in the future.
If the data-type begins with "expected-" then both polarities will be used by default.
Note that this MR changes the level at which the loop over magnet polarities occurs, therefore a lot of stage6 reference files are changed.
Previously the requests were grouped by polarity, e.g.
- 2011 MagUp
- 2012 MagUp
- 2015 MagUp
- 2011 MagDown
- 2012 MagDown
- 2015 MagDown
Now with this MR, they are grouped by year, e.g.
- 2011 MagUp
- 2011 MagDown
- 2012 MagUp
- 2012 MagDown
- 2015 MagUp
- 2015 MagDown
I think this is a much more natural way of grouping them
Some Pb-beam and SMOG tests are altered/removed to fit
- 2024 p-SMOG reduced to reflect actual data
- 2024 Pb-SMOG removed
- 2024.Q1.2 Pb-Pb removed