Electronics-Related.com
Forums

favorite Spice speedups

Started by John Larkin October 24, 2022
tirsdag den 25. oktober 2022 kl. 22.52.55 UTC+2 skrev Martin Brown:
> On 25/10/2022 15:42, John Larkin wrote: > > On Mon, 24 Oct 2022 21:31:23 -0700, boB <b...@K7IQ.com> wrote: > > > >> On Mon, 24 Oct 2022 13:16:20 -0700, John Larkin > >> <jlarkin@highland_atwork_technology.com> wrote: > >> > >>> We have some sims that run absurdly slow. What are your favorite > >>> speedups? > >>> > >>> In LT spice, I have arbitrarily done > >>> > >>> .opt reltol=.002 > >>> > >>> .opt abstol=5n > >>> > >>> .opt trtol=5 > >>> > >>> but that's just guessing. It may work with my parts but mess up an > >>> encrypted model that I have no visibility into. > >>> > >>> Sometimes one solver is unaccountably better than another. > >> > >> > >> Straight from LTwiki ... Was probably from my friend, David Edwards, > >> AKA Analog Spiceman... > >> > >> https://ltwiki.org/index.php?title=Main_Page > >> > >> > >> .options gmin=1e-10 > >> .options abstol=1e-10 > >> .options reltol=0.003 > >> .options cshunt=1e-15 > >> > >> > >> boB > > > > Thanks, we'll try them. > > > > We can run a slow sim, add the hacks, and re-run and see if anything > > changes much. If not, we can then run the sims that matter. > You could try running sims at 4x, 2x and 1x delta_t and use Richardson > extrapolation to try and guess at the true solution. > > > > It's taking basically all day to run 50 ms of our power supply sim, > > and we can't iterate very well at that rate. > You need to figure out where it is spending all its time. Adding ram > might help speed it up as might looking to see which resources are > gridlocked. Paradoxically limiting the maximum number of cores it can > use might also speed it up or at the very least get the same answer in > the same time with less power used. My PC is 4 physical 8 virtual core > and is optimal for chess puzzles or spice with 6 cores running. Beyond > that it saturates memory bandwidth and all 8 cores is slower than 6! > > Chances are one or more of the equations is stiff and the time step is > becoming infinitessimal on one of the rapid transitions. Adding a bit of > spurious dissipation 1M to ground here and there might take the edge off > whatever is making it so stiff. > > We once did some awkward PDE's in a computer solution and on a Tektronix > vector display monitor they looked fine so sent them off to the plotter. > The job came back part done with an apologetic note from the sysop "your > job was cancelled because the red pen began to work loose". > > Careful examination of the plot file showed some of the vector steps > were just Angstroms long!
mechanical CAM tools usually have a smoothing option that merges moves below a specified size because it slows everything to a crawl when the machine start to hit the limit of how many moves it can interpret and plan per second
Joe Gwinn wrote:
> On Tue, 25 Oct 2022 07:56:38 -0700, John Larkin > <jlarkin@highlandSNIPMEtechnology.com> wrote: > >> On Tue, 25 Oct 2022 10:43:18 -0400, bitrex <user@example.net> wrote: >> >>> On 10/24/2022 4:16 PM, John Larkin wrote: >>>> We have some sims that run absurdly slow. What are your favorite >>>> speedups? >>>> >>>> In LT spice, I have arbitrarily done >>>> >>>> .opt reltol=.002 >>>> >>>> .opt abstol=5n >>>> >>>> .opt trtol=5 >>>> >>>> but that's just guessing. It may work with my parts but mess up an >>>> encrypted model that I have no visibility into. >>>> >>>> Sometimes one solver is unaccountably better than another. >>>> >>> >>> Using a RAM drive for waveform storage is one, but I guess I don't >>> regularly run sims complex enough that it causes a Ryzen 5600 to chug >>> badly enough to make me frustrated. Have you upgraded your CPU lately? >> >> The guy running this for me has a pretty good, fairly new PC. But the >> sim takes hours to simulate 10s of milliseconds, so we don't want a >> modest speedup. >> >> TI software, TI models, runs for hours. That's silly. > > My recollection from my power-system colleagues is that this can be > caused by often parasitic sub circuits with very short time constants > (compared to the core circuit), so the approach was to model only the > core circuit at first, then start to decorate it. > > Joe Gwinn >
The Gear integrator is specifically designed for problems like that. ("stiff systems"). Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On Tue, 25 Oct 2022 18:01:17 -0400, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:

