Read the warnings & fidelity banner

circsim surfaces a lot of honesty. That's on purpose: a validator you can't trust is worse than none, so circsim would rather tell you about a gap than hide it. This guide decodes every warning surface so none of them are mysterious.

They stack near the top of the window, most-urgent first.

The fidelity banner

The one you'll see most. It appears whenever the simulation is running with incomplete information.

• "Results approximate: …" (amber): one or more parts are unresolved (no model found) or stubbed (running as a placeholder; a microcontroller modeled as a supply-load stub is stubbed). The voltages and waveforms are correct for the modeled part of the circuit, but the real board may differ wherever an unmodeled part matters.
• "Open by design: …" (grey-blue): the only affected parts are documented opens (a part with no meaningful SPICE model). Lower-key, because this is expected, not a problem.

The banner lists the affected parts and links to open Model Doctor (jumps to the first one) and What can circsim tell you? (the fidelity page). The link opens the published page in your browser when you are online and the copy bundled with circsim when you are not. If neither can be opened, the banner says so and gives the page address instead of failing silently. If many parts are affected it collapses to a count.

You can minimize it (the » button) to a compact header badge (⚠ N approximate or ⓘ N open by design) and click the badge to bring it back. You can't fully dismiss it, and it re-expands on its own if the set of affected parts changes: hiding it entirely would misrepresent the simulation. To make it go away for real, resolve or stub the parts.

"Check these voltages": the operating-point caveat

(persistent, appears after a fallback solve) The banner reads: "Check these voltages. These voltages needed a workaround to solve; treat 0.000 V readings as unknown." The operating point converged, but only through a numerical fallback rather than a clean direct solve, and a fallback op can report a misleading 0.000 V on nets it couldn't resolve. Treat the voltages as suspect and look for the underlying cause (a floating node, a missing ground path). A clean solve shows no caveat.

You don't need to understand the solver to use this. If you're curious which workaround ran (a gentler solve, called gmin stepping, or a ramped solve, called source stepping, techniques that ease a stubborn circuit toward a solution, or a transient assist), open the Details disclosure under the banner.

The bundled op-amp, comparator, 555, and regulator models are written so that ordinary boards solve directly, with no fallback. So when this banner does appear on a board built from them, it is a real signal about the circuit (typically a floating node or a missing DC path), not routine noise to dismiss.

"The simulator couldn't find a stable solution"

(dismissable card) The solve failed outright. This is usually a numerical problem, not a broken circuit. circsim names the likely culprit in plain language and often points at the specific net or part. When it does, the name is a button: click a part to select it on the board and reveal its card in the Model Doctor, or click a net to select it on the board. (A culprit that maps to no net on your board is shown as plain text.) Common fixes: designate the correct ground, stub an unresolved part, or check for a floating node. Expand Show the simulator's full log (the raw ngspice log) if you want the engine's own output.

"Check this rail": a gated-off rail

(amber) The chip power pin (VDD) of a digital chip reads about 0 V in the steady-state measurement (the operating point), so circsim used the family-default logic swing instead, which means logic thresholds may be wrong if that rail is actually powered during a live run (a transient simulation). Type the real rail voltage into the inline field and click Set rail voltage to fix it. See rail sensing.

"Undriven nets held at 0 V"

(amber) One or more nets have no path to ground and nothing that drives them, for example a CMOS input wired only to an unused or unmodeled part, or an enable line with no pull-down. To keep the solve numerically stable, circsim ties each such net to ground through a 1 GOhm resistor, so the net reads 0 V in the simulation. That 0 V is an artifact of the tie, not a measurement: on the real board the net floats, and whatever it feeds (a logic input, a comparator, a gate) can read any level. The banner lists every affected net by its KiCad name.

A net driven by a modeled chip output is not listed, even when nothing else gives it a path to ground: a logic gate output, or an op-amp output that feeds only high-impedance inputs (a voltage follower into a comparator input, say). circsim still ties that net to ground through 1 GOhm, but the output holds it at the level the model drives, so its reading is the simulated output and not an artifact. A part with no model drives nothing in the simulation, so a net only it would drive is listed. A capacitor does not count as a driver either: an input AC-coupled to a gate output through a capacitor, with no bias resistor, is still listed, because the capacitor passes no DC and the input sits at 0 V in the simulation.

