SPICE Generates nonsense with near-zero resistor values.

[Zero999]

I'm sure many here know of this, but I thought I'd start a thread to make others aware, as I've been recently bitten by this!

SPICE doesn't like resistors with very low values. More precisely it's a problem with the current is low.

Here's an example of it giving junk results.

The idea is to simulate a potentiometer, as discussed in a thread a few years ago. Rather than limiting the wiper range to 1% and 99%, I added a small value to each resistor. The currents are show, through the upper (POTa) and lower (POTb) parts of the potentiometer. The should be equal, irrespective of the resistor values, because they're connected in series, but the results don't show that. The calculated currents through the lower resistors are correct, 1mA, but the ones through the upper resistors are all over the place, until the minimum resistance is 100u.
https://www.eevblog.com/forum/beginners/simulating-potentiometers-using-ltspice/

I believe this is due to the limit precision of floating point numbers.

[tom66]

Yes, probably a floating point issue.

IEEE754 32-bit float has 24 bits mantissa available. In order to accurately calculate a sum of two FP numbers without loss of precision, the numbers should not be more than 2^24 different in magnitude, or approximately 7 orders of magnitude.

For instance, 1 + 0.0000001 will correctly output 1.0000001, but 1 + 0.00000001 will output 1. 

For 64-bit FP, there are 53 bits in the mantissa, allowing for a range of nearly 16 orders of magnitude.

This is a minimum requirement.  It is still possible to construct FP numbers that do not sum well within this range, such as 1/3 + 1/3 at any precision.

It seems your issue is summing 10k and 1n does not work correctly, which is 13 orders of magnitude.  This suggests that SPICE is using 64-bit FP registers (good choice), but the numerical error is preventing convergence.

If it could be rebuilt with a bignum library, it's likely such errors would not occur, but the performance of the program would be far worse.

[RoGeorge]

Most probably those errors are because of the default values for SPICE parameters.
https://ltwiki.org/LTspiceHelp/LTspiceHelp/_OPTIONS_Set_simulator_options.htm
Those values can be changed by adding the '.option' directive in the schematic page.

[RoGeorge]

Another aspect, your default values might have already been changed (it is also possible to change some of them from the LTspice control panel, too, so maybe they were changed in the past and forgot to put them back).  Saying this because your .asc attachment gives very different results when run on my computer (Ubuntu + WineHQ + LTspice v17.0.37.0).

[Siwastaja]

It's a good example of low-level details leaking to end-user. And the key finding is that this is unavoidable. It leaks anyway, they can just choose how:

1) They can choose higher precision numbers, and loss of performance. Nearly 100% of users would be pissed and complain, or,
2) They can choose performance over numerical correctness in rare corner cases. But in some cases users accidentally (or purposely) create those conditions and are pissed.

It's a lose-lose situation.

[WatchfulEye]

This is an internal precision problem. The numerical problem described here is extremely ill-conditioned, and hence the precision of internal steps is critical.

The problem is much improved by running at a higher precision. Here are two spice runs with an example of the circuit, with the regularising resistance set to 1p Ohm (1f Ohm gives nonsense results in both sims). One run at double precision, and one sim run at extended precision.

Code: [Select]

Title: * C:\Users\Mark\Documents\QSPICE\prectest.qsch
Date: Wed Sep 18 20:31:46 2024
Plotname: Operating Point
Flags: real
No. Variables: 6
No. Points: 1                   
Command: QSPICE64, Build Sep 13 2024 12:02:15
.param POT=1
.param temp=27
.alias I(R2) (0.0001mho*V(0,out))
.alias I(R1) (1000000000000mho*V(out,n01))
Variables:
0 V(out) voltage
1 V(in) voltage
2 I(V1) current
3 P(R2) power
4 P(R1) power
5 P(V1) power
Values:
0 9.999999999999998e+00
1.000000000000000e+01
-1.953125000000000e-03
9.999999999999998e-03
3.155443620884047e-18
-1.953125000000000e-02

Title: * C:\Users\Mark\Documents\QSPICE\prectest.qsch
Date: Wed Sep 18 20:33:44 2024
Plotname: Operating Point
Flags: real
No. Variables: 6
No. Points: 1                   
Command: QSPICE80, Build Sep 13 2024 12:01:08
.param POT=1
.param temp=27
.alias I(R2) (0.0001mho*V(0,out))
.alias I(R1) (1000000000000mho*V(out,n01))
Variables:
0 V(out) voltage
1 V(in) voltage
2 I(V1) current
3 P(R2) power
4 P(R1) power
5 P(V1) power
Values:
0 9.999999999999998e+00
1.000000000000000e+01
-9.994506835937500e-04
9.999999999999998e-03
9.984020831703431e-19
-9.994506835937500e-03

The solution computed at extended precision is nearly correct, whereas the solution computed at double precision is completely wrong.

[Zero999]

This is strange, setting the POT parameter to 0, resolves the error.

[iMo]

Try

.option numdgt=15

[Zero999]

Another aspect, your default values might have already been changed (it is also possible to change some of them from the LTspice control panel, too, so maybe they were changed in the past and forgot to put them back).  Saying this because your .asc attachment gives very different results when run on my computer (Ubuntu + WineHQ + LTspice v17.0.37.0).

You also appear to be using a different version of LTSpice to me.

Try

.option numdgt=15

Post the model. It might not be an issue, if it internally limits the wiper position from 0.1% to 99.9%.

I chose to use discrete resistors, rather than a model for A couple of reasons. It means it can be uploaded without having to use a zip with the symbol files. It's more flexible. The values of the upper and lower resistors can be manipulated and the currents and voltages more easily plotted.

This thread is not about being able to simulate a potentiometer. I know how to do that and can easily modify the circuit so it simulates perfectly. It's to alert others that there are limits to the accuracy of the floating point calculations done by SPICE which can result in erroneous output, with no warning.

[SiliconWizard]

Yes, it's all a matter of FP precision. I got a different result though, and that's because I use the Alternate solver. I switched to Normal solver, and got the exact same values as you. With the Alternate (which gives me "better" results most of the time), the errors I get are there, but not as drastic.

Surprising that this simple circuit would not give the exact same value for what's in the same branch (errors in the node voltage between the resistors would be more expected), but in the end it's all in the way the simulator transforms it into a matrix and there are clear differences between the solvers.

One additional parameter to figure out here is whether LTSpice uses default parasitic capacitance and inductance (even if very small) for resistors and voltage sources. That would explain that the circuit, then being made of reactive components, would give a "harder time" to the solver. But even without that, it's again all in how the circuit is transformed into a matrix. You could get an error in voltages, but the same current, or different currents but a more accurate voltage, or both having a large error.

A different way of implementing the circuit analyzer should give at least the same current through both resistors, as this is the same branch (the "out" node being unconnected). FP errors are to be expected, but the fact the analyzer sees two different branches here is not that good. Just my 2 cents.

[iMo]

Try
.option numdgt=15

Post the model. It might not be an issue, if it internally limits the wiper position from 0.1% to 99.9%.

.SUBCKT pot 1 2 3 T=0.5 R=10k
.param tap={limit(T,1m,.999)}
R0 1 3 {R*(1-tap)}
R1 3 2 {R*tap}
.ENDS

LTspice uses single precision by default, afaik, you have to force it with the numdgt=15 to double precision, also in v24..

Historically "numdgt" was used to set the number of significant figures used for output data. In LTspice, if "numdgt" is set to be > 6, double precision is used for dependent variable data.

PS: what happens if you do

.param tap={limit(T,1f,1.0-1f)} ?

[Zero999]

Try
.option numdgt=15

Post the model. It might not be an issue, if it internally limits the wiper position from 0.1% to 99.9%.

.SUBCKT pot 1 2 3 T=0.5 R=10k
.param tap={limit(T,1m,.999)}
R0 1 3 {R*(1-tap)}
R1 3 2 {R*tap}
.ENDS

LTspice uses single precision by default, afaik, you have to force it with the numdgt=15 to double precision, also in v24..

Historically "numdgt" was used to set the number of significant figures used for output data. In LTspice, if "numdgt" is set to be > 6, double precision is used for dependent variable data.

PS: what happens if you do

.param tap={limit(T,1f,1.0-1f)} ?

I couldn't be bothered to draw a symbol or find the one I have saved somewhere, so I used the nearest looking one to a potentiometer in the default LTSpice install and added an arrow to make it look more like a potentiometer.

Here are the results with the modification you suggested to the model. It produces a similar error, when the wiper limit is make nearer to zero.

[Geoff-AU]

Try

.option numdgt=15

