¿ªÔÆÌåÓý

Date

Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

On 2/24/25 3:29 PM, Bell, Dave via groups.io wrote:
Is ¡°10f¡± a special case in the parasitics settings?
For a regular cap, it would mean 10 Farads!
Farads being the only possible unit for capacitance, there is no need to specify it.

--

David Schultz
"The cheeper the crook, the gaudier the patter." - Sam Spade


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

Yes, I agree, on all counts. It means Farads, in lower OR upper case.

But in the .options context, it appears to accept 10f as 10 femtofarads.

That¡¯s logical, because who would want a 10F parasitic shunt capacitance?

?

I¡¯m just disturbed that it¡¯s different, between contexts.

Not much different from ^ vs. **, where the carat could mean exponentiation or exclusive OR

?

?

From: [email protected] <[email protected]> On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 2:03 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

I think that 10 means 10 farads, 10m means 10 millifarads etc, but, with a space in between, 10 f or 10 F or 10 m means 10 farads and the following letter is disregarded, or throws an error in some cases. This works in the component properties pane.

On 2025-02-24 21:52, Bell, Dave via groups.io wrote:

In *this case*, I see that.

Seems like a bit inconsistent¡­

?

From: [email protected] <[email protected]> On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 1:36 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

10f is recognized as 10 femtofarads.

On 2025-02-24 21:29, Bell, Dave via groups.io wrote:

Is ¡°10f¡± a special case in the parasitics settings?

For a regular cap, it would mean 10 Farads!

?

From: [email protected] <[email protected]> On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

?

?

The following line solved the problem.Is there some manual or intution regarding why these might help?

.options cshunt =10f gshunt=10n abstol=10n vntol=1m

?

Thanks.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

?

Virus-free.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion


Re: .MEAS Failure

 

¿ªÔÆÌåÓý

On 24/02/2025 22:50, eewiz via groups.io wrote:
.meas TooLow1 FIND V(XSW11:X1:Qc,XSW11:X1:Qe) WHEN V(XSW11:X1:Qc,XSW11:X1:Qe)=2 FALL=1
works and produces;
toolow1: v(xsw11:x1:qc,xsw11:x1:qe)=2 at 0.00804696
?
Zooming in the plot window to the end of the universe, I see this point.
8.0469636ms 2.0000203V
The next point is:
8.0469636ms 1.9999355V
The time values must have greater precision than can be seen because a node can't have two different voltages at the same time.
I now see that since there is no value in the data that is exactly 2.0000000 it had to perform a poor mans less-than function.
No, that is not the case - wrong conclusion.
The code saw that 1.9999355 was less-than 2 where the previous sample 2.0000203 was more than two.
So that's a fall.
There was no test to see if data was ever == 2 as the .MEAS statement would imply.
I now see that the Fall and Rise modifiers mimic less-than or greater-than behavior for the .MEAS FIND WHEN statement.
Try again with:

.options numdgt=15.

By default, the .raw file is written with single precision; this option enables double precision (and approximately doubles the .raw file size).

There was no test to see if data was ever == 2 as the .MEAS statement would imply.
That's because the computation used interpolation - an estimation based on the closest two available data points, as previously stated. Obviously, there is no actual data point at exactly 2V. .MEAS can only make guesses on the data that actually exists in the .raw file, as it is a post-analysis calculation. There's no guarantee that any analysis can achieve a data point that shows V ¡Ô 2V, regardless of the maximum time step. This is why interpolation is used. That's just how the LTspice time step algorithm works.

--
Regards,
Tony


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

I think that 10 means 10 farads, 10m means 10 millifarads etc, but, with a space in between, 10 f or 10 F or 10 m means 10 farads and the following letter is disregarded, or throws an error in some cases. This works in the component properties pane.

On 2025-02-24 21:52, Bell, Dave via groups.io wrote:

In *this case*, I see that.

Seems like a bit inconsistent¡­

?

From: [email protected] <[email protected]> On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 1:36 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

10f is recognized as 10 femtofarads.

On 2025-02-24 21:29, Bell, Dave via groups.io wrote:

Is ¡°10f¡± a special case in the parasitics settings?

For a regular cap, it would mean 10 Farads!

?

From: [email protected] <[email protected]> On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

?

?

The following line solved the problem.Is there some manual or intution regarding why these might help?

.options cshunt =10f gshunt=10n abstol=10n vntol=1m

?

Thanks.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

?

Virus-free.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

In *this case*, I see that.

Seems like a bit inconsistent¡­

?

