开云体育

  1. LTspice
  2. Topics

LTspice accuracy, used for calculations and measurements

 

Hi All,

I had a discussion with LTspiceVXII and LTspice24 users about the accuracy of measurement results, shown up in the spice error log. To verify how the constant “pi” is handled, we made a simple example, such as:

.opt plotwinsize=0 numdgt=15 measdgt=15

.param x=pi

.param y=sqrt(x)

.param z=y**2

.op or .tran

.meas z_value param z

.meas x_value param x

Spice error log shows:

z_value: z=3.14159265359

x_value: x=3.14159265359

?

To our surprise, we observed different results between users, although the same setup was implemented.

Mike Engelhardt’s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:

The following constants are internally defined:

Name Value

E 2.7182818284590452354

pi 3.14159265358979323846

K 1.3806503e-23

Q 1.602176462e-19

?

The solver was set to ?Alternate“. We assume, "Alternate" is 1000 times more accurate compared to “Normal”

?

My question is now a general one, independent on the practical significance of pi:

What is the accuracy LTspiceXVII and LTspice24…. Is using for calculations and measurements, shown in the log-file ?

and are there differences between LTspice versions?

?

Thanks a lot in advance

---

regards

Udo

?

?
 
Edited

On 20/04/2025 09:19, Udo Huhn-Rohrbacher via groups.io wrote:
Hi All,

I had a discussion with LTspiceVXII and LTspice24 users about the accuracy of measurement results, shown up in the spice error log. To verify how the constant “pi” is handled, we made a simple example, such as:

.opt plotwinsize=0 numdgt=15 measdgt=15

.param x=pi

.param y=sqrt(x)

.param z=y**2

.op or .tran

.meas z_value param z

.meas x_value param x

Spice error log shows:

z_value: z=3.14159265359

x_value: x=3.14159265359

?

To our surprise, we observed different results between users, although the same setup was implemented.

Mike Engelhardt’s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:

The following constants are internally defined:

Name Value

E 2.7182818284590452354

pi 3.14159265358979323846

K 1.3806503e-23

Q 1.602176462e-19

?

The solver was set to ?Alternate“. We assume, "Alternate" is 1000 times more accurate compared to “Normal”

?

My question is now a general one, independent on the practical significance of pi:

What is the accuracy LTspiceXVII and LTspice24…. Is using for calculations and measurements, shown in the log-file ?

and are there differences between LTspice versions?

?

Thanks a lot in advance

---

regards

Udo

We've had similar discussions here in the past. Printed results in LTspice's logfile are double precision floating point, if measdgt>6 is assigned. Otherwise, it is single precision. Double precision can only support a maximum of 16 decimal digits, and single precision a maximum of 7, although sometimes you will get only 6 (hence the significance of measdgt).

The "constants" pre-assigned in LTspice are variously imprecise:

Constant??? LTspice??? ??? ??? ??? ??? "Accepted or SI definition"
--------------------------------------------------------------------------
e????????? 2.7182818284590452354????? 2.718281828459045235360287471352..
π????????? 3.14159265358979323846???? 3.141592653589793238462643383279..
k??? ??? ? 1.3806503e-23????????????? 1.380649e?23
q??? ??? ? 1.602176462e-19??????????? 1.602176634e?19

You can see that e and π are simply rounded truncations. But k and q were re-defined by SI in 2019, i.e. since the constants were originally coded into LTspice (SWCAD) - possibly even the original Berkeley SPICE. (SI defines elementary charge as "e", not "q".) It seems like LTspice has never updated its values for k and q, even in 24.1.x. It doesn't seem much to get upset about, but LTspice ought to respect the accepted values.

Simulation accuracy is a tricky subject, because the way SPICE works is to approximate the operating point at every step according defined "tolerances" listed in Control Panel > SPICE. Changing any one of those settings may have subtle or major effects on the assumed behaviour of the circuit, i.e. the solution at any one point will probably be "wrong". But because SPICE is assumed deterministic, the result should be same every time you run it with unchanged conditions.

As the solver code is tweaked for convergence, you could expect minor variations in simulated results. After all, if you use enough precision, you will get minor variations in the physically measured value of anything.

--
Regards,
Tony
?
 

Thank you Tony.
?
Regards
Udo
 

On Sun, Apr 20, 2025 at 03:19 AM, Udo Huhn-Rohrbacher wrote:

Spice error log shows:

z_value: z=3.14159265359

?

To our surprise, we observed different results between users, although the same setup was implemented.

Mike Engelhardt’s LTspice XV!! Help-file Copyright ? 1998-2018 Analog Devices Corporation Shows on page 105:

The following constants are internally defined:

Name Value

E 2.7182818284590452354

pi 3.14159265358979323846

Looks OK so far.? The value listed in the Help just has more digits (greater precision) than the values printed in the Error Log file.? It should be obvious why that happened.
?
Do you have the different values for pi that you found from different users?? Can we see them?
?
If the value differed in different LTspice versions, perhaps its value was updated internally.? Anything identified as LTspice 24 was done by Analog Devices, not by Mike Engelhardt as either an LTC employee or an ADI employee.? Mike's value for pi might have been unchanged since before 2000 when he started working on SwitcherCAD III which became LTspice III.? New pairs of eyes (after Mike left) may have noticed that pi's value needed to be corrected.
?

The solver was set to ?Alternate“. We assume, "Alternate" is 1000 times more accurate compared to “Normal”

