Fix SCR convergence failure with series resistor

[esaruoho]

Summary

• Fixes SCR followed by resistor fails to converge; converges with just wire sharpie7/circuitjs1#851 -- SCR followed by resistor fails to converge when triggered
• Moves the SCR on/off state evaluation from doStep() to startIteration() so it is evaluated once per timestep rather than on every Newton-Raphson sub-iteration
• Previously the anode resistance was switched between 0.0105 ohms (on) and 100K ohms (off) inside doStep(), causing it to flip-flop on every iteration when the SCR was near its trigger threshold with an external series resistor, preventing convergence
• This matches the pattern already used by TriacElm and DiacElm, which both evaluate their state in startIteration()

Root cause

The SCR model uses a variable resistor between the anode and an internal node to model the on/off behavior. When on, the resistance is 0.0105 ohms; when off, it is 100K ohms. The switching condition depends on the gate current (ic) and anode current (ia).

The problem was that this switching decision was made inside doStep(), which is called on every Newton-Raphson sub-iteration. When the SCR is near its trigger threshold and there is an external series resistance:

1. Sub-iteration N: currents exceed threshold -> resistance drops to 0.0105
2. The solver computes new voltages/currents based on low resistance
3. Sub-iteration N+1: current feedback through the external resistor pushes currents below threshold -> resistance jumps to 100K
4. The solver computes new voltages/currents based on high resistance
5. Repeat forever -- convergence never occurs

With a wire (zero resistance) this feedback loop does not occur because the voltage is fixed by the source.

Fix

Move the state evaluation to startIteration(), which is called once per timestep before the Newton-Raphson loop begins. This ensures the resistance stays constant during the iterative solve, allowing convergence. The state is re-evaluated at the next timestep based on the converged currents.

This is the same approach used by TriacElm.startIteration() and DiacElm.startIteration().

Test plan

• SCR with series resistor should converge when gate is triggered (the bug scenario)
• Basic SCR circuit (no series resistor) should still work correctly
• SCR should turn off when current drops below holding current
• SCR should turn on when gate current exceeds trigger current
• TRIAC circuits should be unaffected (no changes to TriacElm)

Generated with Claude Code

[pfalstad]

This is probably good but it causes it to oscillate between two states, is that what it's supposed to do? We should really check in LTspice or some other simulator.

[esaruoho]

@pfalstad — addressed the oscillation in commit a483af3e (already on the branch, pushed after your comment).

The issue: the original PR moved the on/off decision from doStep() to startIteration() to fix the convergence problem, but the decision logic still re-evaluated freshly every timestep using only the current gate/anode currents. So at certain operating points the SCR would flip on at one timestep, decide it shouldn't be on the next, flip off, and oscillate.

a483af3e adopts the latching logic that TriacElm uses:

• "Should turn on" only when gate current crosses the trigger threshold (rising edge), not whenever it's above it
• "Should turn off" only when anode current drops below the holding current (latching condition), not whenever it's below it
• State persists across timesteps via a triggered/holding boolean

This matches what an SCR physically does (latch on once triggered, hold until current drops below holding) and removes the two-state oscillation.

For LTspice validation: I don't have LTspice on this Mac, and ngspice isn't installed either, so I can't run an independent SPICE comparison from here. The latching logic is structurally identical to TriacElm.startIteration() which has been in the codebase for years without similar oscillation reports, so I'm relatively confident, but would value your read on whether the physics is right.