A floating op-amp or comparator V- pin is listed too. Those models draw their supply current from V+ to V- with a current source, and the output stage is referenced to the V- pin only through a term that cancels out of its equation. Neither ties V- to anything, so an LM358 whose V- pin is left unconnected shows its V- net here, whether or not its output has a load to ground, instead of borrowing the V+ rail's drive or the output net's path. The reading on that pin is not meaningful, because nothing in the circuit sets it. This applies to the op-amp and comparator models only. The regulator and 555 models read the voltage across their own supply pins in their supply-current source, so they keep a conducting path there and a floating ground pin on one of those is not listed.

Fix it by giving the net a real source: add the missing pull-up or pull-down, connect the unused input, or attach the part that drives it. The note clears on the next solve once every net has a driver or a path to ground.

"Pin map corrected from schematic"

(grey, informational) circsim found a diode/LED whose schematic pin names (A/K) disagreed with its footprint's pad convention, and trusted the schematic, which caught a would-be-reversed part. If your schematic is the stale one, override in the Model Doctor. This is the system working; no action needed unless the schematic is wrong. See the diode-polarity trap.

"pinmap-unverified: polarity of ..."

(sim log warning, when a board opens) A diode or LED sits on a JLCPCB / EasyEDA footprint, whose pad numbering follows the part rather than any convention, so circsim cannot tell which pad is the anode from the footprint name. It uses KiCad's default (pad 1 = cathode). The part has a model, so its dot stays green and it has no Model Doctor card; the sim log names it instead (D8: pinmap-unverified: polarity of "SMA_L4.2-W2.6-LS5.0-RD_1" ...). Attach the schematic so circsim can read the symbol's A/K pin names, which settles the polarity. Without a schematic, check the part against your board (its datasheet drawing or the silkscreen) before you trust a converter or charger result. See the diode-polarity trap.

A part the simulator dropped or rejected

(the part turns no model, red, after a run) circsim reads the simulator's log while it loads the deck. If ngspice says it ignored a part (is not a valid ... instance line), assumed DC 0 for a source with no value, or could not find a valid modelname for a part's card, that part is no longer shown as modeled: it becomes no model with ngspice's message on its card, and the next deck leaves it out instead of repeating the bad card. Before this, such a part could read green while missing from the simulation.

BOM: lines in the sim log

When a BOM is loaded, the sim log says what it did. A BOM: warning means the file could not be read, had a range circsim could not expand, or had rows whose references are not on the board. A BOM: <ref>: ... line names a part whose value the BOM replaced, or whose model its MPN chose or failed to choose, whether or not the part resolved. A part that is also in the Model Doctor shows the same thing as a bom: note on its card. A BOM value that only repeats the board's (a JLCPCB Comment such as 100nF 50V X7R on a 100n capacitor) changes nothing and gets no line.

💡 Coach notes (dark LEDs)

(bottom-left overlay) After a solve, any LED that should be lit but isn't gets a plain-language card explaining why: a reversed diode, no current-limit path, too little voltage. A silent dark LED is a beginner's worst moment, so circsim turns it into a lesson. It disappears once every LED is lit.

Simulator restarted / Bench restarted

(dismissable toasts)

• Simulator restarted: the isolated SPICE engine stopped and recovered automatically. The toast says why: a watchdog timeout (exit code 86, a solve stopped making progress) or a crash (any other exit code). Your work is intact. If the bench was running, it restarts on its own from time zero. If the bench was paused, the paused run cannot be recovered: the notice says so, the bench goes back to idle, and pressing Run starts it again. If the engine fails five times in quick succession, circsim stops trying: the toast changes to Simulator stopped and tells you to quit and reopen circsim. Your board file is never modified, so nothing is lost on disk. Click Save diagnostics in either toast to export a diagnostic bundle for a bug report.
• Bench restarted: a long continuous transient hit its memory/time window and restarted to stay bounded. Scope history is kept. Note that sequential-logic state (flip-flops, counters) resets on a bench restart.

Save diagnostics

A Save diagnostics link sits under any warning (and inside the crash toast). It writes a zip of the decks, the Sim Log, the board hash, and version numbers; see Save a diagnostic bundle.

The Sim Log

(bottom dock, "Sim log" tab) The raw engine output, filterable by All / Warn+ / Errors. Most of the time the friendly surfaces above are enough. Reach for the Sim Log when you want to see exactly what ngspice said.

The through-line

Every one of these exists so you're never trusting a number circsim doesn't trust. When in doubt, read what circsim can and can't tell you: it's the philosophy all of these surfaces come from.