SPICE Generates nonsense with near-zero resistor values. - Page 1
Forum section: electronics / general

author: Zero999
author_rank: Super Contributor
timestamp: September 18, 2024, 01:40:17 pm
content: 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.

author: tom66
author_rank: Super Contributor
timestamp: September 18, 2024, 01:50:56 pm
content: 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.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 18, 2024, 01:57:49 pm
content: Most probably those errors are because of the default values for SPICE parameters.https://ltwiki.org/LTspiceHelp/LTspiceHelp/_OPTIONS_Set_simulator_options.htmThose values can be changed by adding the '.option' directive in the schematic page.

author: RoGeorge
author_rank: Super Contributor
timestamp: September 18, 2024, 02:17:53 pm
content: 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).

author: Siwastaja
author_rank: Super Contributor
timestamp: September 18, 2024, 02:39:31 pm
content: It's a good example of low-level detailsleakingto end-user. And the key finding is thatthis 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.

author: WatchfulEye
author_rank: Regular Contributor
timestamp: September 18, 2024, 07:39:44 pm
content: 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:Title: * C:\Users\Mark\Documents\QSPICE\prectest.qschDate: Wed Sep 18 20:31:46 2024Plotname: Operating PointFlags: realNo. Variables: 6No. Points: 1Command: 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:0V(out)voltage1V(in)voltage2I(V1)current3P(R2)power4P(R1)power5P(V1)powerValues:09.999999999999998e+001.000000000000000e+01-1.953125000000000e-039.999999999999998e-033.155443620884047e-18-1.953125000000000e-02Title: * C:\Users\Mark\Documents\QSPICE\prectest.qschDate: Wed Sep 18 20:33:44 2024Plotname: Operating PointFlags: realNo. Variables: 6No. Points: 1Command: 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:0V(out)voltage1V(in)voltage2I(V1)current3P(R2)power4P(R1)power5P(V1)powerValues:09.999999999999998e+001.000000000000000e+01-9.994506835937500e-049.999999999999998e-039.984020831703431e-19-9.994506835937500e-03The solution computed at extended precision is nearly correct, whereas the solution computed at double precision is completely wrong.

author: Zero999
author_rank: Super Contributor
timestamp: September 18, 2024, 08:04:33 pm
content: This is strange, setting the POT parameter to 0, resolves the error.

author: iMo
author_rank: Super Contributor
timestamp: September 18, 2024, 08:25:21 pm
content: Try.option numdgt=15

author: Zero999
author_rank: Super Contributor
timestamp: September 18, 2024, 09:11:03 pm
content: Quote from: RoGeorge on September 18, 2024, 02:17:53 pmYou also appear to be using a different version of LTSpice to me.Quote from: iMo on September 18, 2024, 08:25:21 pmPost 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 18, 2024, 09:13:59 pm
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: September 18, 2024, 09:29:07 pm
content: Quote from: Zero999 on September 18, 2024, 09:11:03 pm.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}.ENDSLTspice uses single precision by default, afaik, you have to force it with the numdgt=15 to double precision, also in v24..QuotePS: what happens if you do.param tap={limit(T,1f,1.0-1f)} ?

author: Zero999
author_rank: Super Contributor
timestamp: September 18, 2024, 10:00:22 pm
content: Quote from: iMo on September 18, 2024, 09:29:07 pmI 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.

author: Geoff-AU
author_rank: Frequent Contributor
timestamp: September 18, 2024, 11:00:18 pm
content: Quote from: iMo on September 18, 2024, 08:25:21 pmAgreed. But if that doesn't work try.option nonsense=no

author: amyk
author_rank: Super Contributor
timestamp: September 19, 2024, 01:52:24 am
content: Quote from: Siwastaja on September 18, 2024, 02:39:31 pmThey 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 19, 2024, 05:41:48 am
content: Quote from: amyk on September 19, 2024, 01:52:24 amYeah, 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.

author: iMo
author_rank: Super Contributor
timestamp: September 19, 2024, 05:47:54 am
content: Quote from: Zero999 on September 18, 2024, 10:00:22 pmMe 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..

author: Zero999
author_rank: Super Contributor
timestamp: September 19, 2024, 07:47:27 am
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: September 19, 2024, 08:04:43 am
content: 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/ltspiceEdit:typos

author: vk6zgo
author_rank: Super Contributor
timestamp: September 19, 2024, 09:51:41 am
content: 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!

author: tom66
author_rank: Super Contributor
timestamp: September 19, 2024, 10:01:59 am
content: 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.

author: Zero999
author_rank: Super Contributor
timestamp: September 19, 2024, 08:43:59 pm
content: Quote from: vk6zgo on September 19, 2024, 09:51:41 amThat'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.

author: vk6zgo
author_rank: Super Contributor
timestamp: September 20, 2024, 08:49:18 am
content: Quote from: Zero999 on September 19, 2024, 08:43:59 pmReal 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.