Conversation
Contributor
|
Some of these things are probably issues in develop as well, can you create a PR for that as well? |
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
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.
From Claude with love:
Bugs fixed in BNB beam-quality retrieval / FOM
Found while auditing
BeamSpillInfoRetrieveragainst ICARUS flat CAFs (2 files, 99 triggered spills, 3,021 subrun spills; Run 2 + Run 4). Numbers below are from those files.High impact
1. Missing devices are silently used as real values (
getFOM.cpp)Every device is pushed into a one-element
std::vector, so all the.empty()checks (TOR875 fallback, "return 2/3 when BPM data missing") are dead code. A device that fails to read arrives as-999and goes straight into the position/angle extrapolation, so the beam is placed ~1 m off target, FOM ≈ 0, and the spill ends up withFOM = -999in the CAF.-999/non-finite as missing. Return2(horizontal) or3(vertical) when the needed BPM or BPM offset is missing, as the code intended.2. Failed BPM-offset queries throw away good spills (
POTTools.cpp)The offsets (
E_*S,BNB_BPM_settings) are slowly changing setpoints, but the query fails fairly often. Combined with (1), 624 / 3,021 subrun spills (21%) with full intensity (median TOR860 2.7e12) gotFOM = -999only because an offset was missing.ReuseLastBPMOffsets, defaulttrue). InendSubRun(ICARUS and SBND BNB retrievers), back-fill offsets for spills recorded before the first valid reading and recompute their FOM. Emulated on the data, this recovers 624/624; the remaining 414-999s all have a BPM reading missing.3. Multiwire profiles matched to the wrong spill (ICARUS/SBND retrievers)
The MWR↔spill matching has no maximum time difference and falls back silently to index
0when there is no best match. In the data,*_spill_time_diffreaches 22–27 s, so profiles from unrelated spills were used for the beam width.sbn::pot::matchMWRToSpill()(newMWRMatching.h/.cpp, no art deps). It returns-1for no match and rejects matches beyondMWRMaxTimeDiff(default 0.0333 s, half the 15 Hz period;<= 0disables).4. Pre-fit FOM uses an unrelated / uninitialised chi2 (
getFOM.cpp)The "pre-fit" FOM (database widths
M876HS/VS,M875HS/VS) applies the chi2 cut from whichever multiwire profile fit ran last, which has nothing to do with those widths. With no multiwire data (all of Run 2),chi2x/chi2yare uninitialised (undefined behaviour), so whether the pre-fit FOM is accepted depends on stack contents.Medium
5. No intensity requirement. Beam-off spills (TOR860 ≤ 0) get FOM ≈ 1; 13 such spills passed
FOM > 0.95. Also there was no TOR860→TOR875 fallback, and a-999e12intensity gives a negative emittance →sqrt(<0)→ NaN.-1if neither is valid and positive.6. Out-of-bounds read on short multiwire arrays. The profile is used if
size() > 0, but 96 elements are read.7. Fit result never checked; histogram leaked.
TFitResultPtris dereferenced without checking status/null; theTH1Dis leaked on the empty-profile path and registered ingDirectoryunder a fixed name.SetDirectory(nullptr);processBNBprofile()now returnsbool(status 0, ndf > 0).8.
assertcontradicting the code below it (POTTools.cpp).makeBNBSpillInfoasserted every MWR device was non-empty, then handled the empty case; debug builds would abort.spill_time_diff = -999.9.
SBNDBNBZEROBIASRetrieverspill selection.BrokenClock(times_temps[i], …)tested the previous best (initially entry 0) instead of the candidatetimes_temps[k]. When no spill qualified, entry 0 was used anyway (out of range for an empty list).k; if no spill is found, skip (the event still gets an empty product).Low / cosmetic
atan()as if they were tangents. This is <1% for typical slopes but wrong. Now uses the slope directly.FillExposure.cxxtreated a physicalFOM = 0(beam fully off target) as a failure (> 0.0) and used bitwise&. Now[0, 1]with&&.π = 3.14159in the target integral (normalisation +8e-7, contributes to FOM saturating at exactly 1). NowM_PI.MWRtoroidDelayis in s (not ms); multiwire coverage is 24 mm (not 24 cm).Behaviour changes to be aware of
atan(10) and the pre-fit chi2 fix (4).getBNBqualityFOM:-1(no beam),2/3(missing H/V BPM or offset).FillExposuremaps these to-999exactly as before. The100 + FOMconvention for the nominal-width FOM is unchanged.MWRMaxTimeDiffandReuseLastBPMOffsetshave defaults, so existing fcls run unchanged. Both are documented inicarusbnbspillinfo.fcl/sbndbnbdefaults.fcl.Testing
getFOM.cppcompiled (-Wall -Wextra) against a minimal ROOT fit stand-in and run on all 3,120 spills. It agrees with an independent Python implementation to 3e-8 on every spill. The same Python code in "legacy" mode reproduces the FOM stored in the CAFs for 3,120/3,120 spills, so the reference was validated against production first.matchMWRToSpill()was checked against the original loop on 388,644 random device–spill cases. It is identical except for the intended changes (no index-0 fallback, time cut).POTToolsin a full mrb environment, a test job withrun_icarusbnbinfo_sbn.fcl, and any SBND data.Open items (not fixed here)
MWRData::unpackMWRor the hardware; it needs a beam-instrumentation look.BNBSpillInfo::POT()guards against a failed TOR860 (-999e12) being added to the subrun POT.