>Joe Gwinn wrote: >> On Tue, 25 Oct 2022 07:56:38 -0700, John Larkin >> <jlarkin@highlandSNIPMEtechnology.com> wrote: >> >>> On Tue, 25 Oct 2022 10:43:18 -0400, bitrex <user@example.net> wrote: >>> >>>> On 10/24/2022 4:16 PM, John Larkin wrote: >>>>> We have some sims that run absurdly slow. What are your favorite >>>>> speedups? >>>>> >>>>> In LT spice, I have arbitrarily done >>>>> >>>>> .opt reltol=.002 >>>>> >>>>> .opt abstol=5n >>>>> >>>>> .opt trtol=5 >>>>> >>>>> but that's just guessing. It may work with my parts but mess up an >>>>> encrypted model that I have no visibility into. >>>>> >>>>> Sometimes one solver is unaccountably better than another. >>>>> >>>> >>>> Using a RAM drive for waveform storage is one, but I guess I don't >>>> regularly run sims complex enough that it causes a Ryzen 5600 to chug >>>> badly enough to make me frustrated. Have you upgraded your CPU lately? >>> >>> The guy running this for me has a pretty good, fairly new PC. But the >>> sim takes hours to simulate 10s of milliseconds, so we don't want a >>> modest speedup. >>> >>> TI software, TI models, runs for hours. That's silly. >> >> My recollection from my power-system colleagues is that this can be >> caused by often parasitic sub circuits with very short time constants >> (compared to the core circuit), so the approach was to model only the >> core circuit at first, then start to decorate it. >> >> Joe Gwinn >> >The Gear integrator is specifically designed for problems like that. >("stiff systems").
Yes, but sometimes one must also simplify. I've also been bitten by MATLAB handling an overdetermined system by endless iteration. Had to reformulate the problem to evade that. Joe Gwinn
Joe Gwinn wrote:
> On Tue, 25 Oct 2022 18:01:17 -0400, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >> Joe Gwinn wrote: >>> On Tue, 25 Oct 2022 07:56:38 -0700, John Larkin >>> <jlarkin@highlandSNIPMEtechnology.com> wrote: >>> >>>> On Tue, 25 Oct 2022 10:43:18 -0400, bitrex <user@example.net> wrote: >>>> >>>>> On 10/24/2022 4:16 PM, John Larkin wrote: >>>>>> We have some sims that run absurdly slow. What are your favorite >>>>>> speedups? >>>>>> >>>>>> In LT spice, I have arbitrarily done >>>>>> >>>>>> .opt reltol=.002 >>>>>> >>>>>> .opt abstol=5n >>>>>> >>>>>> .opt trtol=5 >>>>>> >>>>>> but that's just guessing. It may work with my parts but mess up an >>>>>> encrypted model that I have no visibility into. >>>>>> >>>>>> Sometimes one solver is unaccountably better than another. >>>>>> >>>>> >>>>> Using a RAM drive for waveform storage is one, but I guess I don't >>>>> regularly run sims complex enough that it causes a Ryzen 5600 to chug >>>>> badly enough to make me frustrated. Have you upgraded your CPU lately? >>>> >>>> The guy running this for me has a pretty good, fairly new PC. But the >>>> sim takes hours to simulate 10s of milliseconds, so we don't want a >>>> modest speedup. >>>> >>>> TI software, TI models, runs for hours. That's silly. >>> >>> My recollection from my power-system colleagues is that this can be >>> caused by often parasitic sub circuits with very short time constants >>> (compared to the core circuit), so the approach was to model only the >>> core circuit at first, then start to decorate it. >>> >>> Joe Gwinn >>> >> The Gear integrator is specifically designed for problems like that. >> ("stiff systems"). > > Yes, but sometimes one must also simplify. > > I've also been bitten by MATLAB handling an overdetermined system by > endless iteration. Had to reformulate the problem to evade that. > > Joe Gwinn >
A stiff system is one whose largest and smallest eigenvalues are very different, in some not-too-well-defined mathematical notion of "very different". ;) An overdetermined system is another animal--usually a benevolent one IME. With a bit of work, it's often possible to get a least-squares optimum solution plus an internal error estimate. Fifth- and higher-order Runge-Kutta methods for ODEs are an example I recall, and of course closure phase in interferometry. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On Tue, 25 Oct 2022 21:52:46 +0100, Martin Brown
<'''newspam'''@nonad.co.uk> wrote:

