Circuit simulation

A circuit simulation combines topology, element laws, sources, state variables, and diagnostics. The diagram is an input editor and output view; the graph and solver remain the physics model. A wire drawn left-to-right does not itself define physical direction—node labels, branch reference direction, voltage polarity, and a chosen reference node do.

Think like a programmer

Serialize circuits as nodes, directed branches, component type/parameters/units, initial state, source schedules, reference-node policy, solver/integrator settings, and versioned model assumptions. Run a pure solver core that assembles equations from the graph, then maps solution data to labels, colors, and animation. Preserve residuals, branch power, state history, convergence iterations, and any regularization; never make the renderer the source of a voltage or current.

Model checklist

Inputs: Node/branch graph, branch direction and voltage polarity, component models/parameters, ground/reference node, initial capacitor/inductor state, source schedules, time/step/integrator or DC solver settings, nonlinear convergence policy, and tolerance.
State: Node voltages, branch currents, dynamic-element states, assembled matrix/residual, solver iterations/status, signed branch powers, and replay provenance.
Rule: Validate graph topology; choose reference constraint; assemble KCL/KVL/component equations with named sign conventions; solve or integrate; then derive residuals, power ledger, and display data.
Output: Reproducible DC or transient trace, node/branch values with units, solver/convergence status, KCL/KVL/power residuals, and serialized replay packet.
Check: Same serialized inputs reproduce trace; changing a branch reference reverses its signed voltage/current but not physical magnitudes; KCL residuals are within tolerance at every unconstrained node; KVL/component-law residuals pass; closed ideal solved network power sums near zero; singular/floating/inconsistent topology reports a diagnostic rather than plausible values.

The standard linear DC workflow is a graph-to-system transform. Choose one node as a voltage reference, assign unknown node voltages, and write KCL from connected branches. Dynamic elements add state and time equations; nonlinear devices add an iteration policy and convergence criteria. These are different solver modes, so a run record must name which one produced a result.

\[\sum_{b\in\operatorname{incident}(n)} i_b=0,\qquad r=A\mathbf x-\mathbf b,\qquad p_b=v_bi_b\]

Branch direction is a bookkeeping convention. If a solver reports i = −2 A, current physically flows opposite the stored branch arrow; it is not a failure. The same applies to voltage polarity. Keep signed quantities rather than flipping diagrams to obtain positive labels, because KCL, KVL, and power checks depend on consistent signs. A positive-resistance element should satisfy its component law and absorb nonnegative I²R power under compatible references.

Try this experiment

Prediction: Changing a diagram’s branch direction reverses reported signs but not physical magnitudes when conventions are applied consistently.

Serialize a one-source/one-resistor circuit including node ids, branch direction, polarity, values, units, ground node, and source schedule. Solve it, record node voltage, branch current, KCL/KVL residuals, and signed power. Reverse only the branch reference convention and predict which fields change sign. Then remove the reference node and describe the singular-system diagnostic you expect.

Where this model breaks

Large, nonlinear, switching, high-frequency, or distributed circuits need robust solvers, convergence handling, parasitic/device models, and often electromagnetic field treatment. An educational diagram is not a safety-certified design tool. Ideal sources, zero resistances, and instantaneous switches can create singular or stiff systems whose numerical regularization must not be mistaken for physical hardware.

Try this experiment

Prediction: Changing a diagram’s branch direction changes signs but not physical magnitudes when conventions are applied consistently.

List the minimum serializable fields of a branch and one solver diagnostic shown in the UI.

Where this model breaks

Large, nonlinear, or switching circuits need robust solvers, convergence handling, and device models. An educational diagram is not a safety-certified design tool.

Summary

Keep circuit graph, pure solver, state/integrator, diagnostics, and renderer separate. Make every result replayable from serialized conventions and inputs, and publish KCL/KVL/component/power residuals alongside node and branch values.

Glossary

Topology: node-and-branch connectivity.
Source schedule: time-dependent input rule.
Replay: rerun from identical serialized inputs.
Reference node: node assigned a known voltage to remove the floating-potential degree of freedom.
Residual: mismatch left after substituting a solution into a circuit constraint.
Self-check
1. What is the authoritative circuit representation?
2. Why does a solver need a reference node?
3. Which layers should be separate?
4. What diagnostics distinguish a sign convention from an incorrect solve?

Sources

C. K. Alexander and M. N. O. Sadiku, Fundamentals of Electric Circuits.
OpenStax, University Physics Volume 2, Kirchhoff’s Rules.

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]

Inputs: Quantities you set or measure, with units and useful bounds.
State: Values the program must retain to reproduce the next result.
Rule: The relationship or update that turns inputs and state into a result.
Check: A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For Circuit Simulation, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Currents and Circuits, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat Circuit Simulation as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?

Model review: turn Circuit Simulation into a test

Structure circuits as serialized graphs with separate solver, diagnostics, and rendering layers.

Name the inputs and units that the currents and circuits model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.

Share to: