ColliderBit: refactor LEP likelihoods#607
Open
ChrisJChang wants to merge 2 commits into
Open
Conversation
The LEP rollcall previously declared ~147 separate capabilities via
QUICK_FUNCTION macros: ~130 internal cross-section capabilities and 17
individual per-analysis likelihoods, each of which had to be listed
separately in the yaml ObsLikes blocks.
This replaces all of those (except the model-restricted L3 gravitino
search) with a single function, calc_LEP_LogLikes, providing two
capabilities:
- LEP_LogLikes (map_str_dbl): the per-analysis breakdown of the LEP
slepton and gaugino log-likelihoods, and
- LEP_Combined_LogLike (double): their sum, for use as a single yaml
LogLike entry.
The required LEP production cross sections are now computed internally via
the existing get_sigma_ee_* helpers rather than being exposed as separate
capabilities. The per-analysis likelihood logic is preserved verbatim in
plain helper functions. The set of analyses entering the combined
likelihood is configurable via the "analyses" run option, defaulting to
the standard non-overlapping set.
This mirrors the existing LHC_Combined_LogLike / LHC_LogLike_per_analysis
pattern, simplifies the LEP yaml entries to a single list, and greatly
reduces the number of module-function template instantiations (and hence
ColliderBit compile time).
The yaml files (CMSSM, NUHM1, NUHM2, MSSM7, MSSM9, ColliderBit_CMSSM) are
updated to use the new capabilities, with the "analyses" option set where
a non-default subset was previously used.
https://claude.ai/code/session_01625839aiHy9p3NVh6DrjDG
|
I checked the update against the old code and it holds up:
A couple of things worth confirming (non-blocking):
I didn't compile this locally, so it'd be good to let CI confirm the ColliderBit build. |
Pengxuan-Zhu-Phys
approved these changes
Jun 19, 2026
Pengxuan-Zhu-Phys
left a comment
Pengxuan-Zhu-Phys
left a comment
There was a problem hiding this comment.
I checked the update against the old code and it holds up
Member
|
Regarding this that @Pengxuan-Zhu-Phys noticed:
I don't think the assumptions in the cross section calculations apply for MSSM63 because of the appearance of for example sleptons with multiple flavour components and this is the reason this capability was previously restricted to MSSM30. This is probably not a big deal since the effect should in any case be small, but if it is possible without too much work to restrict to the MSSM30 that would be better. Later I am hoping to have more generally applicable cross sections that we can take from smoking (and then we don't need these internal cross section routines at all). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR pulls all of the LEP likelihoods into a couple functions, rather than as separate capabilities. This means that in the yaml file, you will simply provide the list of LEP analyses. It still prints them separately to the output file.
The gravitino one was separated because it required a different model dependency.
In theory, it should reduce compile time since it will not need to instantiate a bunch of macros for every different capability. The compile time speedups will not be noticeable unless combined with the other Core PR to link modules (because it will speed up the ColliderBit registry compilation).
Setting @Pengxuan-Zhu-Phys as reviewer since it is ColliderBit code, and also @anderkve because it is something he has mentioned wanting to do before.