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

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?

• Did you try it with a more reasonable divider like 1:10?
– mais
Nov 22, 2021 at 11:41
• @mais the lower the ratio the less obvious is this issue, but it even persist when setting the bottom resistor also to 1 Ohm. And what is "reasonable" of course greatly depends on the application. In my case it is a MOSFET channel in series with a diode at low bias, so the resistance ratio really is even higher than 1e6. Nov 22, 2021 at 11:43
• +1 just for readable graphs on a white background. It's a good question, too. Nov 22, 2021 at 11:56

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.

• Can you explain in simple words why this "error" occurs in the first place? It was added?
– G36
Nov 22, 2021 at 18:08
• @G36 There is a page in the LTspice help titled Integration Methods which gives a basic barebones explanation. Nov 23, 2021 at 1:44
• Sadly Mike Engelhardt has left LTspice dev team following the acquisition of LinearTechnology by Analog Devices. The quality of LTspice has dropped since, IMO. I keep hold of my copy of LTspice IV (you will pull that out of my cold, dead hands! :-) I tried newer LTspice versions and I had lots of troubles. Nov 23, 2021 at 23:33
• @LorenzoDonati--Codidact.com I have several copies of IV and XVII installed, for this particular reason. I miss the fact that you could have many copies of IV installed, without having to share the My Documents folder, which meant that one copy could be "dirty" (with all the custom libraries, etc), while the other clean, to verify the schematic before sending it to 3rd parties. Nov 24, 2021 at 11:00
• Yep. I also "hacked" an installed version of IV so that it could be put on a USB HDD: just a copy of the installation directory and a batch file to set the APPDATA env var to a folder on the same HDD. The software was completely "portable". Very easy for usage on machines you could not install things. This no longer works with XVII. Nov 24, 2021 at 12:18

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.

• Sounds like an even better solution. I will have to try that. Would these methods bring about some disadvantages ? Nov 22, 2021 at 21:48
• @tobalt See answer. I added info on integration methods in LTspice.
– qrk
Nov 22, 2021 at 23:34
• @tobalt you can also read about LTspice maths on Analog Devices site.
– qrk
Nov 23, 2021 at 1:38
• thanks. It sounds like Modified Trapezoidal Integration does merit its choice as a default and both Trapezoidal and Gear have important disadvantages. I will leave the answer from a concerned citizen as the accepted answer, because it has less adverse side effects (although it is of course more clumsy). Nov 23, 2021 at 9:18
• @tobalt What qrk says is true and, depending on what circuit you have, using regular trapezoidal can be the solution (without the added burden of another VCVS). If your circuit involves rapid switching, or (in general) difficulties with convergence, you may get ringing. As usual, placing small (pF, tens, hundreds) capacitors across problem nodes may be a cure. You could use .opt method=gear maxord=3...6 (max is 6, I don't recommend going above 4) because its damping decreases with increasing order, but it also gets slower. Nov 23, 2021 at 10:46