Let's be really careful about that statement.? The Alternate solver is not necessarily 1000 times more accurate, even if the wording in the Help suggests that.? The Alternate solver has about 3 digits more numerical resolution because of the way its numbers are stored internally, and that extra resolution could be capable of yielding better accuracy, but it does not guarantee it.? Accuracy is not the same as resolution.
?
Because SPICE/LTspice is a nonlinear circuit solver, what Tony said is true, that every result of a circuit calculation is an approximation and not exact.? This is not about numerical resolution or math calculation accuracy; it is because you can't get exact results from circuits that are nonlinear and whose parameters shift with the slightest change in the inputs, making it impossible to solve a voltage or current's value exactly.? This is where the SPICE *TOL settings affect the outcome.? SPICE/LTspice calculates differently when a circuit is 100% linear, and those calculations (and results) theoretically could be as accurate as the math allows them to be - those solutions are theoretically "exact", to the degree that the number resolution and the math allows them to be.
?
The values you printed from parameters has nothing to do with that.? Parameter values are set, or calculated from math formulas and then set, but they are never subject to Newton iterations which are at the core of SPICE's/LTspice's need to approximate nonlinear circuits.? Well, you did calculate a square-root and then a square, so yes, those calculations might be subject to whatever math (in)accuracy there is in your operating system's math routines.
?
Note that when LTspice needs to do a math calculation, it calls the appropriate O.S. math routine to actually do that calculation.? This is why we sometimes get strange error codes, coming from your O.S.'s math routines, which end up in the waveforms - values such as -1.#QNAN.? That is the math routine's error code.? Wine users and Windows users and MAC users might see different error codes in a few cases, because they are OS-specific.
?
Andy
?
 

Thank you Andy for your explanations.
?
I will post results observed from other user for different LTspice versions as soon as possible.
----
Udo
 

After consulting 3 users regarding pi-measurements, we came to the conclusion

pi measurements resulted in ?3.14159265359 (11 digits after the decimal point) observed in the LT - versions

?

user 1 : XVII(x64) 17.037.0;?? LTspice 24.1.6; solver: Alternate & Normal, no difference

user 2 :?LTspice 24.0.8 solver: Normal

user3: LTspice XVII(x64) 17.0.36.0 solver Alternate;

user3:?LTspice XVII(x64) 17.0.36.0 solver: Normal: pi = 3.14159

?

To summarize: There was only a difference in version LTspice XVII(x64) 17.0.36.0 for different solver settings > Alternate vs. Normal

?

We are satisfied with all your clarifications.

?

Thank you very much

?

Regards

Udo

?

?
 
Edited

On Tue, Apr 22, 2025 at 10:24 AM, Udo Huhn-Rohrbacher wrote:

To summarize: There was only a difference in version LTspice XVII(x64) 17.0.36.0 for different solver settings > Alternate vs. Normal

In my opinion, that is very odd that the solver would make a significant difference in the calculation of parameters x, y, and z.
?
The fact that one of them printed a value of 3.14159?strongly suggests that this particular simulation forgot to set NUMDGT MEASDGT to greater than 6.? I think that's the only way the value would be limited to 6 digits.? I think the solver could not be the only difference.
?
On a side note, it is slightly disappointing that LTspice seems to know pi to only 12 digits.? Perhaps it was programmed with only that many digits, making its remaining double-precision digits zeros.? Perhaps Mike Engelhardt found that more digits were truly unnecessary, in a circuit simulation program.
?
All this is without verification on my part.? I am away from my work computer today, and I need to do some re-installations and fixing up, eventually.
?
Thanks,
Andy
?
 

Udo,
?
I have more detail to add to this discussion, which might be marginally helpful to you.
?
First, I was incorrect when I suggested that LTspice's?value for pi maybe had only 12 digits.? That was wrong.? But .MEAS command printouts are limited to 12 digits maximum.
?
The internal value for pi appears to be approximately
3.1415926535897931...
which compares favorably with the value quoted in Help:
3.14159265358979323846
both of which are shown here with more digits than double-precision theoretically provides.? ?(Which means that both numbers might have meaningless digits by the end of what is displayed here.)
?
When comparing your pi and sqrt(x)**2 calculations, they differed by less than 1e-15, so they are at about the limit of double-precision math.? I saw no difference in that calculation between the Normal and Alternate solvers.? But I tried this on only one version of LTspice.? (My plans are to get several versions up and running again, but not for today.)
?
NUMDGT and MEASDGT do things differently:
?
If NUMDGT is omitted or set to 6 or below, LTspice's .raw output file uses single-precision floating point numbers, giving you about 6 digits of resolution.? If NUMDGT is 7 or above, the .raw file uses double-precision and about 16 digits of resolution.? The .raw output file is used to save all voltages and currents, but not internal parameters.? All internal calculations are either double-precision or x86-extended-precision, regardless of the value of NUMDGT.
?
MEASDGT has a useful range from 6 to 12.? Within that range, MEASDGT directly sets the number of digits printed to the .log file.? If omitted or set to a number smaller than 6, it defaults to 6 and .MEAS commands print with 6 digits.? If set to a number greater than 12, it maxes at 12 digits.? That is why we saw pi, x, and z displayed with only 12 digits, despite being internally stored with more resolution and accuracy than that.
?
.MEAS printouts of internal PARAM values do not use the .raw file, so they are unaffected by NUMDGT.? .MEAS printouts that involve voltages or currents (including .MEAS ... PARAM of previous .MEAS command results involving voltages or currents) must read them back from the .raw file, so they are affected by NUMDGT first, and then by MEASDGT.? In that case, NUMDGT indirectly affects the accuracy but not the number of printed digits, whereas MEASDGT sets the number of printed digits.
?
Andy
?

1 - 8 of 8