Post Go back to editing

Is it possible to force a fixed internal time step in LTspice transient simulation?

Category: Software
Product Number: LTspice
Software Version: 24.1.9 / 26.0.1

Hello,

I am using LTspice to perform transient simulations of a complex coupled oscillator circuit that includes switching devices.

As the circuit becomes more complex, I have observed that the simulation results can differ depending on the LTspice version. When I compared the raw data files generated by different LTspice versions, I noticed that the transient time points are not identical. In other words, the internal adaptive time-step sequence appears to be different between versions.

This difference seems to affect the extracted oscillation frequency, phase relationship, and final state of the coupled oscillator system.

I understand that LTspice uses an adaptive time-step algorithm for transient analysis. I also understand that the maximum time step can be limited using the fourth parameter of the .tran statement. For example:

.tran 0 {time} 0u 1n uic


However, this only limits the maximum time step. It does not force LTspice to use a completely fixed internal time step, since the simulator can still use smaller time steps depending on switching events, convergence behavior, or local truncation error.

My questions are:

1. Is there any option in LTspice to force a completely fixed internal time step during transient simulation?
2. If a fixed internal time step is not supported, what is the recommended way to minimize version-dependent differences caused by adaptive time stepping?
3. Are there recommended .tran or .options settings for complex switching oscillator circuits where reproducibility of frequency, phase, and final state is important?


In particular, I would like to know whether the transient integration grid can be made deterministic and uniform across LTspice versions, so that the same netlist produces the same sequence of time points and more reproducible raw waveform data.

Thank you.

  • Hi  ,

    However, this only limits the maximum time step. It does not force LTspice to use a completely fixed internal time step, since the simulator can still use smaller time steps depending on switching events, convergence behavior, or local truncation error.

    I think you answered your own question. LTspice just wouldn't be a SPICE engine if you had a lower bound. It would be something else altogether.

    In particular, I would like to know whether the transient integration grid can be made deterministic and uniform across LTspice versions, so that the same netlist produces the same sequence of time points and more reproducible raw waveform data.

    Unlikely. With each improvement to LTspice, the dev team balances usability, features, speed and determinism (those are optimized). LTspice is far more deterministic than it used to be. Asking for a setup that would essentially make LTspice less deterministic and at the same time be more deterministic is probably fraught. In general, LTspice versions move forward in determinism. There are edge cases, and we add those to the test suite. If you have such a case, would love to try it. 

    1. Is there any option in LTspice to force a completely fixed internal time step during transient simulation?
    2. If a fixed internal time step is not supported, what is the recommended way to minimize version-dependent differences caused by adaptive time stepping?
    3. Are there recommended .tran or .options settings for complex switching oscillator circuits where reproducibility of frequency, phase, and final state is important?

    Answer to all three is make the max time step as small as possible. Plus:

    I am using LTspice to perform transient simulations of a complex coupled oscillator circuit that includes switching devices.

    Again, you've answered almost all of your questions here. Switching behavior (even mathematically discontinuous behavior) is a hard problem in iterative simulation, and essentially the raison d'être of LTspice; simulate non-linear systems.

    mike