Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #450944 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2017-03-09 03:29 -0500 |
| Last post | 2017-03-09 18:23 -0500 |
| Articles | 20 on this page of 65 — 21 participants |
Back to article view | Back to sci.electronics.design
LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 03:29 -0500
Re: LTspice Loafing? Johann Klammer <klammerj@NOSPAM.a1.net> - 2017-03-09 11:37 +0100
Re: LTspice Loafing? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-03-09 09:53 -0500
Re: LTspice Loafing? makolber@yahoo.com - 2017-03-09 07:03 -0800
Re: LTspice Loafing? Don Kuenz <g@crcomp.net> - 2017-03-11 01:01 +0000
Re: LTspice Loafing? tabbypurr@gmail.com - 2017-04-17 08:59 -0700
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-09 09:34 -0800
Re: LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 18:11 -0500
Re: LTspice Loafing? John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-09 11:33 -0800
Re: LTspice Loafing? John S <Sophi.2@invalid.org> - 2017-03-09 14:53 -0600
Re: LTspice Loafing? Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-03-09 13:42 -0800
Re: LTspice Loafing? Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-03-09 16:49 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-10 10:25 +0000
Re: LTspice Loafing? Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-03-10 04:51 +0100
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-10 08:20 -0800
Re: LTspice Loafing? Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-03-10 19:06 +0100
Re: LTspice Loafing? John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-10 10:42 -0800
Re: LTspice Loafing? John S <Sophi.2@invalid.org> - 2017-03-10 20:29 -0600
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-11 08:55 +0000
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-11 08:46 -0800
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-11 08:45 -0800
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-11 17:11 +0000
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-11 09:39 -0800
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-11 18:16 +0000
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-11 11:04 -0800
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-10 22:56 +0000
Re: LTspice Loafing? Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2017-03-13 06:54 +0100
Re: LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 17:39 -0500
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-09 18:01 -0500
Re: LTspice Loafing? John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-09 15:49 -0800
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-09 19:07 -0500
Re: LTspice Loafing? John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-03-09 16:13 -0800
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-09 20:25 -0500
Re: LTspice Loafing? John Larkin <jjlarkin@highlandtechnology.com> - 2017-03-09 19:11 -0800
Re: LTspice Loafing? Bill Martin <wwm@wwmartin.net> - 2017-03-10 10:24 -0800
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-12 23:32 -0400
Re: LTspice Loafing? mixed nuts <melopsitticus@undulatus.budgie> - 2017-03-10 00:03 -0500
Re: LTspice Loafing? mhx@iae.nl - 2017-04-17 01:02 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-17 16:14 +0100
Re: LTspice Loafing? "Kevin Aylward" <kevinRemoveandReplaceATkevinaylward.co.uk> - 2017-04-17 17:38 +0100
Re: LTspice Loafing? Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-04-17 09:54 -0700
Re: LTspice Loafing? mhx@iae.nl - 2017-04-17 11:55 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-17 21:20 +0100
Re: LTspice Loafing? mhx@iae.nl - 2017-04-17 14:22 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-18 19:16 +0100
Re: LTspice Loafing? mhx@iae.nl - 2017-04-17 12:09 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-17 21:19 +0100
Re: LTspice Loafing? mhx@iae.nl - 2017-04-17 14:14 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-18 19:14 +0100
Re: LTspice Loafing? mhx@iae.nl - 2017-04-18 14:04 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-19 08:45 +0100
Re: LTspice Loafing? "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-04-19 00:35 -0500
Re: LTspice Loafing? mhx@iae.nl - 2017-04-19 05:28 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-19 14:00 +0100
Re: LTspice Loafing? mhx@iae.nl - 2017-04-19 10:35 -0700
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-04-19 20:29 +0100
Re: LTspice Loafing? John Devereux <john@devereux.me.uk> - 2017-03-10 07:19 +0000
Re: LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 13:23 -0500
Re: LTspice Loafing? bill.sloman@ieee.org - 2017-03-09 03:15 -0800
Re: LTspice Loafing? "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> - 2017-03-09 20:12 +0000
Re: LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 17:47 -0500
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-09 18:09 -0500
Re: LTspice Loafing? Johann Klammer <klammerj@NOSPAM.a1.net> - 2017-03-10 01:00 +0100
Re: LTspice Loafing? rickman <gnuarm@gmail.com> - 2017-03-09 19:52 -0500
Re: LTspice Loafing? bitrex <bitrex@de.lete.earthlink.net> - 2017-03-09 18:23 -0500
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> |
|---|---|
| Date | 2017-04-17 09:54 -0700 |
| Message-ID | <aes9fc1uk42pulaksnjmgicakr4ua9s8hd@4ax.com> |
| In reply to | #456703 |
On Mon, 17 Apr 2017 17:38:01 +0100, "Kevin Aylward"
<kevinRemoveandReplaceATkevinaylward.co.uk> wrote:
[snip]
>
>As I keep mentioning, those that use Spice, should take the trouble to at
>least learn the most trivial, elementary basics of it.
>
>You all need to understand that the max time step, if used, must be set with
>some modicum of rationality. Dah...
>
>Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 or
>so, depending on how jaggered you want the waveform.
>
>
>
>-- Kevin Aylward
>http://www.anasoft.co.uk - SuperSpice
>http://www.kevinaylward.co.uk/ee/index.html
>
Yep. Virtually ALL of the questions about LTspice are from those too
lazy to RTFM.
(On the other side of the tolerances are those who set such a loose
timestep that their circuit converges... and they swear by it, even
when I demonstrate in PSpice that it sings... I think the tune is "All
Hail Larkin" >:-}
...Jim Thompson
--
| James E.Thompson | mens |
| Analog Innovations | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| STV, Queen Creek, AZ 85142 Skype: skypeanalog | |
| Voice:(480)460-2350 Fax: Available upon request | Brass Rat |
| E-mail Icon at http://www.analog-innovations.com | 1962 |
Thinking outside the box... producing elegant solutions.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-17 11:55 -0700 |
| Message-ID | <75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com> |
| In reply to | #456703 |
On Monday, April 17, 2017 at 6:38:13 PM UTC+2, Kevin Aylward wrote: > >"Kevin Aylward" wrote in message > >news:pbmdnWA37PxVRmnFnZ2dnUU7-afNnZ2d@giganews.com... > > >wrote in message > >news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com... > > On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote: > > On 3/9/2017 2:33 PM, John Larkin wrote: > > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > > >>> On 03/09/2017 09:29 AM, rickman wrote: > > >>>> I was running some simulations on LTspice and it is not even using > > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > > >>>> is pretty much at idle. What could be limiting the speed? > > >>>> > > >>>> One of the main reasons I bought a laptop with an i7 processor was > > >>>> to speed simulations. Is this wasted on LTspice or am I doing > > >>>> something wrong? > > >>>> > > >>> I think it saves the waveforms to a file as it goes along > > >>> simulating. Where you the one who complained about your hdd being > > >>> slow in an earlier thread? maybe try running the sim from an ext usb > > >>> stick. if that helps it's definitely the hdd. > > >>> > > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > > >> with real flash drives. > > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >That is really good! > > >* LTspice Alternate Solver 33.129 seconds > >* LTspice normal solver 22.392 seconds > >* LTspice normal solver with .save 13.306 seconds > >* NGSPICE 9.660 seconds > >* NGSPICE with .save 9.002 seconds > > OK, I have now ran the example posted by John at the top of this thread. Is > this the one that has been run here? Yes. > If so, the speed problem is trivial. It is not a problem? I only show that LTspice has been unchallenged for a long time and others are catching up. > The tran statement is > > .tran 0 20m 10n uic > > This runs in about 15 secs on my laptop in LTSpice. > > However..... > > If you right click on the tran line in LTSpice and remove the max time step > entry, to let LT does what it does, it runs in < 1/2 sec, probably even 100 > ms. Its just zooms through, so difficult to tell. That is cheating in the context of a benchmark, but LTspice runs it in 252 ms here (normal solver, with .save line). In NGSPICE that becomes 262 ms, with the default (double-precision) solver. > As I keep mentioning, those that use Spice, should take the trouble to at > least learn the most trivial, elementary basics of it. > > You all need to understand that the max time step, if used, must be set with > some modicum of rationality. Dah... > > Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 or > so, depending on how jaggered you want the waveform. I am sure most people know that. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-17 21:20 +0100 |
| Message-ID | <MbidndbbOOY3vmjFnZ2dnUU7-anNnZ2d@giganews.com> |
| In reply to | #456718 |
wrote in message news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com... > > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >That is really good! > > >* LTspice Alternate Solver 33.129 seconds > >* LTspice normal solver 22.392 seconds > >* LTspice normal solver with .save 13.306 seconds > >* NGSPICE 9.660 seconds > >* NGSPICE with .save 9.002 seconds > > OK, I have now ran the example posted by John at the top of this thread. > Is > this the one that has been run here? >Yes. >> If so, the speed problem is trivial. >It is not a problem? It is a typically a problem when it takes 50 times longer, and uses 100 times more file size than it needs to. >I only show that LTspice has been >unchallenged for a long time and others are catching up. LT Spice has only been unchallenged on Windows only. Those of us that use $100k per seat, per year pro IC design tools use Spices on Linux that multicores on both the matrix solving and device evaluation, for many years. > The tran statement is > > .tran 0 20m 10n uic > > This runs in about 15 secs on my laptop in LTSpice. > > However..... > > If you right click on the tran line in LTSpice and remove the max time > step > entry, to let LT does what it does, it runs in < 1/2 sec, probably even > 100 > ms. Its just zooms through, so difficult to tell. >That is cheating in the context of a benchmark, but LTspice >runs it in 252 ms here (normal solver, with .save line). What is the cheat? LTSpice uses its own algorithms to get the best speed and accuracy. Max step time should usually be left as default for most simulations. A bench mark means letting each system run as it wants to run. >In NGSPICE that becomes 262 ms, with the default (double-precision) >solver. Its an interesting result, but on its own means nothing. See other post. > As I keep mentioning, those that use Spice, should take the trouble to at > least learn the most trivial, elementary basics of it. > > You all need to understand that the max time step, if used, must be set > with > some modicum of rationality. Dah... > > Like, 10ns in 20us is 2,000 points per cycle. Typically, you only need 20 > or > so, depending on how jaggered you want the waveform. >I am sure most people know that. Apparently not. Its probably the most typical issue I get from those that use SuperSpice. Where do you get your information from? -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-17 14:22 -0700 |
| Message-ID | <3e3875a4-5d65-419c-a571-0fa326aa5d59@googlegroups.com> |
| In reply to | #456727 |
On Monday, April 17, 2017 at 10:21:06 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com... [..] > >That is cheating in the context of a benchmark, but LTspice > >runs it in 252 ms here (normal solver, with .save line). > > What is the cheat? > > LTSpice uses its own algorithms to get the best speed and accuracy. Max step > time should usually be left as default for most simulations. > > A bench mark means letting each system run as it wants to run. I meant that it would be cheating if I set the options for NGSPICE differently for those of LTspice, especially for those options that have a large influence on run speed. I interpret your last statement that one should optimize the settings for each simulator such that they run as fast as they can. That makes some sense, and the advantage for the reader is that they may learn something they didn't know yet. > >I am sure most people know that. > > Apparently not. Its probably the most typical issue I get from those that > use SuperSpice. > > Where do you get your information from? My colleagues. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-18 19:16 +0100 |
| Message-ID | <tJWdnbSUjOt2ymvFnZ2dnUU7-VvNnZ2d@giganews.com> |
| In reply to | #456733 |
wrote in message news:3e3875a4-5d65-419c-a571-0fa326aa5d59@googlegroups.com... On Monday, April 17, 2017 at 10:21:06 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:75bb9bd2-f0ef-4dd2-9759-b07dc896c4e0@googlegroups.com... [..] > >That is cheating in the context of a benchmark, but LTspice > >runs it in 252 ms here (normal solver, with .save line). > > What is the cheat? > >> LTSpice uses its own algorithms to get the best speed and accuracy. Max >> step >> time should usually be left as default for most simulations. > >> A bench mark means letting each system run as it wants to run. >I meant that it would be cheating if I set the options for NGSPICE >differently for those of LTspice, especially for those options that >have a large influence on run speed. I disagree. Its because the options can have a large effect on speed, that its misleading to do make then the same. LTSpice does a lot of stuff automatically, such that if you set it the same as Spice3, you can cripple it. Its not a fair test. LTSpice is very good at getting fast results without any user input. To know whether one spice is faster/accurate than another, you need to set each one to the setting that make each one as fast/accurate as possible. > >I am sure most people know that. > >> Apparently not. Its probably the most typical issue I get from those that >> use SuperSpice. > >> Where do you get your information from? >My colleagues. How many colleagues do you have that respond to spice customer support? :-) Well, sonny... I have been at this some while, although not as long as old man Jim T. I do have a pretty good idea of the spice knowledge of fellow analog IC designers, and the capabilities of spice customers as well. I also have experience of receiving initial support from the Cadence Application Engineers when trying to resolve technical problems of my own, that provides ample evidence to the level of anticipated answers to questions... I would say, that your colleagues are a rather special set. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html www.kevinaylward.co.uk
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-17 12:09 -0700 |
| Message-ID | <605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com> |
| In reply to | #456692 |
On Monday, April 17, 2017 at 5:14:29 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:779882df-64e0-4433-8b58-fcdce25392ac@googlegroups.com... > > On Friday, March 10, 2017 at 6:03:40 AM UTC+1, mixed nuts wrote: > > On 3/9/2017 2:33 PM, John Larkin wrote: > > > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > > > <pcdhSpamMeSenseless@electrooptical.net> wrote: > > > > > >> On 03/09/2017 05:37 AM, Johann Klammer wrote: > > >>> On 03/09/2017 09:29 AM, rickman wrote: > > >>>> I was running some simulations on LTspice and it is not even using > > >>>> 5% of my CPU. Nothing else is topping it and the entire computer > > >>>> is pretty much at idle. What could be limiting the speed? > > >>>> > > >>>> One of the main reasons I bought a laptop with an i7 processor was > > >>>> to speed simulations. Is this wasted on LTspice or am I doing > > >>>> something wrong? > > >>>> > > >>> I think it saves the waveforms to a file as it goes along > > >>> simulating. Where you the one who complained about your hdd being > > >>> slow in an earlier thread? maybe try running the sim from an ext usb > > >>> stick. if that helps it's definitely the hdd. > > >>> > > >> I'd start with a ramdisk and see then. USB sticks are glacial compared > > >> with real flash drives. > > >> > > >> Cheers > > >> > >> >> Phil Hobbs > > > > >> > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. > > > >> Less than 15 sec on an HP flaptop (ZBook G3 i7...) with 12% of one cpu. > >> Slower and busier with a plot updating. > > > > -- > >> Grizzly H. > > >That is really good! > > >* LTspice Alternate Solver 33.129 seconds > >* LTspice normal solver 22.392 seconds > >* LTspice normal solver with .save 13.306 seconds > >* NGSPICE 9.660 seconds > >* NGSPICE with .save 9.002 seconds > > This don't make any sense to me. LTSpice should be running several times > faster than NGSpice. Because? This is a properly compiled and optimized (for AVX and open-mp) console-based NGSPICE from the latest Git branch. It has XSPICE integrated and has my custom mods for power-electronics (but these shouldn't cut in here). It has a Berkeley parallel BJT model, but that is only slowing it down here as there is only a single transistor in this circuit. > Are you running default settings in LTSpice, or say, setting a minimum step > time? I use the PH settings, but added "nomarch". Plotwinsize is NOT used, it has no effect (here). > It is possible to override stuff in LTSpice, such that it aint running > anything like as fast as it should. Its also possible to speed it up a bit > by changing some settings for some circuits. I think LTspice runs as fast as it can here (see also the other timings presented in this thread). NGSPICE is running faster that you seem to expect. > I would be interested in what settings you have for reltol, trtol and min > step size Default: reltol=1m, trtol=1. Min step size can't be set, but max step size is 10ns (as prescribed). > The spice default Spice3 value of trtol is 7. I think LTSpice might use 1, I > use 1 in SS. The 1 setting can slow it down by a factor of 3, but for some > switching circuits, a value of 7 generates way too large errors. A too high value of TRTOL can also slow down some circuits. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-17 21:19 +0100 |
| Message-ID | <J8mdnd0OuafMvmjFnZ2dnUU7-K3NnZ2d@giganews.com> |
| In reply to | #456721 |
wrote in message news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... > > -- > >> Grizzly H. > > >That is really good! > > >* LTspice Alternate Solver 33.129 seconds > >* LTspice normal solver 22.392 seconds > >* LTspice normal solver with .save 13.306 seconds > >* NGSPICE 9.660 seconds > >* NGSPICE with .save 9.002 seconds > > This don't make any sense to me. LTSpice should be running several times > faster than NGSpice. >Because? Because LTSpice does compile on run to resolve memory addresses for every individual circuit. For the lase 15 years or so it has been 3 times fast as anything else on Windows. I don't keep track of it much, other then noting that it added multicore support. >This is a properly compiled and optimized (for AVX >and open-mp) console-based NGSPICE from the latest >Git branch. It has XSPICE integrated and has my custom >mods for power-electronics (but these shouldn't cut >in here). It has a Berkeley parallel BJT model, >but that is only slowing it down here as there is only >a single transistor in this circuit. None on this addresses the special nature of the LTSpice assembler It's explained here: www.linear.com/docs/46028 Snippet: " Ideally, the addresses of the data required for a calculation would be known ahead of calculation time so that data can be efficiently fetched and the FPU doesn’t have to wait for it. LTspice eliminates the overhead in getting the data to the FPU with self-authoring assembly language source written at run time, after matrix memory has been allocated, and the addresses returned from malloc() are known. This late authored code can resolve concrete matrix element addresses in line with LTspice eliminates the overhead in getting the data to the FPU with self-authoring assembly language source written at run time, after matrix memory has been allocated, and the addresses returned from malloc() are known. This late-authored code can resolve concrete matrix element addresses in line with the code so the data can be efficiently loaded, allowing the FPU to operate with the pipeline full." >> Are you running default settings in LTSpice, or say, setting a minimum >> step >> time? >I use the PH settings, but added "nomarch". >Plotwinsize is NOT used, it has no effect (here). >> It is possible to override stuff in LTSpice, such that it aint running >> anything like as fast as it should. Its also possible to speed it up a >> bit >> by changing some settings for some circuits. >I think LTspice runs as fast as it can here (see also the >other timings presented in this thread). NGSPICE is running >faster that you seem to expect. This one transistor circuit just don't cut it for me. I would need to see a much more serious design to make any conclusions as to the speed/convergence comparison of LTSpice and NGSpice. Does the latest version of NGspice do the aforementioned just in time assemble? Has it done anything to its convergence algorithms? If not, I would be pretty surprized if NGSpice comes anywhere near LTSpice in real designs. LTSpice is particular good in convergence. The problem with LTSpice, is its incredibly shit GUI. > I would be interested in what settings you have for reltol, trtol and min > step size >Default: reltol=1m, trtol=1. Min step size can't be set, but max >step size is 10ns (as prescribed). Min was basically, a typo. Meant to be max. > The spice default Spice3 value of trtol is 7. I think LTSpice might use 1, > I > use 1 in SS. The 1 setting can slow it down by a factor of 3, but for some > switching circuits, a value of 7 generates way too large errors. >A too high value of TRTOL can also slow down some circuits. Maybe in some vague theory, never, ever, seen that happen though. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-17 14:14 -0700 |
| Message-ID | <406c7b9d-ce9d-4458-b5f3-8ca3cd5407f6@googlegroups.com> |
| In reply to | #456726 |
On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... > > > > > -- > > >> Grizzly H. > > > > >That is really good! > > > > >* LTspice Alternate Solver 33.129 seconds > > >* LTspice normal solver 22.392 seconds > > >* LTspice normal solver with .save 13.306 seconds > > >* NGSPICE 9.660 seconds > > >* NGSPICE with .save 9.002 seconds > > > > This don't make any sense to me. LTSpice should be running several times > > faster than NGSpice. > > >Because? > > Because LTSpice does compile on run to resolve memory addresses for every > individual circuit. > > For the lase 15 years or so it has been 3 times fast as anything else on > Windows. > > I don't keep track of it much, other then noting that it added multicore > support. > > >This is a properly compiled and optimized (for AVX > >and open-mp) console-based NGSPICE from the latest > >Git branch. It has XSPICE integrated and has my custom > >mods for power-electronics (but these shouldn't cut > >in here). It has a Berkeley parallel BJT model, > >but that is only slowing it down here as there is only > >a single transistor in this circuit. > > None on this addresses the special nature of the LTSpice assembler > > It's explained here: > > www.linear.com/docs/46028 > > Snippet: > > " Ideally, the addresses of the > data required for a calculation would > be known ahead of calculation time so > that data can be efficiently fetched and > the FPU doesn’t have to wait for it. > LTspice eliminates the overhead in getting > the data to the FPU with self-authoring > assembly language source written at > run time, after matrix memory has been > allocated, and the addresses returned > from malloc() are known. This late authored > code can resolve concrete > matrix element addresses in line with > LTspice eliminates the overhead in getting the data to the FPU with > self-authoring > assembly language source written at run time, after matrix memory has been > allocated, and the addresses returned from malloc() are known. This > late-authored > code can resolve concrete matrix element addresses in line with the code so > the > data can be efficiently loaded, allowing the FPU to operate with the > pipeline full." That makes perfect sense, but the proof of the pudding is in the eating. > >> Are you running default settings in LTSpice, or say, setting a minimum > >> step > >> time? > > >I use the PH settings, but added "nomarch". > >Plotwinsize is NOT used, it has no effect (here). > > >> It is possible to override stuff in LTSpice, such that it aint running > >> anything like as fast as it should. Its also possible to speed it up a > >> bit > >> by changing some settings for some circuits. > > >I think LTspice runs as fast as it can here (see also the > >other timings presented in this thread). NGSPICE is running > >faster that you seem to expect. > > This one transistor circuit just don't cut it for me. I would need to see a > much more serious design to make any conclusions as to the speed/convergence > comparison of LTSpice and NGSpice. LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS benchmark sets. Do you have a netlist that would convince you? > Does the latest version of NGspice do the aforementioned just in time > assemble? Has it done anything to its convergence algorithms? No it does not, unfortunately. However, my VTune sessions show that, in NGSPICE at least, most time is spent in the system matrix load phase, not in solving this matrix. > If not, I would be pretty surprized if NGSpice comes anywhere near LTSpice > in real designs. LTSpice is particular good in convergence. That is true, there was a lot of catching up to do there, and more would be welcome. > The problem with LTSpice, is its incredibly shit GUI. I have seen worse, even today :-) > > I would be interested in what settings you have for reltol, trtol and min > > step size > > >Default: reltol=1m, trtol=1. Min step size can't be set, but max > >step size is 10ns (as prescribed). > > Min was basically, a typo. Meant to be max. > > > The spice default Spice3 value of trtol is 7. I think LTSpice might use 1, > > I > > use 1 in SS. The 1 setting can slow it down by a factor of 3, but for some > > switching circuits, a value of 7 generates way too large errors. > > >A too high value of TRTOL can also slow down some circuits. > > Maybe in some vague theory, never, ever, seen that happen though. My remark didn't make sense, as I agree that TRTOL should not be too large. A value of 1 is fine. I offer you my experimental data. It's good that you question it, I may learn something in the process. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-18 19:14 +0100 |
| Message-ID | <OYSdnarXHOU9ymvFnZ2dnUU7-UPNnZ2d@giganews.com> |
| In reply to | #456732 |
wrote in message news:406c7b9d-ce9d-4458-b5f3-8ca3cd5407f6@googlegroups.com... On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... > > > > > -- > > >> Grizzly H. > > > > >That is really good! > > > > >* LTspice Alternate Solver 33.129 seconds > > >* LTspice normal solver 22.392 seconds > > >* LTspice normal solver with .save 13.306 seconds > > >* NGSPICE 9.660 seconds > > >* NGSPICE with .save 9.002 seconds > > > > This don't make any sense to me. LTSpice should be running several times > > faster than NGSpice. > > >Because? > > Because LTSpice does compile on run to resolve memory addresses for every > individual circuit. > > For the lase 15 years or so it has been 3 times fast as anything else on > Windows. > > I don't keep track of it much, other then noting that it added multicore > support. > > >This is a properly compiled and optimized (for AVX > >and open-mp) console-based NGSPICE from the latest > >Git branch. It has XSPICE integrated and has my custom > >mods for power-electronics (but these shouldn't cut > >in here). It has a Berkeley parallel BJT model, > >but that is only slowing it down here as there is only > >a single transistor in this circuit. > > None on this addresses the special nature of the LTSpice assembler > > It's explained here: > > www.linear.com/docs/46028 > > Snippet: > > " Ideally, the addresses of the >> data required for a calculation would >> be known ahead of calculation time so >> that data can be efficiently fetched and >> the FPU doesn’t have to wait for it. >> LTspice eliminates the overhead in getting >> the data to the FPU with self-authoring >> assembly language source written at >> run time, after matrix memory has been >> allocated, and the addresses returned >> from malloc() are known. This late authored >> code can resolve concrete >> matrix element addresses in line with >> LTspice eliminates the overhead in getting the data to the FPU with >> self-authoring >> assembly language source written at run time, after matrix memory has >> been >> allocated, and the addresses returned from malloc() are known. This >> late-authored >> code can resolve concrete matrix element addresses in line with the code >> so >> the >> data can be efficiently loaded, allowing the FPU to operate with the >> pipeline full." >That makes perfect sense, but the proof of the pudding is in the eating. LTSpice, has been proven to be the fasted, "non pro tool", on Windows for many years. There are of course, products like FastSpice from Berkeley Design Automation, now owned by Mentor. It can reliably do millions of transistors. Its Linux/Unix though. > >> Are you running default settings in LTSpice, or say, setting a minimum > >> step > >> time? > > >I use the PH settings, but added "nomarch". > >Plotwinsize is NOT used, it has no effect (here). > > >> It is possible to override stuff in LTSpice, such that it aint running > >> anything like as fast as it should. Its also possible to speed it up a > >> bit > >> by changing some settings for some circuits. > > >I think LTspice runs as fast as it can here (see also the > >other timings presented in this thread). NGSPICE is running > >faster that you seem to expect. > >> This one transistor circuit just don't cut it for me. I would need to see >> a >> much more serious design to make any conclusions as to the >> speed/convergence >> comparison of LTSpice and NGSpice. >LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS >benchmark sets. Do you have a netlist that would convince you? I have a SMPS example in SuperSpice that I compared with LTSPice maybe, 15 years ago. LTSpice was something like 3 times faster. In 2000, it was a real big deal to get practical SMPS sims going. Now, my laptop does 90 GFlops, with 16GB of ram, and does it in about 7 secs in SuperSpice, so speed for board level stuff is not so important now. For analog ASIC, its never fast enough. I have a working ngspice-26 so I might give it go. I actually passed on my xspice code model code for the John Chan et la. Hysteresis core model to Paolo Nenzi many moons ago. > Does the latest version of NGspice do the aforementioned just in time > assemble? Has it done anything to its convergence algorithms? >No it does not, unfortunately. However, my VTune sessions show >that, in NGSPICE at least, most time is spent in the system >matrix load phase, not in solving this matrix. This depends on the size of the circuit. Are you a pro? I routinely run analog ASIC simulations in my day job of maybe, 20,000 to 100,000 nets. Large circuits get really bogged down in solving the matrix. > > > The spice default Spice3 value of trtol is 7. I think LTSpice might use > > 1, > > I > > use 1 in SS. The 1 setting can slow it down by a factor of 3, but for > > some > > switching circuits, a value of 7 generates way too large errors. > > >A too high value of TRTOL can also slow down some circuits. > > Maybe in some vague theory, never, ever, seen that happen though. >My remark didn't make sense, as I agree that TRTOL should not >be too large. A value of 1 is fine. I consider the setting of TRTOL to be somewhat controversial. Ken Kundert (Spectre author) wrote a paper with the view that TRTOL should be set higher, nearer to the spice3 default 7 value and tighten up the accuracy settings, say to 100u or 10u. I did do fair bit of experimenting on this for SMPS and Sigma-Delta Converters where it definitely all goes to pot with a value of 7. I can't say I really agree with Ken in general though. I manually set the best TRTOL and RETOL in my SuperSpice examples to get an optimum speed/accuracy trade-off. Typically I might use values of 2-4, and accuracy 10u-100u -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-18 14:04 -0700 |
| Message-ID | <179a7510-159e-4454-bf05-89d86da7cdb7@googlegroups.com> |
| In reply to | #456846 |
On Tuesday, April 18, 2017 at 8:15:10 PM UTC+2, Kevin Aylward wrote: > wrote in message > news:406c7b9d-ce9d-4458-b5f3-8ca3cd5407f6@googlegroups.com... > > On Monday, April 17, 2017 at 10:19:38 PM UTC+2, Kevin Aylward wrote: > > wrote in message > > news:605d4f15-d117-4df6-b4d9-274b745b2021@googlegroups.com... [..] > > www.linear.com/docs/46028 > > > > Snippet: > > > > " Ideally, the addresses of the > >> data required for a calculation would > >> data can be efficiently loaded, allowing the FPU to operate with the [..] > >> pipeline full." > > >That makes perfect sense, but the proof of the pudding is in the eating. > > LTSpice, has been proven to be the fasted, "non pro tool", on Windows for > many years. That statement needs no proof. I meant proof for the snippet's claim that pointer chasing is the main cause of inefficiency in SPICE. > There are of course, products like FastSpice from Berkeley Design > Automation, now owned by Mentor. It can reliably do millions of transistors. > Its Linux/Unix though. I don't doubt that. [..] > >LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS > >benchmark sets. Do you have a netlist that would convince you? > > I have a SMPS example in SuperSpice that I compared with LTSPice maybe, 15 > years ago. LTSpice was something like 3 times faster. Is that CurrentModeController.sss? It indeed runs in 6.964s. However, when I try it, it gives suspicious results (false gate triggers) in SuperSpice (as is), LTspice and NGSPICE. In NGSPICE it runs very slowly, around 2.527 seconds, because I didn't want to tune the options yet. > In 2000, it was a real big deal to get practical SMPS sims going. Now, my > laptop does 90 GFlops, with 16GB of ram, and does it in about 7 secs in > SuperSpice, so speed for board level stuff is not so important now. For > analog ASIC, its never fast enough. I don't think 7seconds is at all satisfactory when having feedback control with 100ms time constants, or when doing a PFC with 20 Hz bandwidth. > I have a working ngspice-26 so I might give it go. I actually passed on my > xspice code model code for the John Chan et la. Hysteresis core model to > Paolo Nenzi many moons ago. Your name is still listed in the manual, but I didn't know you worked on the Chan Core model. > >No it does not, unfortunately. However, my VTune sessions show > >that, in NGSPICE at least, most time is spent in the system > >matrix load phase, not in solving this matrix. > This depends on the size of the circuit. Are you a pro? These were small matrices, and then load time dominates. I have the numbers when you are interested. For 1000's of transistors (ISCAS and MCNC) solving becomes dominant, but then NGSPICE uses KLU (which LTspice doesn't have). > I routinely run analog ASIC simulations in my day job of maybe, 20,000 to > 100,000 nets. Large circuits get really bogged down in solving the matrix. Definitely. [..] > >My remark didn't make sense, as I agree that TRTOL should not > >be too large. A value of 1 is fine. > > I consider the setting of TRTOL to be somewhat controversial. > > Ken Kundert (Spectre author) wrote a paper with the view that TRTOL should > be set higher, nearer to the spice3 default 7 value and tighten up the > accuracy settings, say to 100u or 10u. Which paper is that? As far as the source code goes, TRTOL always multiplies with the normal TOL value (sum of volttol and chargetol). It does trickier stuff when the compile option NEWTRUNC is enabled, but that is not the case in NGSPICE. Actually. my tests said that NEWTRUNC is not doing any good. > I did do fair bit of experimenting on this for SMPS and Sigma-Delta > Converters where it definitely all goes to pot with a value of 7. I can't > say I really agree with Ken in general though. I think I again have to agree with you. > I manually set the best TRTOL and RETOL in my SuperSpice examples to get an > optimum speed/accuracy trade-off. Typically I might use values of 2-4, and > accuracy 10u-100u I think TRTOL=1 and RELTOL = 1m is fine, but I'll remember this when using SuperSpice. -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-19 08:45 +0100 |
| Message-ID | <Q4udnU_fruwRiGrFnZ2dnUU7-bvNnZ2d@giganews.com> |
| In reply to | #456854 |
>wrote in message >news:179a7510-159e-4454-bf05-89d86da7cdb7@googlegroups.com... > >LTspice bogs down for larger circuits, e.g. the mcnc or ISCAS > >benchmark sets. Do you have a netlist that would convince you? > > I have a SMPS example in SuperSpice that I compared with LTSPice maybe, 15 > years ago. LTSpice was something like 3 times faster. >Is that CurrentModeController.sss? It indeed runs in 6.964s. However, >when I try it, it gives suspicious results (false gate triggers) in >SuperSpice (as is), LTspice and NGSPICE. In NGSPICE it runs very >slowly, around 2.527 seconds, because I didn't want to tune the >options yet. Yes. However, I could have another go and do another model from scratch, could probably speed it up a fair chunk. Overtime, I have his habit of breaking stuff that worked, so its possible its now now strange things. Recently, I noticed that I have inadvertently removed the sweep of resistance in dc sweep setup list box. Now fixed. Note, a lot of the SS examples, are where I just wanted to create demos that worked, rather than a viable real "design". They are meant to demonstrate all the features, and the sort of problems you can solve in SS. I think they are way more extensive than any other simulators examples. There is a lot of behavioural, system examples. Most haven't been updated since they were crated. That example actually has an external gate resister to get convergence, but since then I added RG to the mosfet core model itself. My mosfet 1 now supports an "enhanced" LTSpice VDMOS mode. http://www.anasoft.co.uk/MOS1Model.htm >> In 2000, it was a real big deal to get practical SMPS sims going. Now, my >> laptop does 90 GFlops, with 16GB of ram, and does it in about 7 secs in >> SuperSpice, so speed for board level stuff is not so important now. For >> analog ASIC, its never fast enough. >I don't think 7seconds is at all satisfactory when having >feedback control with 100ms time constants, or when doing >a PFC with 20 Hz bandwidth. Its all relative though. Using my aforementioned expensive $100k per seat, per year, Cadence suite, I often run simulations that last 1/2 or 1 hour. Main top levels can take a day, some several days. PSNoise is the main killer. I started with a HP85 in around 1982 for AC analyses, moving up to DOS PSpice in 1985 on an XT, so I am sure you can appreciate, that today, 7 secs for a SMPS, is sheer Luxury. I used to dreeeeeem of such a life when I was knee high. On that HP, I wrote my first complex number Gaussian elimination with partial pivoting routine. I also learned how to move graphic objects on screen by getting the prior background and XORing stuff. However, all this software stuff is pissing about really. After 150k lines of SS C++ code, I am still just a hack. My expertise is really only in analog design. >> I have a working ngspice-26 so I might give it go. I actually passed on >> my >> xspice code model code for the John Chan et la. Hysteresis core model to >> Paolo Nenzi many moons ago. >Your name is still listed in the manual, but I didn't know you >worked on the Chan Core model. I wrote it from scratch after Mike was lording it over everyone with his LT implementation. I actually paid £30 to get the paper! Anyone that wants my full source code to my xspice version is welcome to it. Just email me. It would be worth copying in my ASK routines for BSIm3 and BSim4 to ngspice. I added the code so that all transient terminal currents (d, g, b,s) are available. The original only has drain. Its an indispensible feature. > >No it does not, unfortunately. However, my VTune sessions show > >that, in NGSPICE at least, most time is spent in the system > >matrix load phase, not in solving this matrix. > This depends on the size of the circuit. Are you a pro? >These were small matrices, and then load time dominates. I have >the numbers when you are interested. For 1000's of transistors >(ISCAS and MCNC) solving becomes dominant, but then NGSPICE >uses KLU (which LTspice doesn't have). I have considered setting up the latest ngspice to work better with SS. Like having it as an alternative, engine. [..] > >My remark didn't make sense, as I agree that TRTOL should not > >be too large. A value of 1 is fine. > > I consider the setting of TRTOL to be somewhat controversial. > >> Ken Kundert (Spectre author) wrote a paper with the view that TRTOL >> should >> be set higher, nearer to the spice3 default 7 value and tighten up the >> accuracy settings, say to 100u or 10u. >Which paper is that? I will see if I can dig it out. > I manually set the best TRTOL and RETOL in my SuperSpice examples to get > an > optimum speed/accuracy trade-off. Typically I might use values of 2-4, and > accuracy 10u-100u >I think TRTOL=1 and RELTOL = 1m is fine, but I'll remember this when using >SuperSpice. TRTOL=1 is a safe option. For things like Sigma-Dalta, much more risky to increase, especially the tolerance. Its the bit about chaos that does it :-) My SS 1st order S-D is ok with retol=1m and trtol=5, but the 2nd order S-D has something like trtol=1 and relto=100u. It can really mess-up with looser values. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tiwill@seventransistorlabs.com> |
|---|---|
| Date | 2017-04-19 00:35 -0500 |
| Message-ID | <od6snc$v1e$1@dont-email.me> |
| In reply to | #456726 |
"Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote in message news:J8mdnd0OuafMvmjFnZ2dnUU7-K3NnZ2d@giganews.com... > This one transistor circuit just don't cut it for me. I would need to see > a much more serious design to make any conclusions as to the > speed/convergence comparison of LTSpice and NGSpice. May I offer you guys a more complicated, but still "all cards on the table" discrete, circuit to test with, then? Schematic screenshot: https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackSch.png Netlist: https://www.seventransistorlabs.com/Images/Discrete%20Flyback.nsx (YMMV with other TL431 models; this is tuned for the TI one, included. Other credits: MOSFET model is Motorola, SB160 is Thomatronik GmbH, 2N3904/6 are... dunno, Fairchild maybe?) Output, overall: https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave1.png Zoom (last 10us): https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave2.png Simulation time: it's Altium, so it's terrible. Nevermind that. LTSpice: seems to run fine but change RSHUNT --> 1/GSHUNT. Doesn't seem to be using more than one core; perhaps a bigger circuit is necessary? Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-19 05:28 -0700 |
| Message-ID | <c00eb16f-9944-4f7f-a049-646e1eb0e350@googlegroups.com> |
| In reply to | #456909 |
On Wednesday, April 19, 2017 at 7:34:35 AM UTC+2, Tim Williams wrote: > "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote in message > news:J8mdnd0OuafMvmjFnZ2dnUU7-K3NnZ2d@giganews.com... > > This one transistor circuit just don't cut it for me. I would need to see > > a much more serious design to make any conclusions as to the > > speed/convergence comparison of LTSpice and NGSpice. > > May I offer you guys a more complicated, but still "all cards on the table" > discrete, circuit to test with, then? > > Schematic screenshot: > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackSch.png > Netlist: > https://www.seventransistorlabs.com/Images/Discrete%20Flyback.nsx > (YMMV with other TL431 models; this is tuned for the TI one, included. > Other credits: MOSFET model is Motorola, SB160 is Thomatronik GmbH, 2N3904/6 > are... dunno, Fairchild maybe?) > > Output, overall: > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave1.png > Zoom (last 10us): > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave2.png > > Simulation time: it's Altium, so it's terrible. Nevermind that. > > LTSpice: seems to run fine but change RSHUNT --> 1/GSHUNT. Doesn't seem to > be using more than one core; perhaps a bigger circuit is necessary? > > Tim > > -- > Seven Transistor Labs, LLC > Electrical Engineering Consultation and Contract Design > Website: http://seventransistorlabs.com Perfectly documented! Unfortunately MUCH too small. LTspice: 8.221 seconds. NGSPICE: 1.450 seconds. SuperSpice: (don't have it on this machine) | Original .options: | .OPTIONS GMIN=1E-9 ITL4=5000 PIVTOL=1E-9 RELTOL=0.0001 RSHUNT=1E7 METHOD=GEAR MAXORD=2 | .TRAN 1E-9 0.0005 0 1E-7 UIC LTspice options (alternate solver): .options reltol=1m method=gear nomarch .tran 0 500u 10u uic NGSPICE options: .options reltol=1m method=gear .tran 0 500u 10u 20n uic -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-19 14:00 +0100 |
| Message-ID | <Y8SdncA5lMgWwmrFnZ2dnUU7-e_NnZ2d@giganews.com> |
| In reply to | #456922 |
>wrote in message >news:c00eb16f-9944-4f7f-a049-646e1eb0e350@googlegroups.com... On Wednesday, April 19, 2017 at 7:34:35 AM UTC+2, Tim Williams wrote: > "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> wrote in message > news:J8mdnd0OuafMvmjFnZ2dnUU7-K3NnZ2d@giganews.com... > > This one transistor circuit just don't cut it for me. I would need to > > see > > a much more serious design to make any conclusions as to the > > speed/convergence comparison of LTSpice and NGSpice. > > May I offer you guys a more complicated, but still "all cards on the > table" > discrete, circuit to test with, then? > > Schematic screenshot: > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackSch.png > Netlist: > https://www.seventransistorlabs.com/Images/Discrete%20Flyback.nsx > (YMMV with other TL431 models; this is tuned for the TI one, included. > Other credits: MOSFET model is Motorola, SB160 is Thomatronik GmbH, > 2N3904/6 > are... dunno, Fairchild maybe?) > > Output, overall: > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave1.png > Zoom (last 10us): > https://www.seventransistorlabs.com/Images/AltiumDiscreteFlybackWave2.png > > Simulation time: it's Altium, so it's terrible. Nevermind that. > > LTSpice: seems to run fine but change RSHUNT --> 1/GSHUNT. Doesn't seem > to > be using more than one core; perhaps a bigger circuit is necessary? > > Tim > > -- > Seven Transistor Labs, LLC > Electrical Engineering Consultation and Contract Design > Website: http://seventransistorlabs.com >Perfectly documented! >Unfortunately MUCH too small. >LTspice: 8.221 seconds. >NGSPICE: 1.450 seconds. >SuperSpice: (don't have it on this machine) Note that SS automatically prints out the simulation clock time at the end of each run type. >| Original .options: >| .OPTIONS GMIN=1E-9 ITL4=5000 PIVTOL=1E-9 RELTOL=0.0001 RSHUNT=1E7 >METHOD=GEAR MAXORD=2 | .TRAN 1E-9 0.0005 0 1E-7 UIC >LTspice options (alternate solver): >.options reltol=1m method=gear nomarch >.tran 0 500u 10u uic Now rerun LTspice with a blank setting for max time step. Then check if the waveform is ok. You usually need to let LTSpice do what it wants to do for any comparison to be valid. It uses different algos -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2017-04-19 10:35 -0700 |
| Message-ID | <71962b8c-adb7-4bed-a9e8-379820bb75d9@googlegroups.com> |
| In reply to | #456923 |
On Wednesday, April 19, 2017 at 3:01:09 PM UTC+2, Kevin Aylward wrote: > >wrote in message > >news:c00eb16f-9944-4f7f-a049-646e1eb0e350@googlegroups.com... [..] > >| Original .options: > >| .OPTIONS GMIN=1E-9 ITL4=5000 PIVTOL=1E-9 RELTOL=0.0001 RSHUNT=1E7 > >METHOD=GEAR MAXORD=2 > | .TRAN 1E-9 0.0005 0 1E-7 UIC > > >LTspice options (alternate solver): > >.options reltol=1m method=gear nomarch > >.tran 0 500u 10u uic > > Now rerun LTspice with a blank setting for max time step. > Then check if the waveform is ok. The above .tran line already has TMAX blank. The "10u" is TSTART, the time when to start saving data (I skip the transient at the start). Or did you mean something else? > You usually need to let LTSpice do what it wants to do > for any comparison to be valid. I think I did. > It uses different algos BTW, do you, by chance, know what LTspice tries to tell us with messages like these? || Changing Tseed to 1e-016 || Heightened Def Con from 3e-010 ++++++++++++to 3.3e-009 -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-04-19 20:29 +0100 |
| Message-ID | <d6mdnfJhI5QGJ2rFnZ2dnUU7-UnNnZ2d@giganews.com> |
| In reply to | #456979 |
wrote in message news:71962b8c-adb7-4bed-a9e8-379820bb75d9@googlegroups.com... On Wednesday, April 19, 2017 at 3:01:09 PM UTC+2, Kevin Aylward wrote: > >wrote in message > >news:c00eb16f-9944-4f7f-a049-646e1eb0e350@googlegroups.com... > It uses different algos >BTW, do you, by chance, know what LTspice tries to tell us >with messages like these? >|| Changing Tseed to 1e-016 >|| Heightened Def Con from 3e-010 ++++++++++++to 3.3e-009 Looks like Mikes randomly deciding whether or not to nuke Iran. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
| From | John Devereux <john@devereux.me.uk> |
|---|---|
| Date | 2017-03-10 07:19 +0000 |
| Message-ID | <87fuil8up0.fsf@devereux.me.uk> |
| In reply to | #451021 |
John Larkin <jjlarkinxyxy@highlandtechnology.com> writes: > On Thu, 9 Mar 2017 09:53:26 -0500, Phil Hobbs > <pcdhSpamMeSenseless@electrooptical.net> wrote: > >>On 03/09/2017 05:37 AM, Johann Klammer wrote: >>> On 03/09/2017 09:29 AM, rickman wrote: >>>> I was running some simulations on LTspice and it is not even using >>>> 5% of my CPU. Nothing else is topping it and the entire computer >>>> is pretty much at idle. What could be limiting the speed? >>>> >>>> One of the main reasons I bought a laptop with an i7 processor was >>>> to speed simulations. Is this wasted on LTspice or am I doing >>>> something wrong? >>>> >>> I think it saves the waveforms to a file as it goes along >>> simulating. Where you the one who complained about your hdd being >>> slow in an earlier thread? maybe try running the sim from an ext usb >>> stick. if that helps it's definitely the hdd. >>> >> >>I'd start with a ramdisk and see then. USB sticks are glacial compared >>with real flash drives. >> >>Cheers >> >>Phil Hobbs > > Try this one. 32 seconds on my new Dell. Runs about 25% CPU. 20 seconds on my old laptop. On a linux VM! -- John Devereux
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-09 13:23 -0500 |
| Message-ID | <o9s6cm$lfg$1@dont-email.me> |
| In reply to | #450949 |
On 3/9/2017 5:37 AM, Johann Klammer wrote: > On 03/09/2017 09:29 AM, rickman wrote: >> I was running some simulations on LTspice and it is not even using 5% of my CPU. Nothing else is topping it and the entire computer is pretty much at idle. What could be limiting the speed? >> >> One of the main reasons I bought a laptop with an i7 processor was to speed simulations. Is this wasted on LTspice or am I doing something wrong? >> > I think it saves the waveforms to a file as it goes along simulating. > Where you the one who complained about your hdd being slow in an earlier thread? > maybe try running the sim from an ext usb stick. if that helps it's definitely the hdd. NONE of the computer features I can see in Task Manager are being taxed at all. The disk is near zero utilization and there are 2 GB of free memory. I just watched and LTspice was only using 5% of the CPU. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | bill.sloman@ieee.org |
|---|---|
| Date | 2017-03-09 03:15 -0800 |
| Message-ID | <114894f7-9781-46c3-b695-e9d0fd488d3d@googlegroups.com> |
| In reply to | #450944 |
On Thursday, March 9, 2017 at 7:29:17 PM UTC+11, rickman wrote: > I was running some simulations on LTspice and it is not even using 5% of > my CPU. Nothing else is topping it and the entire computer is pretty > much at idle. What could be limiting the speed? > > One of the main reasons I bought a laptop with an i7 processor was to > speed simulations. Is this wasted on LTspice or am I doing something > wrong? It might be worth buying more RAM or a solid state hard disk. LTSpice can get very slow when the waveform files are are being swapped out of RAM onto hard disk. -- Bill Sloman, Sydney
[toc] | [prev] | [next] | [standalone]
| From | "Kevin Aylward" <kevinRemovAT@kevinaylward.co.uk> |
|---|---|
| Date | 2017-03-09 20:12 +0000 |
| Message-ID | <17GdnYUwcd3XKlzFnZ2dnUU7-dvNnZ2d@giganews.com> |
| In reply to | #450951 |
wrote in message news:114894f7-9781-46c3-b695-e9d0fd488d3d@googlegroups.com... >On Thursday, March 9, 2017 at 7:29:17 PM UTC+11, rickman wrote: >> I was running some simulations on LTspice and it is not even using 5% of >> my CPU. Nothing else is topping it and the entire computer is pretty >> much at idle. What could be limiting the speed? > >> One of the main reasons I bought a laptop with an i7 processor was to >> speed simulations. Is this wasted on LTspice or am I doing something >> wrong? >It might be worth buying more RAM or a solid state hard disk. >LTSpice can get very slow when the waveform files are are being swapped out >of RAM onto hard disk. Yes. True for any spice. Once it starts memory swapping, its all over. Always get as much memory as you can if running spice. I've had 16 GB on my computers for many years now. -- Kevin Aylward http://www.anasoft.co.uk - SuperSpice http://www.kevinaylward.co.uk/ee/index.html
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | sci.electronics.design
csiph-web