From: [email protected] <[email protected]> On Behalf Of John Woodgate
Sent: Monday, February 24, 2025 1:36 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

10f is recognized as 10 femtofarads.

On 2025-02-24 21:29, Bell, Dave via groups.io wrote:

Is ¡°10f¡± a special case in the parasitics settings?

For a regular cap, it would mean 10 Farads!

?

From: [email protected] <[email protected]> On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

?

?

The following line solved the problem.Is there some manual or intution regarding why these might help?

.options cshunt =10f gshunt=10n abstol=10n vntol=1m

?

Thanks.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

?

Virus-free.


Re: .MEAS Failure

 

Hello All:
?
.meas TooLow1 FIND V(XSW11:X1:Qc,XSW11:X1:Qe) WHEN V(XSW11:X1:Qc,XSW11:X1:Qe)=2 FALL=1
works and produces;
toolow1: v(xsw11:x1:qc,xsw11:x1:qe)=2 at 0.00804696
?
Zooming in the plot window to the end of the universe, I see this point.
8.0469636ms 2.0000203V
The next point is:
8.0469636ms 1.9999355V
The time values must have greater precision than can be seen because a node can't have two different voltages at the same time.
I now see that since there is no value in the data that is exactly 2.0000000 it had to perform a poor mans less-than function.
The code saw that 1.9999355 was less-than 2 where the previous sample 2.0000203 was more than two.
So that's a fall.
There was no test to see if data was ever == 2 as the .MEAS statement would imply.
I now see that the Fall and Rise modifiers mimic less-than or greater-than behavior for the .MEAS FIND WHEN statement.
?
All for now
?
Sent:?Monday, February 24, 2025 at 12:17 PM
From:?"eewiz via groups.io" <eewiz@...>
To:[email protected]
Subject:?Re: [LTspice] .MEAS Failure
?
Hello All:
?
Sorry for being late to the party but I had to grab some sleep time.
?
So, it's equality only.
No matter how many times I read the .meas help I would not come to that conclusion.
To me;?WHEN <expr> means WHEN <any and all types of mathematical experssion>.
WHEN <expr of equality only> would be much more redily understandable.
?
I noticed that there were no examples of anything like:
Print the time if and when a power exceeds 5W.
Print the time if and when a collector-emitter voltage goes less than 2V.
Print the time if and when a snubbed node ever exceeds 15.6V.
?
Those are always the type of questions that I regularly need answers to.
?
Thanks very much for the examples.
I will see if I can get the answers I need using only equality.
?
All for now

?
Sent:?Monday, February 24, 2025 at 11:24 AM
From:?"Tony Casey via groups.io" <tony@...>
To:[email protected]
Subject:?Re: [LTspice] .MEAS Failure
On 24/02/2025 15:57, Andy I via groups.io wrote:
But I distinctly recall Helmut Sennewald cautioning people not to test for equality.? Better to use >= or <=.? The implication was that it did not use linear interpolation in those situations.? I thought .MEAS was one of them.
This would be the case, for example, in a B-source expression, which disallows the "=" operator anyhow, e.g.:
?
B1 EQ0 0 V=if(V(test)=0,1,0)

..which triggers an error, but:
?
B1 EQ0 0 V=if(V(test)==0,1,0)

..doesn't.

However, in the example of my simple sine source circuit, the 2nd of those expressions only results in V(eq0)=1 once at time=0, because none of the following data points result in V(test)=0, even though it is clear the waveform is periodic and passes through zero twice every cycle. This example therefore doesn't use interpolation, it simply looks at each data point.

--
Regards,
Tony


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

10f is recognized as 10 femtofarads.

On 2025-02-24 21:29, Bell, Dave via groups.io wrote:

Is ¡°10f¡± a special case in the parasitics settings?

For a regular cap, it would mean 10 Farads!

?

From: [email protected] <[email protected]> On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

?

?

The following line solved the problem.Is there some manual or intution regarding why these might help?

.options cshunt =10f gshunt=10n abstol=10n vntol=1m

?

Thanks.

--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

Virus-free.


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

Is ¡°10f¡± a special case in the parasitics settings?

For a regular cap, it would mean 10 Farads!

?

From: [email protected] <[email protected]> On Behalf Of john23 via groups.io
Sent: Monday, February 24, 2025 12:29 PM
To: [email protected]
Subject: EXTERNAL: Re: [LTspice] intuition behind a solution to crashing time domain simulation #Time-step-too-small

?

?

?

The following line solved the problem.Is there some manual or intution regarding why these might help?