>On 25/10/2022 15:42, John Larkin wrote: >> On Mon, 24 Oct 2022 21:31:23 -0700, boB <boB@K7IQ.com> wrote: >> >>> On Mon, 24 Oct 2022 13:16:20 -0700, John Larkin >>> <jlarkin@highland_atwork_technology.com> wrote: >>> >>>> We have some sims that run absurdly slow. What are your favorite >>>> speedups? >>>> >>>> In LT spice, I have arbitrarily done >>>> >>>> .opt reltol=.002 >>>> >>>> .opt abstol=5n >>>> >>>> .opt trtol=5 >>>> >>>> but that's just guessing. It may work with my parts but mess up an >>>> encrypted model that I have no visibility into. >>>> >>>> Sometimes one solver is unaccountably better than another. >>> >>> >>> Straight from LTwiki ... Was probably from my friend, David Edwards, >>> AKA Analog Spiceman... >>> >>> https://ltwiki.org/index.php?title=Main_Page >>> >>> >>> .options gmin=1e-10 >>> .options abstol=1e-10 >>> .options reltol=0.003 >>> .options cshunt=1e-15 >>> >>> >>> boB >> >> Thanks, we'll try them. >> >> We can run a slow sim, add the hacks, and re-run and see if anything >> changes much. If not, we can then run the sims that matter. > >You could try running sims at 4x, 2x and 1x delta_t and use Richardson >extrapolation to try and guess at the true solution. >> >> It's taking basically all day to run 50 ms of our power supply sim, >> and we can't iterate very well at that rate. > >You need to figure out where it is spending all its time. Adding ram >might help speed it up as might looking to see which resources are >gridlocked. Paradoxically limiting the maximum number of cores it can >use might also speed it up or at the very least get the same answer in >the same time with less power used. My PC is 4 physical 8 virtual core >and is optimal for chess puzzles or spice with 6 cores running. Beyond >that it saturates memory bandwidth and all 8 cores is slower than 6! > >Chances are one or more of the equations is stiff and the time step is >becoming infinitessimal on one of the rapid transitions. Adding a bit of >spurious dissipation 1M to ground here and there might take the edge off >whatever is making it so stiff.
We are running TI's Cadence sim and TI's encrypted switcher chip models. We just discovered that their TPS562208 model runs about 50x faster than the TPS54302 model. They are very similar chips. We have both in our power supply design, one 54302 pre-regulating for three of the 562208's.
> >We once did some awkward PDE's in a computer solution and on a Tektronix >vector display monitor they looked fine so sent them off to the plotter. >The job came back part done with an apologetic note from the sysop "your >job was cancelled because the red pen began to work loose". > >Careful examination of the plot file showed some of the vector steps >were just Angstroms long!
Sometimes a Spice sim takes femtosecond steps all afternoon. For some reason the Spice programs allow us to set the max time step but not the min.
On Tue, 25 Oct 2022 10:37:48 -0700, boB <boB@K7IQ.com> wrote:

>On Tue, 25 Oct 2022 07:56:38 -0700, John Larkin ><jlarkin@highlandSNIPMEtechnology.com> wrote: > >>On Tue, 25 Oct 2022 10:43:18 -0400, bitrex <user@example.net> wrote: >> >>>On 10/24/2022 4:16 PM, John Larkin wrote: >>>> We have some sims that run absurdly slow. What are your favorite >>>> speedups? >>>> >>>> In LT spice, I have arbitrarily done >>>> >>>> .opt reltol=.002 >>>> >>>> .opt abstol=5n >>>> >>>> .opt trtol=5 >>>> >>>> but that's just guessing. It may work with my parts but mess up an >>>> encrypted model that I have no visibility into. >>>> >>>> Sometimes one solver is unaccountably better than another. >>>> >>> >>>Using a RAM drive for waveform storage is one, but I guess I don't >>>regularly run sims complex enough that it causes a Ryzen 5600 to chug >>>badly enough to make me frustrated. Have you upgraded your CPU lately? >> >>The guy running this for me has a pretty good, fairly new PC. But the >>sim takes hours to simulate 10s of milliseconds, so we don't want a >>modest speedup. >> >>TI software, TI models, runs for hours. That's silly. > > >I have had LTspice circuits that would not converge or took enormous >amounts of time that were fixed by simple adding high value resistance >between isolated nodes or to grounded nodes. Several MegOhms.
I've got past a hangup by changing a 50 ohm resistor to 51.
> >Those 4 lines I posted seem to help a lot though. Not 100% though. > >I had one circuit that did not converge until I hung just ONE end of a >resistor to a node. The next version of LTspice fixed that issue >though. > >Or, one of the models of one of the parts are the problem. >The matrix becomes ill conditioned I guess. > >It's all dependant on how well the models are created it seems. > > >boB > >
On Tue, 25 Oct 2022 20:39:04 +0100, "Kevin Aylward"
<kevinRemoveandReplaceATkevinaylward.co.uk> wrote:

