# How to trace down why LTSpice simulation is slow?

I have a pretty complicated schematic in LTSpice (at least it is the most complicated schematic I ever tried to simulate in LTSpice).

For some reason simulation of just 20 ms turns into about 15 seconds to accomplish.

I have several theories:

1. The schematic is complicated, computer is slow (it is really not very powerful) so I can not expect anything faster.
2. I have some trouble in the schematic cosing LTSpice to short the iterations and therefore - slowdown the simulation process.

If I'd skip the first, how can I trace down the problem part of the schematic?

I tried:

• cut some suspicious parts of the schematic to define if the simulation became reasonably fast (did not help - simulation time vary from something 10 to 20 seconds)
• put initial conditions to "charge" capacitors to intended voltages (it helped as I could make the simulation time shorter: 20 ms instead of 100-200 ms)
• I defined Maximum Timestep as 1 us:

• I put 10 MOhms resistors between optos and ground

Is there any method to find a problem node?

I think that I will not ask the community to find the problem for me as I'd better learn to do it myself. So this is why I did not put my schematic in the question.

• You have a fairly complex circuit. Can you simulate say the three parts by themselves without any problem? Does it help to replace optocouplers with dependent current sources? Does it help to not float V5? – winny Oct 10 '16 at 9:11
• So you run at the speed of 1.3ms/s? Thats pretty fast for nontrivial stuff. My current simulation runs at 15µs/s and takes three hours to complete. Having a turn around time of 20s is quite fine. – PlasmaHH Oct 10 '16 at 9:14
• @winny, All subcircuits already simulated on their own. But the schematic is not so simple so I intended to see how it all working together. I will check if optos are slowing down. Regarding V5: I wouldn't say that it is really flowing. What do you mean saying "floating"? – Roman Matveev Oct 10 '16 at 9:30
• @winny, without optos simulation is one third faster (11 seconds instead of 15). – Roman Matveev Oct 10 '16 at 9:33
• V5: It's "blocked" by two inductors. Sometime giving it 1 or 10 Mohm to ground will help. What about the stack of MOVs (D37)? – winny Oct 10 '16 at 11:05

Imposing a timestep does not make it faster, and if you need speed and accuracy, I'm afraid that's not very possible.

There are some TVSs in series, quite a lot of them, which can be replaced by one TVS with n=X (= the number of series elements). If we're at it, m=Y will set the number of parallel devices. Note that only m is valid for RLCs, n only for diodes. This can simply be added after the instance name. For example, two series and three parallel 4148s will look like 1N4148 n=2 m=3. They will not count towards the final node count because they're expanded internally, but they will count towards the computation, since LTspice still has to compute the presence of 6 diodes.

For the floating V5, if that is one offending element (which could be, since LTspice even specifies in its manual that current sources are recommended over their voltage counterparts and voltage sources should be tied to ground for best performance), the cure is simple: add Rser=1m. This will transform, also internally, the voltage surce into its Norton equivalent, thus improving convergence.

You can also combine series RL with L Rser=x, same for caps, same for parallel and/or series combinations. Same explanation as for the TVS.

As for settings, you're better off making trtol=3..7 instead of the others. There will be a (minor, -ish) speedup, depending on your hardware and schematic, while the precision doesn't have tham much of an impact as gmin, reltol and abstol have.

There is one more thing that puzzles me: in one of the comments, someone suggests using current sources instead of optocouplers, and you say you tried. This makes me think accuracy, or keeping to a quasi-real setup, is not that important to you, which means you could simplify theLC filter after V5 into it's simple LC lowpass (i.e. don't make it a symmetric filter), but the biggest simplification can be done to the whole bridge and its control circuitry: you can simply use some G (or E) sources driving the native switch SW. The SW may need some anti-parallel diodes. Speaking of which, you can also replace the diodes with the idealized version, having .model D D Vfwd=0.7 Vrev=1k Ron=0.1 Roff=10Meg epsilon=100m revepsilon=50m, or Vfwd=0.5 for Shottky. I see two anti-parallel diodes, those could be replaced by only one diode with Vfwd=Vrev. Zeners also with Vrev=X. Of course, all these imply using an idealized, or a behavioural approach to all your schematic and, while it's very plausible and used for quick tests, you should not forget that the downside is the unrealistic results, even when modeled with great care. You could get good results, but they shouldn't be relied on, as even a schematic made with "real" elements is only a SPICE simulation using models that, themselves, are approximation of real-life cases. Of course, ultimately, it falls on you to choose your way.

• This is a great answer! Thanks! Regarding the current sources: actually I tried not exactly what was suggested, I removed the optos with shorts instead of diodes and opens instead of outputs, this was to test if this simplification will do any speed enhancement. I'm not really aimed on the high accuracy, I just need to be sure that the schematic is working (values will be tuned up during real life tests). – Roman Matveev Oct 10 '16 at 17:50

I was lucky to find the solution that helped me for the moment.

So I changed the Spice settings in the Tools -> Control Panel -> SPICE like this:

So now I have a simulation time only 1 second instead of 15.

However I am aware of the reduction of the simulation tolerance. I hope I will have no problem after that. Please comment if someone has any opinion on this.

• Imposing a timestep does not make it faster, but the true question is what do you need: speed or accuracy? If it's both, I have bad news. But I see there a long snake of TVSs which can be replaced by one TVS with n=X (= the number of series elements). They will not count towards the final node count because they're expanded internally. For the floating V5 the cure is simple: add Rser=1m. You can also combine series ~RL with L Rser=x, same for caps, same for parallel or combinations. Same explanation as for TVS. And you're better off making trtol=3..7` instead of the others. – a concerned citizen Oct 10 '16 at 12:25
• @aconcernedcitizen Thank you! Could you post your thoughts as an answer to let me accept it? – Roman Matveev Oct 10 '16 at 12:57
• @aconcernedcitizen how can I do the "n=X" stuff? I did not find anything like this in the SMBJ24CA properties window. – Roman Matveev Oct 10 '16 at 12:59
• 15 seconds is NOT a long simulation time. I've done simulations that take 10 minutes and longer to render. The trick you've found actually plays with the convergence criterion of the simulation ; you will get a faster simulation, but at the cost of accuracy. – lucas92 Jun 4 '18 at 19:23