.options cshunt =10f gshunt=10n abstol=10n vntol=1m

?

Thanks.


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

?
?
The following line solved the problem.Is there some manual or intution regarding why these might help?
.options cshunt =10f gshunt=10n abstol=10n vntol=1m
?
Thanks.


Re: Monitor simulation percent completion from python

 

There is no way of knowing how large the .raw file will be.? Indeed, it might not be the same even for similar simulations.? It depends on how many time points LTspice actually used, which is not known until it's done.
?
I suspect LTspice currently outputs no progress information when running in batch mode, and the only way to get that, would be by adding it (new feature) to LTspice.? As you know, this forum is not the place to request that.
?
Even having progress info., it can't tell you how much time is still needed.? A simulation might whiz through the first 90% and then take hours or days trudging through the last 5%.
?
Andy


Re: Initial conditions for inductor current in .TRAN UIC analysis - follow up

 

Apologize, I just wanted to make sure I understood it correctly :-)


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

I don't know what's going on here. U1 isn't open-loop. Are we looking at the same .ASC, PID_section_united_AC_separate?? U3 is open-loop at DC. U1 and U2 have unity gain, U4 has 100 times gain at DC. In such a circuit, I would not expect a TSTS? error, and I would expect the model o a costly opamp to be a good one. I meant that I could not see how to verify node 38 without going back over the previous many emails.

On 2025-02-24 17:19, Andy I via groups.io wrote:
On Mon, Feb 24, 2025 at 11:11 AM, John Woodgate wrote:

I agree, of course, but the AD797 is a (costly) opamp. It should not produce a TSTS error in that .ASC.

Why not?

Does expensive silicon imply an equally expensive SPICE model?? Shouldn't every SPICE model ever made, whether for cheap or expensive silicon, not produce time step too small errors?? And yet they happen.

Without a lot of digging, it isn't possible to confirm that it is connected correctly; for example, is node 38 really the output?

The SPICE model claims that it is.? What is your point with that question?? Are you suggesting that its creator at AAG/PMI did not know what she/he was doing, and mis-labeled the output node?? If that happened, then there would be an awful lot more questions than that one.
?
I think simpler circuits are in order for this simulation.? Realizing that U1 is open-loop might be a good first step.? Since this is a DC simulation, capacitors are open-circuits.? No negative feedback around U1.? U3 seems to run into difficulty right in the vicinity of 0 V output, which is odd.
?
Even when the circuit is made smaller and it runs, it has considerable difficulty at certain operating points.? The SPICE output log is foll of warning messages that suggest it has trouble, and it suggests alternative settings to help.
?
Andy
?
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion


Re: Monitor simulation percent completion from python

 

Thanks Tony, I have a callback function for when the simulation finishes so the user gets notified via email. They are asking for percent completion because they are running simulations that take 3 days... and highlighting to me that you can see % completion in the GUI. I was wondering if I could parse one of the output files but probably the only way is just to show the current size of the raw file. You of course wouldn't have an idea of percent completion unless you knew approximately how large the raw file was expected to be though.


Re: Initial conditions for inductor current in .TRAN UIC analysis - follow up

 

On Mon, Feb 24, 2025 at 12:15 PM, Carlo wrote:
Do you mean it might try to compute another/different ITS pass ...
You appear to be extremely insistent by asking this question over and over, as if asking it every few minutes will twist my arm and force me to answer you immediately.
?
I don't work that way.
?
Go somewhere else.? Take your nagging to another forum.? Keep it up, and you'll be permanently out of here.
?
Andy
?


Re: .MEAS Failure

 

On Mon, Feb 24, 2025 at 11:24 AM, Tony Casey wrote:
On 24/02/2025 15:57, Andy I via groups.io wrote:
But I distinctly recall Helmut Sennewald cautioning people not to test for equality.? Better to use >= or <=.? The implication was that it did not use linear interpolation in those situations.? I thought .MEAS was one of them.
This would be the case, for example, in a B-source expression, which disallows the "=" operator anyhow, e.g.:

B1 EQ0 0 V=if(V(test)=0,1,0)

..which triggers an error, but:

B1 EQ0 0 V=if(V(test)==0,1,0)

..doesn't.
Yeah - that is a different problem, caused by misusing operators.
?
Helmut's concern was over the lack of exact equality.? I guess it applied only in specific situations, which did not include this one.
?
Andy
?


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

On Mon, Feb 24, 2025 at 11:11 AM, John Woodgate wrote:

