Per-component thermal rise override silently ignored by Fields issue grading

Overview Files Skills Discover Packages Releases Dependencies Issues3 Breadcrumbs Pull Requests Activity

Closed bug report

John Lauer · 29d ago ·closed by John Lauer

Environment: task-local adom-fields0.6.2 package-cooling solver, Linux; shared wiki src/fields.rs blob c085c8d0230217ffceff07714cb73e54b69be177 independently inspected. No desktop dependency. First noticed during R7 electronic-load supplier-informed solve on2026-10-16.

A spec with hotMaxRiseC35 and hot.Q1.maxRiseC15 silently loses the per-part limit because Hot does not deserialize maxRiseC. Tab-rise issue generation uses only spec.hotMaxRiseC. Expected Q1's explicit15C limit to govern issue threshold, severity and explanatory text, while parts without overrides use35C.

Actual output: Q1: +55 °C at its thermal screening node in still air (+38 °C in moving air) against a 35 °C budget.

This case still fails either limit, and AIFlow separately retains the15C gate. A Q1 result between15 and35C can nevertheless escape the Fields issue list. Do not use the current issue list alone as qualification.

Repro: deserialize {"hotMaxRiseC":35,"hot":{"Q1":{"watts":5.5,"tabNet":"LOAD_POS","maxRiseC":15}}}, then review a Q1 result with20C still and18C moving. Expected high tab-rise against15C; current global-only comparison reports none.

Suggested repair: preserve and validate finite positive per-hot-part maxRiseC; use effective per-part limit for all thermal issue comparisons, text and UI thresholds. Add regression tests for override, fallback, invalid override and15..35C false-negative range. Preserve global summary as explicitly global, rather than describing it as every part's limit.

Evidence and input are published on adom/adom-custom-electronic-load under revisions/compact-r11/current-repair-r7/spec-package-supplier-informed.json and docs/r7-probing-and-thermal-review.md. Board/spec hashes in the result are respectively967199ce93e7479c26e33876c9c534a6a56707aed8106564e00372a5eec866e1 and40dcf6d474847d7ede36f9f4567ff939f595e918e61854b95b24490519ebc630. No runtime/source fix claimed by this issue.

1 Reply

John Lauer · 27d ago

Fixed in adom-fields 0.8.1. hot.<ref>.maxRiseC is now read: a part with its own limit is checked against it, and the issue text says so ("against its own 15 °C limit (hot.Q1.maxRiseC)"). A part without an override falls back to hotMaxRiseC ("the board's … budget"), and a non-positive or non-finite override is refused with an error. Checked on the R7 supplier-informed spec (Q1 now reported against 15 °C), and on a case inside the old false-negative band: a part at +45 °C with its own 40 °C limit under a 60 °C board budget is now a medium tab-rise, where 0.8.0 passed it. Update with adom-wiki pkg install adom/adom-fields. Closing; reopen if a case slips through.

John Lauer closed this · 27d ago