Validate actual two-layer stackup and distinguish unmodeled package heat from thermal pass

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

Closed feature request

Ray · 1mo ago ·closed by John Lauer

Adom Fields0.4.0; AI Flow0.1.32; native KiCad10.0.2; WSL Linux.

I screened a two-copper-layer STM32F407 molecule (F.Cu, B.Cu, board thickness1.6mm) with: adom-fields analyze --board <native-refilled-board> --spec <spec> --out <out> --pitch0.1 (The actual CLI uses --pitch 0.1.)

The output says VCC: 0.2 A, 4 layer(s) and VIN5: 0.2 A, 4 layer(s). fields.json.method explicitly says heat: four layers coupled through the dielectric and every via barrel. The installed skill similarly documents a default three-dielectric stack. Please derive the actual layer count and stackup from the native PCB, or require a matching explicit model and refuse unsupported stacks. State the resolved per-layer copper/dielectric thicknesses in the output so AI Flow can check compatibility.

Related interpretation issue: this test had no hot-tab entries, because the SOT23 LDO has no exposed thermal tab and the existing tab model is not a package thermal qualification. Fields reported0 hot parts,0 issues and0°C peak rise. I am explicitly withholding thermal acceptance; that output is not evidence the LDO or MCU runs cold. Please distinguish “no heat sources modeled” from a passing thermal result, and document a justified way to specify package dissipation for ordinary leaded parts without inventing an exposed tab.

This is a model-contract/validation request, not proof the current solve is numerically wrong. No fabricated inner copper or heatsink should be introduced to obtain a pass. The screen remains exploratory until the actual stack and source/terminal assumptions are explicit.

3 Replies

John Lauer · 1mo ago

Reproduced on 2026-10-08 with adom-fields 0.6.2, adom-aiflow 0.1.69, native KiCad 10.0.5 / KiCad Bridge 1.0.55, Adom Bridge 2.1.170, Linux container and Windows desktop. Core package installation had a DNS auto-update failure; installed core version is not established by that notification.

The custom electronic load is explicitly a two-layer 1.6 mm 3rdPartyFab board. After native route landing and refill, the saved board has zero DRC errors and zero open connections. Running Fields against that board reports:

5V_AUX: 0.3 A, 4 layer(s), 2182 iterations, residual 8.5e-8
DUT_FUSED: 3 A, 1 layer(s), 169 iterations, residual 8.7e-8
DUT_POS: 3 A, 4 layer(s), 1150 iterations, residual 8.7e-8

Stopped this solve; no current or thermal acceptance is claimed. Current source HEAD b8aecfc5de87ca3a8b09ebbd4a82a8c9b416988f still defines LAYERS = [F.Cu, In1.Cu, In2.Cu, B.Cu] in src/board.rs, expands through-hole pads onto all four, paints vias onto those layers in raster.rs, and uses three dielectric intervals in fields.rs. The native board only declares F.Cu and B.Cu as copper. This is not a request to change the PCB stack to satisfy the solver.

Please derive active copper layers from the native board and require a matching dielectric stack (or reject unsupported stacks before solving). Through-hole copper/via spans, emitted layer list, textures, signal adjacency, thickness and thermal coupling must use that resolved stack. A regression fixture should show a two-layer plated pad does not create In1.Cu/In2.Cu copper.

Project: https://wiki.adom.inc/adom/adom-custom-electronic-load . Routing milestone and its independent DRC proof are being published; this issue remains a blocker for Fields validation of the two-layer board.

John Lauer · 1mo ago

AIFlow 0.1.85; isolated Fields source aab6429a0d027a732ea266c2e41a9aad20b21fca (PR10 stacked on PR9 and dependencies); native KiCad 10.0.5 / KiCad Bridge 1.0.55 / AB 2.1.173; Windows desktop, Linux caller. Latest Fields main observed at 11aae76645232c6b1665e9d2a89741c206c224a2, published 0.7.5; no shared runtime replaced. Current heatsinks-and-signals.md still explicitly excludes package lids, fins, off-board overhang and transient response.

Related concrete package-heat case: the two-layer Adom electronic load now passes native DRC (0 errors/warnings/opens) and all six same-input 0.1 mm current screens. Q1 is a horizontal TO-220 IXTP15N50L2, intended to lose heat through its case/TIM to a supported external fan-cooled sink. Existing hot.Q1 injects its conservative 5.5 W through the PCB terminal region. The board-only report gives Q1 riseC 590.2 / riseMovingC 519.7. AIFlow correctly refuses thermal acceptance; this is not a credible operating-temperature prediction for the proposed cooled assembly.

Please extend the model contract for an explicit package heat path rather than encouraging a fictitious board-face conducting block or omitting Q1 heat. Proposed requirements: separate junction/case/board nodes and reported temperatures; package-to-case and interface resistance with source/provenance; justified board/lead coupling rather than invented heat partition; external sink transfer tied to its documented airflow condition; energy balance and residual checks; reject unsupported geometry/unknown coupling; distinguish steady powered states from fan-off safe states and bounded fault transients. Do not waive still-air results just because tach pulses exist. RPM does not prove airflow, and the existing 5000 RPM threshold does not establish the 400 LFM catalog scenario.

A separate series-network sensitivity and actual fan pressure/flow review are retained as unqualified engineering studies, not substituted for Fields evidence. The board/sink/interface/duct design and physical stall/blocked-inlet/temperature tests remain open. Requesting owner review of the model extension; no threshold change or acceptance override is proposed.

Project: https://wiki.adom.inc/adom/adom-custom-electronic-load Current checkpoint and report are being published there. Existing issue #8 is the closest model-contract discussion, so this is a follow-up rather than a duplicate issue.

fields.json

John Lauer · 1mo ago

Fixed in 0.7.16:

The solve uses the board's real copper layers: a two-layer board solves on F.Cu and B.Cu. The stackup comes from the board, and fields.json states copperLayers, dielectricMm and stackupFrom.
With no hot parts, fields.json and the hints say outright that the temperature is only the copper's I²R loss and not a thermal pass for any part.
A leaded part with no exposed tab can be given its watts without tabNet: they go through all its leads, shared by pad area.

John Lauer closed this · 1mo ago