Under Wine on Ryzen 2600X it finished it in ~200 seconds. Your i5 Alder Lake should be ~2x as fast as mine, so no real speed penalty for running it under Wine.
Is there a way for LTSpice to use the GPU? Default doesn't seem to.
Strange convergence problem. I put a sim together of the F6 amp for fun and find it won't drive a model of the B&W703 speaker. Adding an unterminated resistor (any value, even a million meg ohms) to ground and the sim runs. Resistor at the top left.
And without. Look at the scale.
The speaker model actually starts with a series 1 ohm and so should not be to weird.
And without. Look at the scale.
The speaker model actually starts with a series 1 ohm and so should not be to weird.
I do indeed, yes. It seems to work if you connect a single resistor to other points as well.
For example this works:
I have a slight variation of this, sometimes: a known good circuit wouldn't converge; then I change a value by a tiny bit, like 1.01K in stead of 1K, and it happily works. That's valid for all versions.
Maybe that's related to the legendary "Berkeley quality code"?
NB.: Simulation Program with Integrated Circuit Emphasis, L. W. Nagel, ERL-M520, 9 May 1975, U. C. Berkeley
Maybe that's related to the legendary "Berkeley quality code"?
NB.: Simulation Program with Integrated Circuit Emphasis, L. W. Nagel, ERL-M520, 9 May 1975, U. C. Berkeley
I have a slight variation of this, sometimes: a known good circuit wouldn't converge; then I change a value by a tiny bit, like 1.01K in stead of 1K, and it happily works. That's valid for all versions.
Maybe that's related to the legendary "Berkeley quality code"?
NB.: Simulation Program with Integrated Circuit Emphasis, L. W. Nagel, ERL-M520, 9 May 1975, U. C. Berkeley
I've certainly come across convergence problems before in the other version but this one seemed a bit different. Why would a resistor not connected to anything but ground get it to run... I have no idea on that one.
How are you calculating that value?
It certainly seems to work but then so does changing other things.
The last parameter in '.trans' is the maxstep.
There should be a power of two here (as a divisor).
0.0000001220703125 has been calculated as 2 to the power of 14
There should be a power of two here (as a divisor).
.param Freq=1000 cycle=2 initcycle=0 stepcycle=2**16
.tran 0 {(cycle+initcycle)/Freq} {initcycle/Freq} {cycle/Freq/(stepcycle)}
0.0000001220703125 has been calculated as 2 to the power of 14
The time interval for the measuring points in the requested time window is always a multiple of two (2,4,8,16,...).
This is the same with FFT.
If there is no specification for 'maxstep', it is set automatically by LTspice.
LTspice sometimes doesn't accept the user's input and only strange things happen.
Why, for what reason is not clear to me.
This is the same with FFT.
If there is no specification for 'maxstep', it is set automatically by LTspice.
LTspice sometimes doesn't accept the user's input and only strange things happen.
Why, for what reason is not clear to me.
Interesting, thanks. I looked back to how I used to calculate it and I got a difference answer (lol)
So the sim runs for 20ms and gathers data from 16ms onward giving 4ms 'run time' for data. As I recall we calculate 4ms/262144 (which is the default number of samples LT is set to) and doing that I get 0.0152587890625us
Now that works and takes a wee while to run at 19 seconds.
Just trying the full 20ms/262144 as a timestep and that... well that actually freezes at 2.1% completed.
Maths is not my strong point I'm afraid
I'll have another play around.
So the sim runs for 20ms and gathers data from 16ms onward giving 4ms 'run time' for data. As I recall we calculate 4ms/262144 (which is the default number of samples LT is set to) and doing that I get 0.0152587890625us
Now that works and takes a wee while to run at 19 seconds.
Just trying the full 20ms/262144 as a timestep and that... well that actually freezes at 2.1% completed.
Maths is not my strong point I'm afraid
I'll have another play around.
Mooly, I ran your .asc in LTXVII and had no problem with whatever setting of timestep starting from 10nsec to 10usec including your timestep.
Hans
I used Mooly's .options maxstep= xxxxMaybe it depends on the processor of the PC.
"The ways of the Lord are unfathomable"
The timestep is slightly different:
Hans
Oh that's interesting, thanks for trying that
With Toshiba's JFETs it also works with the old timestep.
Now that doesn't run for me... is that odd?
If I change the upper 47 ohm gate resistor to this then it runs:
Which timestep did you use for this?If I change the upper 47 ohm gate resistor to this then it runs:
(at 47 ohms, not 47.0000001)
I ran it without altering anything and I can see the timestep I put in originally...
Which I took to me it ran with that timestep and your FET models.
Which I took to me it ran with that timestep and your FET models.
I ran further tests with version 17.0.35.0.
The 'Test.asc' file runs without errors.
However, there are problems with the 'Test_BW.asc' file.
In this case, if I change resistor R11 to 47.0000001, there are no more problems.
The PC with version 17.0.35.0 is an Intel I3 (x64) Win10
The new Version 17.1.6 runs on an Intel I5 (x64) Win11
The 'Test.asc' file runs without errors.
However, there are problems with the 'Test_BW.asc' file.
In this case, if I change resistor R11 to 47.0000001, there are no more problems.
The PC with version 17.0.35.0 is an Intel I3 (x64) Win10
The new Version 17.1.6 runs on an Intel I5 (x64) Win11