Agreed.  But if that doesn't work try

.option nonsense=no

 

[amyk]

It's a good example of low-level details leaking to end-user. And the key finding is that this is unavoidable. It leaks anyway, they can just choose how:

1) They can choose higher precision numbers, and loss of performance. Nearly 100% of users would be pissed and complain, or,
2) They can choose performance over numerical correctness in rare corner cases. But in some cases users accidentally (or purposely) create those conditions and are pissed.

It's a lose-lose situation.

They could also choose to dynamically increase precision from hardware FP to software arbitrary-precision when they detect it's necessary, like some programming languages do, but that's even more complexity.

[Siwastaja]

It's a good example of low-level details leaking to end-user. And the key finding is that this is unavoidable. It leaks anyway, they can just choose how:

1) They can choose higher precision numbers, and loss of performance. Nearly 100% of users would be pissed and complain, or,
2) They can choose performance over numerical correctness in rare corner cases. But in some cases users accidentally (or purposely) create those conditions and are pissed.

It's a lose-lose situation.

They could also choose to dynamically increase precision from hardware FP to software arbitrary-precision when they detect it's necessary, like some programming languages do, but that's even more complexity.

Yeah, that crossed my mind and in a case like this it might not be even difficult to do, like just loop through all values to find min and max (regardless of units) and decide accuracy (float/double/bignum lib) based on ratio between largest and smallest number. But then again someone would find another corner case where the detection would not work correctly.

[iMo]

..I couldn't be bothered to draw a symbol or find the one I have saved somewhere, so I used the nearest looking one to a potentiometer in the default LTSpice install and added an arrow to make it look more like a potentiometer..

Me too.. Therefore I install Bordodynov's library pack, you will get megatons of stuff which you might find useful..

PS: it looks the 1nano is the threshold when it gets weird..
Interestingly you can enter 0 value for a resistor, but as a result of math you cannot..

[Zero999]

I had loads of libraries installed before, but it messed things up, when posting the .asc files, so I uninstalled them. It would be much easier if there was a way to tell if the .asc has non-standard symbols and it were possible to embed them.

It works when 0 is entered for the resistor value, because the resistor is eliminated from the circuit before it's simulated, if it sees a zero. It's similar to inserting a component with nothing connected to it. If it encounters a zero Ohm resistor during the simulation it generates an error because the calculation will involve dividing by zero.

It's interesting that it depends on which way round the resistors are connected. The error only occurs when the upper resistor is 1fΩ. When the lower resistor is 1fΩ, it has no problem with 0.001fV on R2, but when the upper resistor 1fΩ, the voltage across R4 is rounded to 10V, which is the same as the supply, so the current through R3 is erroneously calculated to be zero.

[iMo]

At ADI's site is the EZone with forum for LTspice, it seems there are people active from the LTspice design team (I escalated something in past there and got answers).

https://ez.analog.com/design-tools-and-calculators/ltspice

Edit:typos

[vk6zgo]

Your last 5 words are redundant.
SPICE also simulates Op Amps with LC tuned circuits at the input & output as working perfectly, but real world ones are quite nice oscillators!

[tom66]

Using long double is also an option, or on some architectures quadruple precision can make use of SSE/MMX capability on the processor.  This will be slower than using the native FP engine unless the entire program is vectorised though as moving data in/out of the vector units is usually the slow part.

[Zero999]

Your last 5 words are redundant.
SPICE also simulates Op Amps with LC tuned circuits at the input & output as working perfectly, but real world ones are quite nice oscillators!

That's completely unrelated to this issue.

If an op-amp circuit oscillates in real life, but simulates correctly, the most likely issue it the models: op-amp being the prime suspect, failing that, the user not modelling the load correctly i.e. using a plain resistor, when it's a transmission line.

[vk6zgo]

Your last 5 words are redundant.
SPICE also simulates Op Amps with LC tuned circuits at the input & output as working perfectly, but real world ones are quite nice oscillators!

That's completely unrelated to this issue.

If an op-amp circuit oscillates in real life, but simulates correctly, the most likely issue it the models: op-amp being the prime suspect, failing that, the user not modelling the load correctly i.e. using a plain resistor, when it's a transmission line.

Real LC tuned circuits are not identical in every respect, slight detuning of either the input or output one turns the negative feedback into positive feedback.
Newbies get caught with this quite often, & ask about it in the beginners section.