> > > >http://www.kevinaylward.co.uk/ee/index.html >"John Larkin" wrote in message >news:r2uflh18gf75sp7v3m8476u7b79uqql1li@4ax.com... > >On Tue, 25 Oct 2022 10:43:18 -0400, bitrex <user@example.net> wrote: > >>On 10/24/2022 4:16 PM, John Larkin wrote: >>> We have some sims that run absurdly slow. What are your favorite >>> speedups? >>> >>> In LT spice, I have arbitrarily done >>> >>> .opt reltol=.002 >>> >>> .opt abstol=5n >>> >>> .opt trtol=5 >>> >>>> but that's just guessing. It may work with my parts but mess up an >>>> encrypted model that I have no visibility into. >>> >>> Sometimes one solver is unaccountably better than another. >>> >> >>>Using a RAM drive for waveform storage is one, but I guess I don't >>>regularly run sims complex enough that it causes a Ryzen 5600 to chug >>>badly enough to make me frustrated. Have you upgraded your CPU lately? > >>The guy running this for me has a pretty good, fairly new PC. But the >>sim takes hours to simulate 10s of milliseconds, so we don't want a >>modest speedup. > >>TI software, TI models, runs for hours. That's silly. > >I would have to have a look at it to see about pointing the way to >contracting decent behavioural models for the relevant bits > >I have a current mode SMPS in my SS examples taking 5 secs to do a 200us sim > >I don't have much confidence in mainstream companies making usable models. >It probably needs a rewrite from scratch. You just cant get the staff..... > >I should get TI to subcontract their models to me :-)
Yup. And ADI could use some help getting all their chips modeled in LT Spice.
> > >Kevin Aylward > >http://www.anasoft.co.uk/ SuperSpice
Lasse Langwadt Christensen wrote:
> [Snip!]
> > mechanical CAM tools usually have a smoothing option that merges moves > below a specified size because it slows everything to a crawl when the machine > start to hit the limit of how many moves it can interpret and plan per second >
I did that once for an embroidery machine. It turned out that lots of those tiny steps where at the end of patterns, there to prevent the last stitches from becoming undone. Jeroen Belleman
On 25/10/2022 22:06, Lasse Langwadt Christensen wrote:
> tirsdag den 25. oktober 2022 kl. 22.52.55 UTC+2 skrev Martin Brown:
>> We once did some awkward PDE's in a computer solution and on a Tektronix >> vector display monitor they looked fine so sent them off to the plotter. >> The job came back part done with an apologetic note from the sysop "your >> job was cancelled because the red pen began to work loose". >> >> Careful examination of the plot file showed some of the vector steps >> were just Angstroms long! > > mechanical CAM tools usually have a smoothing option that merges moves > below a specified size because it slows everything to a crawl when the machine > start to hit the limit of how many moves it can interpret and plan per second
Calcomp plotters were not that smart back in those days. It drew every last line segment and shook the pen assembly to bit in the process. -- Regards, Martin Brown
On 26/10/2022 04:41, John Larkin wrote:
> On Tue, 25 Oct 2022 21:52:46 +0100, Martin Brown > <'''newspam'''@nonad.co.uk> wrote: >
>> Chances are one or more of the equations is stiff and the time step is >> becoming infinitessimal on one of the rapid transitions. Adding a bit of >> spurious dissipation 1M to ground here and there might take the edge off >> whatever is making it so stiff. > > We are running TI's Cadence sim and TI's encrypted switcher chip > models. > > We just discovered that their TPS562208 model runs about 50x faster > than the TPS54302 model. They are very similar chips. We have both in > our power supply design, one 54302 pre-regulating for three of the > 562208's.
It might be worth building one to see if it really is inclined to squeg in real circuits. The sim could be telling you something important.
>> We once did some awkward PDE's in a computer solution and on a Tektronix >> vector display monitor they looked fine so sent them off to the plotter. >> The job came back part done with an apologetic note from the sysop "your >> job was cancelled because the red pen began to work loose". >> >> Careful examination of the plot file showed some of the vector steps >> were just Angstroms long! > > Sometimes a Spice sim takes femtosecond steps all afternoon. For some > reason the Spice programs allow us to set the max time step but not > the min.
Usually if a simulation goes to insanely short steps it is because it cannot achieve the specified accuracy any other way (or is buggy). That sort of behaviour is characteristic of stiff equations where it is fighting hard to prevent the solution diverging in some bad way. Parasitic things with ridiculously high Q can ring if provoked which is why adding the odd spurious dissipative resistor to certain key nodes sometimes helps instil good behaviour. Jeroen has made the same point. -- Regards, Martin Brown