I agree, of course, but the AD797 is a (costly) opamp. It should not produce a TSTS error in that .ASC.

Why not?

Does expensive silicon imply an equally expensive SPICE model?? Shouldn't every SPICE model ever made, whether for cheap or expensive silicon, not produce time step too small errors?? And yet they happen.

Without a lot of digging, it isn't possible to confirm that it is connected correctly; for example, is node 38 really the output?

The SPICE model claims that it is.? What is your point with that question?? Are you suggesting that its creator at AAG/PMI did not know what she/he was doing, and mis-labeled the output node?? If that happened, then there would be an awful lot more questions than that one.
?
I think simpler circuits are in order for this simulation.? Realizing that U1 is open-loop might be a good first step.? Since this is a DC simulation, capacitors are open-circuits.? No negative feedback around U1.? U3 seems to run into difficulty right in the vicinity of 0 V output, which is odd.
?
Even when the circuit is made smaller and it runs, it has considerable difficulty at certain operating points.? The SPICE output log is foll of warning messages that suggest it has trouble, and it suggests alternative settings to help.
?
Andy
?


Re: .MEAS Failure

 

?
Hello All:
?
Sorry for being late to the party but I had to grab some sleep time.
?
So, it's equality only.
No matter how many times I read the .meas help I would not come to that conclusion.
To me;?WHEN <expr> means WHEN <any and all types of mathematical experssion>.
WHEN <expr of equality only> would be much more redily understandable.
?
I noticed that there were no examples of anything like:
Print the time if and when a power exceeds 5W.
Print the time if and when a collector-emitter voltage goes less than 2V.
Print the time if and when a snubbed node ever exceeds 15.6V.
?
Those are always the type of questions that I regularly need answers to.
?
Thanks very much for the examples.
I will see if I can get the answers I need using only equality.
?
All for now

?
Sent:?Monday, February 24, 2025 at 11:24 AM
From:?"Tony Casey via groups.io" <tony@...>
To:[email protected]
Subject:?Re: [LTspice] .MEAS Failure
On 24/02/2025 15:57, Andy I via groups.io wrote:
But I distinctly recall Helmut Sennewald cautioning people not to test for equality.? Better to use >= or <=.? The implication was that it did not use linear interpolation in those situations.? I thought .MEAS was one of them.
This would be the case, for example, in a B-source expression, which disallows the "=" operator anyhow, e.g.:
?
B1 EQ0 0 V=if(V(test)=0,1,0)

..which triggers an error, but:
?
B1 EQ0 0 V=if(V(test)==0,1,0)

..doesn't.

However, in the example of my simple sine source circuit, the 2nd of those expressions only results in V(eq0)=1 once at time=0, because none of the following data points result in V(test)=0, even though it is clear the waveform is periodic and passes through zero twice every cycle. This example therefore doesn't use interpolation, it simply looks at each data point.

--
Regards,
Tony


Re: .MEAS Failure

 

¿ªÔÆÌåÓý

On 24/02/2025 15:57, Andy I via groups.io wrote:
But I distinctly recall Helmut Sennewald cautioning people not to test for equality.? Better to use >= or <=.? The implication was that it did not use linear interpolation in those situations.? I thought .MEAS was one of them.
This would be the case, for example, in a B-source expression, which disallows the "=" operator anyhow, e.g.:

B1 EQ0 0 V=if(V(test)=0,1,0)

..which triggers an error, but:

B1 EQ0 0 V=if(V(test)==0,1,0)

..doesn't.

However, in the example of my simple sine source circuit, the 2nd of those expressions only results in V(eq0)=1 once at time=0, because none of the following data points result in V(test)=0, even though it is clear the waveform is periodic and passes through zero twice every cycle. This example therefore doesn't use interpolation, it simply looks at each data point.

--
Regards,
Tony


Re: .MEAS Failure

 

