Simulations Tolerances

Hi eewiz 

eewiz said:

How do I keep LTspice from wasting time-step resources on signals orders of magnitude less than the tolerances.

"Wasted" is quite a loaded value statement/question. :-)

eewiz said:

Pictured here you can see many time-steps wasted on a current in the femtoampere range.

LTspice must still numerically converge when calculating all device currents. I'm assuming the waveform above does not show all device currents? Without any more context than the waveforms, it looks like there are/is some device currents that have nonlinearities. That is why the time steps become very small around certain time points. That is time step control trying to converge on a solution.

Have you tried .options debugtran to see why those time points require so many time points?

mike

Hello Mike:

I ran a controlled comparison of the same .tran with RAW waveform compression enabled and disabled.

With compression enabled:
.options plotwinsize=300
Plotname: Transient Analysis
Flags: real forward
No. Variables: 10066
No. Points:       333605
Offset:    1.0000042796693752e-01
Binary RAW file 13,434,624,944 bytes
Five run average: 428.531 seconds.

With compression disabled:
.options plotwinsize=0
Plotname: Transient Analysis
Flags: real forward nocompression
No. Variables: 10066
No. Points:       335060
Offset:    1.0000042796693752e-01
Binary RAW file 13,493,214,912 bytes
Five run average: 434.112 seconds.

This analysis shows that my rather complex project does not benefit much from compression.
10,066 variables and 335060 - 333605 = only 1455 points not saved.
That amounts to 0.434%, a 57MB (58,589,968 bytes) reduction to a 12.5GB raw file.
LTspice created 335,060 transient points.
With default waveform compression enabled, only 1,455 points were removable because some quantity among the 10,066 stored variables made essentially every point non-discardable.
335,060 points / 100ms run = 3,350,600 points/s or approximately 300ns/point on average.
In my case, .options plotwinsize=300, permits compression of an average maximum of 89.4us into two end points.
At that rate, maximum compression could result in only 1,186 points being saved where the actual is 333,605 points.

With 10,066 variables, compression has a brutal problem.
A time-point can only disappear from the shared transient time axis if throwing it away is acceptable for the entire variable set.
With more than ten thousand node voltages, terminal currents, internal MOSFET currents, diode currents, logic internals, and so forth, there is almost always at least one waveform violating the compression tolerance at nearly every time-point.

I realize that the solver’s time-steps and the RAW file’s saved points are two different layers.
I decided to explore the compression layer first, before diving into the solver tolerances.

Is there a treatise that covers use of the available compression controls under various conditions leading to greater compression?

Hi eewiz ,

eewiz said:

With default waveform compression enabled, only 1,455 points were removable because some quantity among the 10,066 stored variables made essentially every point non-discardable.

Probably.

eewiz said:

Is there a treatise that covers use of the available compression controls under various conditions leading to greater compression?

I don't believe so. Have you played with Settings > Compression in addition to just the plotwinsize?

I will also ask. Would be good to have some theory written down.

eewiz said:

I realize that the solver’s time-steps and the RAW file’s saved points are two different layers.
I decided to explore the compression layer first, before diving into the solver tolerances.

Have you tried just saving the data you require over the time periods you require? Or, at least being much more selective about what is saved?

eewiz said:

I ran a controlled comparison of the same .tran with RAW waveform compression enabled and disabled.

I'm still wondering if .options debugtran would be revealing.

mike

Hello Mike:

I have run .debugtran many times.
Historically I got scores as high as 7.xxx.
I replaced the highest scoring model (NE555) with other models until obtaining these highest scores.

Device Convergence Difficulty Score:
    xch2:xlogic:xsync:u18:Q19     : 2.122514
    xch2:xlogic:xclk:u4:xin2:AE1     : 2.105900
    xch2:xlogic:xclk:u2:xin2:AE1     : 2.105900
    xch1:xlogic:xclk:u4:xin2:AE1     : 2.105851
    xch1:xlogic:xclk:u2:xin2:AE1     : 2.105851
    xch1:xlogic:xsync:u18:Q19     : 2.047826
    xch1:xsw2:M2     : 1.908211
    xch2:xsw1:M1     : 1.790880
    xch2:xsw1:M2     : 1.676162
    xch1:xsw2:M1     : 1.603939
    xch1:xsw1:M1     : 1.580818
    xch1:xsw1:M2     : 1.508841
    xch1:xlogic:xclk:u4:A1     : 1.501496
    xch1:xlogic:xclk:u2:A1     : 1.501496
    xch2:xlogic:xclk:u2:A1     : 1.501446
    xch2:xlogic:xclk:u4:A1     : 1.501397
    xch2:xsw2:M2     : 1.453134
    xch2:xlogic:xsync:u18:Q29     : 1.287637

