incmode branch -- how incmode is supposed to work

The incmode branch has an example with a convergence problem and
incmode makes a difference, with a proposed change to fall back to
non-incmode more often and later in the cycle.

It's incorrect.

The reason for the convergence problem has nothing to do with the BJT,
everything to do with the switch.  Ron=1e12, Roff=1e-10 ...  That's a
ratio of 1e22 .. 22 decimal digits needed to represent the difference.

This leads to numeric precision problems in the matrix, regardless of
incmode.  Since incmode changes the order of calculations, precision
and overflow problems could show in a different way, leading to the
belief that incmode might be part of the problem.  It isn't.  The
result is wrong either way.

Regarding the line that reverts to non-incmode at the TRLOW (usually
6th) iteration, changing it to 6, 12, 18, etc ...   This doesn't solve
any problems.

The reason to revert to non-incmode ever is to stop accumulation of
roundoff errors.  These errors occasionally come up in the first few
iterations of a time step when there are big changes between
iterations, when iteration is having trouble.  On later iterations,
usually the solution is close and doing refinement with small changes.
This is where incmode actually helps.


What incmode does .....  Instead of building the entire matrix from
zero, it starts with the old matrix and adds corrections to update to
the new value.  This saves time because anything that is constant or
converged does not need to be loaded.

The speedup can be much more than expected because it works together
with several other optimizations including bypass, lubypass, lcbypass,
fbbypass, traceload which are mutually dependent.  You can turn the
options on and off independently, but the benefit of using them
together exceeds the sum of the parts.