mhx, sorry, I know better.
?
I did not excluding anything via .save.
?
.meas TRAN TooLow1 find V(XSW11:X1:Qc)-V(XSW11:X1:Qe) when V(XSW11:X1:Qc)-V(XSW11:X1:Qe)<1 still produces;
Measurement "toolow1" FAIL'ed
?
It's not the comma syntax. The above still fails even with full mathematical syntax.
?
I added a simple .meas statement using comma syntax and it works two levels deep.
?
.meas Low1 MIN V(XSW11:X1:Qc,XSW11:X1:Qe)
low1: MIN(v(xsw11:x1:qc,xsw11:x1:qe))=0.00498581 FROM 0 TO 0.0500001
?
It is something to do with ".meas find when".
?
.meas TooLow1 find V(XSW11:X1:Qc)-V(XSW11:X1:Qe) when V(XSW11:X1:Qc)-V(XSW11:X1:Qe)<1
.meas TooLow2 find V(XSW11:X1:Qc,XSW11:X1:Qe) when V(XSW11:X1:Qc,XSW11:X1:Qe)<1
.meas TooLow3 find V(XSW11:X1:Qc)-V(XSW11:X1:Qe) when V(v+15)-V(v-15)>28
.meas TooLow4 find V(v+15)-V(v-15) when V(XSW11:X1:Qc)-V(XSW11:X1:Qe)<1
.meas TooLow5 find V(v+15,v-15) when V(XSW11:X1:Qc)-V(XSW11:X1:Qe)<1
.meas TooLow6 find V(XSW11:X1:Qc)-V(XSW11:X1:Qe) when V(v+15,v-15)>28
.meas TooLow7 find V(XSW11:X1:Qc) when V(v+15,v-15)>28
.meas TooLow8 find V(XSW11:X1:Qc) when V(XSW11:X1:Qe)<1
?
Measurement "toolow1" FAIL'ed
Measurement "toolow2" FAIL'ed
Measurement "toolow3" FAIL'ed
Measurement "toolow4" FAIL'ed
Measurement "toolow5" FAIL'ed
Measurement "toolow6" FAIL'ed
Measurement "toolow7" FAIL'ed
Measurement "toolow8" FAIL'ed

All for now

?
?
Sent:?Monday, February 24, 2025 at 5:24 AM
From:?"mhx via groups.io" <mhx@...>
To:[email protected]
Subject:?Re: [LTspice] .MEAS Failure
No, that is not what I said ...
.MEAS TRAN TooLow1 find V(XSW11:X1:Qc ) - V( XSW11:X1:Qe) when V(XSW11:X1:Qc ) - V( XSW11:X1:Qe) < 1
(may need extra parentheses).

A final one: Do you have a .SAVE statement somewhere?

-marcel




?


Re: intuition behind a solution to crashing time domain simulation #Time-step-too-small

 

¿ªÔÆÌåÓý

I agree, of course, but the AD797 is a (costly) opamp. It should not produce a TSTS error in that .ASC. Without a lot of digging, it isn't possible to confirm that it is connected correctly; for example, is node 38 really the output? The .ASC appears to work with the simple opamp.. It could hardly refuse.

On 2025-02-24 14:52, Andy I via groups.io wrote:
On Mon, Feb 24, 2025 at 09:03 AM, john23 wrote:
Hello ,I have the following file which is presenting an error shown below
...
Convergence Failure: ?Time step too small; time = 8.11724e-08, timestep = 1.25e-19: trouble with instance "u1:DSC1"
I assume this is the failure you asked about.
?
"Time step too small" errors are unfortunately difficult to deal with.? If this is your first time encountering a "timestep too small" error, "welcome to the club".
?
"Time step too small" errors happen for this reason.? When SPICE can't converge at any timepoint, it backs up to the previous one, sets the time step smaller (I think by a factor of 8), and tries again.? It is more likely to find convergence by not trying to go too far into the future, so a smaller timestep after the last good point is more likely to solve, and then it can move on.
?
But occasionally that doesn't work.? It keeps trying smaller and smaller timesteps, until eventually the timestep gets ridiculously small, and SPICE/LTspice aborts with that error message.
?
The root problem is most likely because there is something in the circuit that behaves badly.? Maybe a component's function or its derivative has a discontinuity.? Both are bad for SPICE and should never happen, but many models have discontinuities and can lead to these problems.? The best remedy is to fix the models.? But often we can't do that.? There are a handful of other things that can sometimes help,?
?
Download the FAQ file.? Open it and read until you find the section about "time step too small" errors, and start reading.? There are a couple dozen suggestions that MIGHT help.? There is no guarantee that you can ever fix a "time step too small" error.
?
When I ran your simulation, I do not (yet) have a "time step too small" error, but it has not found the initial DC solution yet.? Time step too small errors can happen even during the initial DC solution phase, because one of the algorithms is "Pseudo-Tran", which applies the transient solver to finding the DC solution.? Sometimes it can abort in that phase, even though it is not a .TRAN simulation at all.
?
Andy
?
?
--
OOO - Own Opinions only If something is true: * as far as we know - it's science *for certain - it's mathematics *unquestionably - it's religion

Virus-free.