feat(mixing): add OneBB1500W preset and 1BB1500W beam constants - #565
Conversation
A one-booster-batch beam at 1500 W, for Run1B mixing. The existing presets cover full 1BB (1.58e7), full 2BB (3.93e7) and 1% of a single batch pulse (1.58e5); reduced-intensity Run1B running has until now been a bare extendedMean override carried in the prodtools campaign config, with no record of where the number came from. The value follows from the accelerator parameters already in JobConfig/ensemble/python/constants.py: 1500 W over a 1.33 s cycle is 1.5565e12 POT/cycle, and the 1BB duty factor of 0.323 puts 253445 microbunches in the 0.4296 s spill, giving 6.14e6 protons per microbunch. cutMax follows the 6x convention of the other presets. Including OneBB.fcl rather than restating SDF keeps the lognormal width defined in one place and makes the file independent of include order. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
☀️ The build tests passed at c591efd.
N.B. These results were obtained from a build of this Pull Request at c591efd after being merged into the base branch at bfa5e6c. For more information, please check the job page here. |
The ensemble constants carried only full 1BB and 2BB. The Run1B campaigns run one booster batch at reduced intensity, which is neither, so normalising them with run_mode='1BB' would assume 1.58e7 protons per spill where those campaigns actually mix 5.92e6 — an overestimate of POT by 2.7x. Nothing does this today; the trap is latent. Adds ONEBB1500W_POT_PER_CYCLE and ONEBB1500W_PROTONS_PER_SPILL for the 1500 W beam, matching JobConfig/mixing/OneBB1500W.fcl. The constants are named for the beam rather than the campaign, following ONEBB_/TWOBB_; a run mode string would be '1BB1500W'. Duty factor and cycle time are not repeated: this is the same accelerator mode as 1BB and takes ONEBB_DF and ONEBB_CYCLE, so only the intensity is new. Also records how protons per spill follows from POT per cycle, for all three modes. That relation was undocumented, which left the mixing intensities impossible to source. Nothing reads the new constants yet: get_duty_factor() and get_pot() still branch on '1BB' and '2BB' only, so this normalisation continues to need the 'custom' method until a run mode is plumbed through. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
@FNALbuild run build test |
|
⌛ The following tests have been triggered for 947cccd: build (Build queue - API unavailable) |
|
☀️ The build tests passed at 947cccd.
N.B. These results were obtained from a build of this Pull Request at 947cccd after being merged into the base branch at bfa5e6c. For more information, please check the job page here. |
michaelmackenzie
left a comment
There was a problem hiding this comment.
Looks good to me, thanks!
Adds a one-booster-batch beam preset at 1500 W, and the Run1B constants it
derives from.
Why
The mixing presets cover full 1BB (1.58e7 protons/spill), full 2BB (3.93e7) and
1% of a single batch pulse (1.58e5). Run1B runs one booster batch at reduced
intensity, which is none of these, so every Run1B campaign has carried a bare
extendedMeanoverride in its prodtools entry with no record of where thenumber came from. Reconstructing it took a full pass through the accelerator
parameters.
The derivation
Protons per spill is POT per cycle divided by the number of 1695 ns spills that
fit in the onspill fraction of a cycle:
This reproduces the two existing presets to their quoted precision, which is
what establishes that the relation is the right one. It also explains why 1BB
and 2BB are not a factor of two apart in protons per spill despite being a
factor of two in protons: 2BB delivers double the protons in a shorter spill,
0.344 s against 0.430 s. Power depends on POT/cycle and cycle time only — the
duty factor cancels.
cutMaxfollows the 6× convention of the other presets.OneBB1500W.fclincludes
OneBB.fclrather than restatingSDF, so the lognormal width staysdefined in one place and the file does not depend on include order.
Normalisation gap, documented but not closed
ensemble/python/constants.pycarried only 1BB and 2BB. Normalising Run1B withrun_mode='1BB'assumes 1.58e7 protons/spill where the campaigns actually mix5.92e6 — an overestimate of POT by 2.7×.
This PR adds
ONEBB1500W_DF,ONEBB1500W_CYCLE,ONEBB1500W_POT_PER_CYCLEand
ONEBB1500W_PROTONS_PER_SPILL— named for the beam rather than thecampaign, following
ONEBB_/TWOBB_, with'1BB1500W'as the natural run modestring — but does not wire them in:
get_duty_factor()andget_pot()still branch on
'1BB'and'2BB'only, so this normalisation continues torequire the
custommethod. Making it a first-class run mode touches fourbranch sites across two functions and is better reviewed on its own. Worth
folding into that change:
get_duty_factor()currently fails open, returningthe 1BB duty factor for any unrecognised mode with its warning commented out,
while
get_pot()raises.Effect on existing jobs
None. No existing fcl or campaign entry includes the new file, and nothing reads
the new constants. Verified: all three modes reproduce their stated
protons-per-spill from the constants as imported (Run1B −0.010%, 1BB −0.111%,
2BB +0.185%; the two existing figures are the rounded values the presets use).