The highest scoring model is still this NE555 model.
* NE555 schematic from ST-datasheet
.SUBCKT NE555S 1 2 3 4 5 6 7 8
* pin-1:GND pin-2:trigger pin-3:output pin-4:reset
* pin-5:ctrl pin-6:thresh pin-7:dis pin-8: VCC
Q1 N005 N011 N013 0 NP
Q2 N005 6 N011 0 NP
Q3 N006 N012 N013 0 NP
Q4 N006 5 N012 0 NP
R1 N013 1 10K
Q5 N006 N006 N003 0 PN
Q6 1 N006 N001 0 PN
Q7 N005 N005 N002 0 PN
Q8 N010 N005 N001 0 PN
Q9 N016 N007 N004 0 PN
R2 8 N004 1K
Q10 N024 N019 N016 0 PN
Q11 1 N022 N019 0 PN
Q12 N023 N018 N016 0 PN
Q13 1 2 N018 0 PN
R3 8 5 5K
R4 5 N022 5K
R5 N022 1 5K
Q17 N017 N010 1 0 NP
Q18 N010 N023 1 0 NP
Q19 N015 N017 1 0 NP
Q23 N007 N007 8 0 PN
Q25 N015 N007 8 0 PN
R7 N015 N010 4.7K
Q26 N025 4 N014 0 PN
Q27 7 N025 1 0 NP
Q28 N008 N015 N020 0 NP
R8 8 N008 6.8k
R9 N020 N025 100
R10 N020 1 4.7k
R11 N021 N020 220
Q29 3 N021 1 0 NP
Q30 8 N009 3 0 NP
Q31 8 N008 N009 0 NP
R12 N009 3 3.9K
R13 8 N002 4.7k
R14 8 N003 4.7k
R15 8 N001 830
R16 N023 1 100k
R17 N024 1 100k
D1 N014 N017 DD
R18 N007 N014 5k
D2 3 N008 DD
.model D D
.model NP NPN(BF=125 Cje=.5p Cjc=.5p Rb=500)
.model PN LPNP(BF=25 Cje=.3p Cjc=1.5p Rb=250)
.model DD D(Is=1e-12 Cjo=1p Rs=5)
.ends NE555S

Filtering the NE555 from the .debugtran data yields:
Device Convergence Difficulty Score:
    xch2:xlogic:xsync:u18:Q19     : 2.122514
    xch1:xlogic:xsync:u18:Q19     : 2.047826
    xch2:xlogic:xsync:u18:Q29     : 1.287637
    xch1:xlogic:xsync:u18:Q29     : 1.252684
    xch2:xlogic:xsync:u18:Q28     : 1.245191
    xch1:xlogic:xsync:u18:Q28     : 1.209696
    xch2:xlogic:xsync:u18:Q30     : 1.131606
    xch1:xlogic:xsync:u18:Q30     : 1.098379
    xch2:xlogic:xsync:u18:Q27     : 1.038284
    xch1:xlogic:xsync:u18:Q27     : 1.015853
    xch2:xlogic:xsync:u18:Q17     : 0.966406
    xch1:xlogic:xsync:u18:Q17     : 0.938946
    xch1:xlogic:xsync:u18:Q18     : 0.804656
    xch2:xlogic:xsync:u18:Q18     : 0.799874
    xch2:xlogic:xsync:u18:Q31     : 0.656809
    xch2:xlogic:xsync:u18:Q25     : 0.655182
    xch1:xlogic:xsync:u18:Q31     : 0.648724
    xch1:xlogic:xsync:u18:Q25     : 0.634624
    xch2:xlogic:xsync:u18:D2     : 0.461290
    xch1:xlogic:xsync:u18:D2     : 0.447782
    xch2:xlogic:xsync:u18:Q12     : 0.358107
    xch1:xlogic:xsync:u18:Q12     : 0.352931
    xch2:xlogic:xsync:u18:D1     : 0.341641
    xch1:xlogic:xsync:u18:D1     : 0.333507
    xch1:xlogic:xsync:u18:Q10     : 0.294709
    xch2:xlogic:xsync:u18:Q10     : 0.287511
    xch2:xlogic:xsync:u18:Q8     : 0.265573
    xch1:xlogic:xsync:u18:Q8     : 0.263009
    xch2:xlogic:xsync:u18:Q13     : 0.234515
    xch1:xlogic:xsync:u18:Q13     : 0.234416
    xch2:xlogic:xsync:u18:Q26     : 0.198181
    xch1:xlogic:xsync:u18:Q26     : 0.194287
    xch2:xlogic:xsync:u18:Q4     : 0.184279
    xch1:xlogic:xsync:u18:Q4     : 0.181173
    xch2:xlogic:xsync:u18:Q6     : 0.169095
    xch1:xlogic:xsync:u18:Q6     : 0.164954
    xch1:xlogic:xsync:u18:Q7     : 0.155291
    xch2:xlogic:xsync:u18:Q7     : 0.153369
    xch2:xlogic:xsync:u18:Q3     : 0.152334
    xch2:xlogic:xsync:u18:Q1     : 0.150164
    xch1:xlogic:xsync:u18:Q3     : 0.148735
    xch1:xlogic:xsync:u18:Q1     : 0.146516

