Ltspice Sim

ltspice-sim

This file is the LTspice index. Use the simplest reliable execution path for the workspace you are in. When sim is available, prefer uv run sim run --solver ltspice because it gives you structured .meas results, run history, and a consistent error surface. When a task already provides a direct LTspice launcher (LTspice.exe -b, wine-ltspice, a Docker wrapper, or a plain Bash script), that path is equally valid.

Use portable file parsing for completed .log and .raw artifacts. Do not route every post-processing step back through sim-cli just because uv run sim exists.

Read ../sim-cli/SKILL.md when you are using the sim-cli path or a remote uv run sim serve host. This skill covers the LTspice-specific layer: netlist/schematic conventions, platform quirks, batch execution, and result extraction.

What LTspice is (and isn't)

LTspice is the free SPICE3 simulator from Analog Devices. It has no vendor Python API — unlike Fluent (pyfluent), COMSOL (mph), or MATLAB (matlabengine). The sim-plugin-ltspice plugin ships its own Python API as sim_plugin_ltspice.lib: pure-Python parsers for .asc/.net/.log/.raw plus a subprocess runner around the LTspice CLI. That bundled lib IS the Python API for LTspice.

Implication: the LTspice-specific advice in this skill stays useful whether you call uv run sim run foo.net --solver ltspice, invoke LTspice directly in batch mode, or import sim_plugin_ltspice.lib in Python. The file format understanding and platform quirks are the same.

Execution paths

Pick the path with the least moving parts that still gives verifiable artifacts:

For benchmark and agent tasks, the important requirement is not which launcher you used. It is that reported values are grounded in produced artifacts and can be re-extracted.

Input classification

When you produce a netlist for an agent workflow, prefer .net. It is the most portable input format and has the fewest platform edge cases.

Platform capabilities

† On macOS 26 the -netlist flag works but sim-plugin-ltspice's preferred path is the in-process schematic_to_netlist flattener — no LTspice binary touched. Use -netlist only when the flattener can't handle a hierarchy or custom-symbol case.

If you need a feature macOS lacks (or to dodge the 26.0.1 -netlist regression), route through uv run sim --host <windows-host>. See ../sim-cli/SKILL.md for the HTTP dispatch model. The full flag-by-flag table lives in base/reference/command_line_switches.md.

Hard constraints (LTspice-specific)

1. Every netlist must have an analysis directive. At least one of .tran, .ac, .dc, .op, .noise, .tf, .four. Without one, LTspice returns exit code 0 but produces no useful output. If using sim-cli, uv run sim lint can catch this before the run.
2. Put .meas statements in the netlist, not in a config file. That is how stable scalar values appear in the .log; sim-cli also surfaces them as structured measures when you use uv run sim run. Free-form .print output is harder to parse.
3. Never rely on hidden workspace / process state across batch runs. Each invocation is a cold LTspice batch whether launched directly or through sim-cli. Chain steps by writing out intermediate .net variations in Python, not by stateful execution.
4. First line of a netlist is the title, always ignored. Component declarations start at line 2. A common mistake is putting V1 in 0 1 on line 1 — LTspice silently treats it as comment text.
5. Use single-letter element prefixes. R / C / L / V / I / D / Q / M / X. Two-letter names like R1a are fine as instance labels, but the first letter must match the element kind.
6. Ground is net 0 (numeric zero). Not GND, not 0v. Other names are arbitrary user-defined nets.

Required protocol (one paragraph)

Check that LTspice is available by the intended route (uv run sim check ltspice for sim-cli, or the task's direct launcher/version command otherwise). Validate that the .net has a title line, at least one analysis directive, and .meas statements for every scalar acceptance metric. Run the deck by the simplest available batch path. If using sim-cli, read structured results with uv run sim logs last --field measures; if running directly, parse the produced .log or .raw with shell/Python. Evaluate against the task's acceptance criteria using values re-extracted from those artifacts. For parameter sweeps, prefer .step param inside the netlist so one batch run covers the sweep; the resulting .raw has one dataset per step.

LTspice-specific layered content

Read the relevant base/reference/ pages, snippets, and workflows for the task at hand.

base/ — always relevant

Documentation lookup

LTspice ships an extensive offline help set on Windows at %LOCALAPPDATA%\Programs\ADI\LTspice\LTspiceHelp\ (~738 HTML files in 26.x — comprehensive SPICE + analysis reference). macOS 17 ships no HTML help (in-GUI help only); macOS 26 has parity with Windows.

The community mirror at ltwiki.org indexes the same content and is searchable from any platform without LTspice installed locally.

For authoritative syntax questions on a Windows host:

uv run sim --host <windows-host> exec 'cat "%LOCALAPPDATA%\Programs\ADI\LTspice\LTspiceHelp\<topic>.htm"'

For anyone else, consult the LTspice Users' Guide PDF (search "LTspice Getting Started Guide" — Analog Devices publishes it openly).

tests/ (top-level, QA-only)

Not loaded during a normal session. Mirrors the sibling skills' convention.

Common pitfalls (save yourself a cycle)

1. Missing ground reference. Every net that isn't declared somewhere must be connected to something — LTspice flags singular matrices cryptically. Always add ground (FLAG 0 via the netlist is implicit when you reference net 0).

2. .meas misspelled as .measure. Both work, but .meas is the shorter form used in every example and our parser is tuned for it.

3. Windows .log encoding trap. LTspice 26 writes UTF-8 logs; LTspice 17 (macOS) writes UTF-16 LE. sim-plugin-ltspice handles both transparently, but if you're reading the .log yourself with open(), sniff the encoding.

4. Drive-letter paths in logs. On Windows, the .log has a Files loaded:\nC:\Users\...\design.net block. A naive regex parser would see C: as a measure name. If you roll your own log parser, exclude newlines from the expression capture. (Ours does — see the sim-cli driver's regex.)

5. macOS .asc refusal. If uv run sim run my.asc --solver ltspice errors with MacOSCannotFlatten, either (a) ensure the schematic uses only shipped-library symbols and no hierarchy, or (b) route via uv run sim --host <windows-host>.

6. -netlist is broken on LTspice 26.0.1 (Windows). The flag silently hangs — no .net written, no exit code, no signal. Don't shell out to LTspice.exe -netlist; use sim_plugin_ltspice.lib.schematic_to_netlist instead. See base/reference/command_line_switches.md for the full regression note.

7. No GUI session log. Unlike Flotherm, LTspice writes nothing for GUI events (popups, schematic-load failures, updater dialogs). The only file channel is the per-deck <deck>.log, which only covers solver-time errors. For hangs and GUI-only failures, the sim_plugin_ltspice.lib.runner 300 s timeout is the triage primitive — see base/reference/log_channel_limits.md.

8. Generic-model lookup is closed. Q1 c b e 2N9999 will fail at solve time unless 2N9999 is in lib/cmp/standard.bjt or pulled in via .lib/.include. The 8 lib/cmp/standard.* files are the closed enum — see base/reference/component_models.md for offline lint via ComponentModelCatalog.