LTspice fails at a simple two-resistor voltage divider. How can I fix it?

Question

During some simulations, I noticed some oddities and narrowed it down to the following problem:

This is is simple voltage divider using two resistors. The four traces show:

1. supply voltage
2. current through R1. Everything is good so far
3. the voltage across R1. The DC voltage is missing.
4. consequently, the resistance of R1 is not 1 ohm, but it deviates by 10s of ohms.

I thought that this was a problem with limited precision, so I added the .options numdgt=15, but it didn't change anything. How can I get this right?

Answer 1

The problem is known and only happens in versions of LTspice XVII after May (or June? don't remember) 2019. It doesn't happen in version prior to that, or LTspice IV. If you add a VCVS across the 1 Ω resistor with the value of 1, you'll get the correct voltage.

Search in the LTspice group for problem with modified trap. There are also files similar to yours, ProblemWithModTrap.asc and ProblemWithModTrap2.asc (you'll need registration, to avoid spam).

---

I'll try to address at least a part of G36's comment.

As Ste Kulov mentions in the comments, there is a page in the help (LTspice > Integration Methods) that tries to explain why there is such a reading with the modified trapezoidal solver. The page has two parts: the first explains how the modified trap works, and the second explains why the readings are how they are. While the first part explains very well how the modified trap works, in my, personal opinion, the second part is wrong, for these reasons:

1. The exact same schematic, used with versions of LTspice XVII prior to May 2019, or LTspice IV, and which have the exact same settings, do not exhibit the same behaviour. Therefore whatever it is in the newer versions of LTspicethat affects the response must have been introduced around May 2019 or later.

2. The schematic (as seen in the help) is comprised of a simple voltage source, together with a resistive divider. There are no reactive elements, there are no behavioural expressions, therefore there are no states. Not only the integration routine is not even called, but it's a simple matter of a sine voltage and a divider, therefore there cannot be any oscillations. No oscillations means there is no average, whatsoever, and the only waveform that should be seen is the 1 mV peak one. What's more, for the versions of LTspice after May 2019, if the normal trap solver is used, there are no artifacts, which only reinforces the idea that there are no oscillations and, therefore, there cannot be any artifacts due to averaging.

What is certain: the modified trap is mostly a post-processing applied to the waveforms. If there are oscillations, they still exist as the solver finds them, but they are not displayed due to this post-processing.

Answer 2

If you use Gear or trapezoidal for the Default Integration method, things will compute as expected. You'll find this under the SPICE tab of the control panel. You still need to use double precision math (numdgt=15 setting).

Edit:
Since you asked about the differences in integration methods in LTspice, here is a posting in alt.sci.engineering by Mike Engelhardt (brains behind LTspice), 21 Feb 2004.

Integration Method Explained:
Gear, compared to trap, has the advantage that it is numerically more stable, but less accurate. In principle, it's better defined because Steven Gear even specifies when you change integration order and timestep size. PSpice is hard-wired to use Gear(well, the docs say it a proprietary algorithm, but it acts like Gear.) The inaccuracy of Gear comes from the fact it dampens the circuit. The amount of dampening decreases with decreasing step size.

Trapezoidal is faster and usually much more accurate. Occasionally it's not as numerically stable, especially when running non-physical circuits described with macro-models. It has the disadvantage that it can ring as a simulation artifact. This can be disconcerting to novice SPICE users. Most SPICE programs have some form of Trapezoidal integration as the default. There's fair bit of leeway in trap implementations, so I call them all affectionately cowboy integration.

Modified-trap is a proprietary algorithm that has the speed and accuracy of trap but precisely cancels traditional trap ringing. It is the most accurate method I know of.

If you're using LTspice, use the default of modified trap. Use trap and Gear only as diagnostics. Gear will let you duplicate some PSpice simulations. For example, if LTspice says a circuit is unstable but PSpice says it's stable, you can switch LTspice to use basically the same integration method of PSpice to duplicate it's erroneous results for diagnostic purposes. Switch to pure trap instead of Modified-trap if you want to see if your circuit is trap ringing. If the trap ringing that Modified- trap cancels is spread over several circuit nodes, then the cancellation might not work well. Using pure trap lets you investigate potential simulation artifacts.

There's yet another method called backward Euler. Where mod-trap, trap, and Gear are all implemented as 2nd order methods in SPICE programs, backward Euler is the 1st order method. 1st order mod-trap, trap, and Gear are all identical and simply called backward Euler. You can use this method by adding the SPICE directive ".options maxord=1" to your simulation. Backward Euler is as stable if not more so than Gear, but is the slowest and least accurate of all methods.

Solvers Explained:
The alternate solver runs with about 1000x more internal accuracy in the sparse matrix package but at half the simulation speed. The advantage of it is that is solves certain convergence problems. Here's a simple deck that demonstrates that it's more accurate then the normal solver:

*
V1 1 0 ac 1
R1 1 2 1T
C1 2 X 1
R2 X 3 1T
C2 3 0 1
.ac oct 10 1 1Meg
.end

Node V(x) should be -6dB for all frequencies. However, the normal solver(and other other SPICE program) makes errors solving this matrix. If you switch to LTspice's alternate solver, you get close to the correct answer. The alternate solver was released on June 13, 2003 and was discussed in message number 434 of this group.

On Gear vs. Trap, here's a circuit that will illustrate that Gear is over-stable, that is, it incorrectly dampens the circuit in the interest of avoiding convergence problems:

*
L1 1 0 10u Rser=0 Rpar=0
C1 1 0 100p
I1 1 0 PWL(0 0 .1u 1 .2u 0)
.tran 1m 1m
.end

(Mod-)Trap will give the correct answer, that is, that the current spike starts the tank ringing and the ringing then continues indefinitely. If you run that circuit in PSpice, it will only ring a few times. This over- stability of the Gear causes an error and is what makes many circuits converge in PSpice but not LTspice. PSpice is giving you the wrong answer.