It says to me that the all-transistor model of the NE555 is the most difficult thing for LTspice to process followed by the 74HCxxx models.
And, that scores under 3 generally do not lead to the femtosecond crawl.

I understand that plotting a femtoampere-range current does not by itself prove that particular current is the variable controlling the time step.

My question is about the accepted transient points and the resulting RAW-file cost.
I would like to determine which of my 10,066 variables is causing the closely spaced transient points when I believe that there should not be any accepted points.

I normally run with .options plotwinsize=0 because I get no benefit from lossy waveform compression.
Therefore, when LTspice accepts a large number of closely spaced transient points, each accepted point causes the full set of saved waveform values to be written to the RAW file.
In a large schematic, that can produce a RAW file approaching 100 GB even though the visible activity associated with the dense points may be many orders of magnitude below the user-selected absolute tolerances.

I have tried .options debugtran.
The 26.0.1 help says this produces relative device and node convergence difficulty scores, with values below 1 generally negligible and values above approximately 50 problematic.

What I do not understand is how those scores answer the timestep question.
Does debugtran identify only Newton/device convergence difficulty, or does it also identify points restricted by transient tolerance control?
How do I correlate a reported debugtran device or node score with the particular time intervals where the RAW file contains extremely dense accepted points?
Given:
.options abstol=1e-6
.options chgtol=1e-7
.options trtol=7
.options vntol=1e-4
.options reltol=3e-3
which option controls whether femtoampere-range or similarly tiny activity is allowed to require additional accepted transient points?

I am not asking LTspice to skip convergence.
I am trying to determine why these accepted timestep densities occur despite the specified absolute tolerances, and whether the resulting multiplication of RAW-file storage is avoidable.

All for now

Hi eewiz ,

eewiz said:

I am trying to determine why these accepted timestep densities occur despite the specified absolute tolerances, and whether the resulting multiplication of RAW-file storage is avoidable.

At this point, the only way to really analyze the situation would be to have your schematic as a test jig.

eewiz said:

The highest scoring model is still this NE555 model.
* NE555 schematic from ST-datasheet
.SUBCKT NE555S 1 2 3 4 5 6 7 8

Yeah. Can't really help with that. Looks like the NE555 is discussed in many LTspice forums, including groups.io. That said, if you have a large number of A devices, you will inevitably end up with a lot of time points at the signal edges.

eewiz said:

I have run .debugtran many times.
Historically I got scores as high as 7.xxx.

You are correct, nothing suggests convergence problems. 

eewiz said:

Given:
.options abstol=1e-6
.options chgtol=1e-7
.options trtol=7
.options vntol=1e-4
.options reltol=3e-3
which option controls whether femtoampere-range or similarly tiny activity is allowed to require additional accepted transient points?

Do you get "better", fewer GB, results using the Normal solver? Are you using the Normal solver? 

mike

Hello Mike:

Yes I am using the Normal Solver and the Gear Method.

eewiz,

If you have more than 10,000 variables that are being simulated and saved, how likely is it that you will ever want to look at 9,900 of them?  I think it would be a really good idea to add a .SAVE command and save only the ones that matter to you.  I think most of your 10,000 variables are likely buried in subcircuits and you might never want to look at them.  Don't make LTspice save all of them.  It just slows your computer down, and (I think) it affects the waveform compression in ways you do not want it to.  By eliminating the ones that end up with micro fine timesteps, what remains might be easily compressible.

Either way, the .RAW file gets smaller, and faster to save.

Admittedly it would be better to figure out what makes it spend time trying to converge, since that could be the bigger time-hog.  But that is not so easy.

Regards,

Andy

Hello Andy:

Finding and recording a hundred or more variables like V(XCH1:XLOGIC:XSYNC:UNDR,V-24) into a .save command is task I tried once and never wish to repeat.
And no matter what, tomorrow there will be a few more signals to add/manage.
And maybe five minutes from now, one might need to follow a current through several levels of hierarchy and none of those signals exist in the .raw file requiring a rerun.

Plus, once you run a .save you loose visibility of all the variable names that were not .saved.

Yes, I have tried using the .save command and have deemed the benefit unworthy of the expense.

All for now