# Why does LT spice limits frequency domain output to 65535 data points?

Background: I ran a simulation and I am generating the S21 gain of a circuit I am working with dembedding and wanted a 100% accurate and wanted a ridiculous amount of data points and when checking my simulation error log it states that the "Number of points reduced from 100000000 to 65535."

Attempted fixes: Up to date 64bit
I have updated to the newest 64 bit of ltspice and looked through the control pannel, but I don't know why the .ac simulation of the circuit is limited to that many points or how to fix it. I can export .trans with a million data points just having an issue with .AC.

Error Message: Number of points reduced from 100000000 to 65535.

spice netlist if desired

* \\my_network_location\
R1 N002 0 10k
R2 N003 0 10k
R3 out 0 50
C1 N002 0 1p
C2 N003 0 1p
C3 out 0 1p
L1 N002 N001 1p
L2 N003 N002 1p
L3 out N003 1p
V1 N001 0 PULSE(0 1 0 100p 100p 400p 1000p) AC 1
;tran 0 10n 0 0.01p
.ac lin 100000000 1 10000g
;tran 0 20n 0 0.01p
;.ac lin 1000000 1 100g
.save V(out)
.backanno
.end


Break the desired frequency range into smaller ranges, each with 65535 points, and run a separate simulation for each range. Concatenate the data from the simulations and plot it using some other tool.

By the way, you will not get 100% accuracy...ever. If you state that as your goal then it makes it very difficult to achieve what you really need in a reasonable amount of time. I doubt very much that you really need 100 million data points.

• Nice workaround. But I'm still wondering what the answer is to the main question. – Huisman Jul 16 at 19:27
• @Huisman I think the only definitive answer could be found by emailing Mike Engelhardt – loudnoises Jul 16 at 20:10
• LTSpice is (or once was) a 32-bit application, living in a maximum 4 GB virtual address space, with typically only 2 GB available to applications. 100M points, would likely consume ~1/4 of the total memory space (assuming single-precision floats). If you wanted output for more than 4 nodes, you'd completely swamp the available memory. 65k points seems like a reasonable limit of "more points than can be usefully displayed in a graph and viewed by the human eye". – The Photon Jul 17 at 1:47

Probably because they are storing something in a uint16 (or equivalent) instead of a 32-bit or 64-bit value.

I've never had the need to simulate over 20pts to get the resolution I need to see where poles are at. I don't see any parasitics listed for the filter so, if your using this for the real world it will differ substantially, and adding more points won't help make a simulation more accurate. Even in adding parasitics the simulation will differ from real world values by a few percentage points, as real components are continuous and not discrete.

I checked the size of the .raw file by adding more and more node voltages and device currents:
The the .raw file increases with 1Mb per node voltage / device current, starting with 2Mb for 1 node voltage/device current.
Without the .save directive, the .raw file grows to 15Mb, which is indeed the 1Mb plus the total number of independent voltage nodes and device currents in Mb.

So, I think the data points have been limited to 1Mb per node voltage/device current, and I'm going with Laptop2d that they're being stored using 16 bits which means a limit of 65535 entries per node voltage / device current.

I've used Signal Chain Explorer to examine XTAL oscillator performance, with Qs of a Trillion at 1.59MHz. The frequency span was a few microHertz.

Since Signal Chain Explorer does not use any matrix convergence, you might describe the BODE (gain, phase) plots as "100% accurate".

Another way to specify the accuracy is to look for numeric noise. There is none.