Slinky Question

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

...It doesn't show any non-linear *curves*. Only
straight lines, therefore how can it be implementing
the above referanced equations?

Because your example is broken...

Yeah. It looks like I didn't translate the set-up
correctly. I am not an expert in running LTSpice.
I seem to be able to get the basic curves to look
simular now.

It might go a bit beyond that.

Oh dear...Here we go again... the personal insults...

Magnetic core saturation
is quiet an abrupt effect, analogous to electrical
breakdown. If one's not aware of how abrupt it is
one can miss it as you did.

That was not the reason in the slightest. I copied over the wrong
parameter. For starters I had Hc=10 in my SS simulation, but initially
an erroneously set it to 1 in the LTSpice version.

You do have this habit of trying to imply people are stupid. This
doesn't do you any favours. The idea that you are suggesting that I am
not aware of the basic behaviour of core saturation shows more about the
chips on your shoulder then anything else. You simply don't give up on
this approach do you. You need to grow up a bit. What are you trying to
achieve? Do you serously expect those that read these NGs think I'm a
dunce? Arrogant, maybe...

That would explain why

you were also so sure core saturation was so important
to model.

What's with it with you? I said that it is a *useful* property to model,
and indeed it is. In what fantasy universe did you read such purported
claims of mine? Sure, its a region where you don't want to operate in,
but ideally, spice should tell you this.

My advice is usually to just use linear

{snip advice from a software engineer on designing analogue electronics}

When a inductor with a magnetic core is transversing
a minor B-H loop, the inductance changes with a
discontinuity then H reverses.

Yes, if the input changes discontinuously. However,
if the input changes *smoothly* and very slowly, i.e.
as in a slow sinewave, there should be no hard switch
in inductance. It should behave something like like
it is coming out of transistor saturation.

Nonsense. Look at a minor loop of a B-H curve. The
inductance(i.e., differential inductance) changes
discontinuously when the direction of H changes. The
upper and lower lines followed by B meet in the corner
at the same value of B, but the slope of the line,
proportional to L, changes discontinuously at this
corner upon reversal of H.

Well, untill I get some more real data on real cores I will have to pass
on further discussion on this point. What I will say is that it is quite
posible to get very, very sharp points at the intersection of two
curves, and still have both slopes match at that point, something like a
shark fin. For magnet curves approaching saturation, from graphs I have
seen, this appears to indeed be what is happening, so I might have a go
at doing this to avoid the glitch. I just have this issue with
discontinuities in the real world.

I had a look at the corrected circuit, and LTSpice
seems to be handling this ok, with no jumps. What
did you do to achieve this?

I could tell you, but then I'd have to hire you.

Ahhh... So you admit that you actually had to do something special to
overcome an inherent issue. That's all I need to know.

Again, just the fact that you noted that supporting a gap requires a
relativly messy equation to be handled tells me all I need to know to
implement it. Its when you think that you have missed something simple
and obvious that there is a problem. When you are looking at something
the first time, and conclude that the problem is a bit trickier then the
impression being given, your not sure if you have completely missed the
boat.

BTW, if you read the article,

I have. Spent several days on it. Its explanation is
dreadful. It gives no explicit details, only
general guidelines.

[rubbish proof trying to prove something that
is false is true deleted]

Nonsense. If you could have seen an error, you would have pointed it
out. You have no argument to refute my claim at all. Its that simple.

The slope of (B_+ + B_-)/2 cannot possible be equal to the slope of B_+
+ Bd at h max.

Prove that this is not the case, or apologise and retract your claim, as
I would most certainly do if I were proven incorrect.

My data is that the problem lies with the reader. I
know a few people besides myself who read that article
and understood.

Oh... You mean many say they understand. As you yourself pointed out,
apparently, many implement this model incorrectly so obviously what
people say is not to be taken very seriously. Sure, I am having trouble
understanding how this particular model achieves a continuous derivative
when rejoining the average curve (the asymmetrical case makes this very
clear), but other than that, I have already posted my graphs showing
that apart from the minor glitch, not actually visible on the graphs as
they are small, the graphs appear correct. So, I can't be as clueless as
you still keep trying to put forward. Why most you keep doing this. Just
what is your problem?

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

That is a really excellent analysis and interpretation.

Yep. So here we go again Mike. I point out, and show mathematically,
that the slopes at intersections can't match. You declare my correct
proof, false because you cant understand it, yet praise analog here for
pointing out that very same fact. Unreal dude. As I said, you need to
grow up a bit.

Analog actually knows what he's talking about. You do not.
Your treatise was about a discontinuty causing a voltage spike.
The discontinuty is real, the spike is not. You starting the
discussion with a stupid statement that LTspice wasn't doing
as I explained. Hence I took you as a fool for saying such a
stupid things for not only were you mistaken, but you didn't
check what you were doing before making such a stupid assertion.
It's not like there isn't clear documentaion in the help and
other places.

--Mike

 

[Mike Engelhardt]

Kevin,

When a inductor with a magnetic core is transversing
a minor B-H loop, the inductance changes with a
discontinuity then H reverses.

Yes, if the input changes discontinuously. However,
if the input changes *smoothly* and very slowly, i.e.
as in a slow sinewave, there should be no hard switch
in inductance. It should behave something like like
it is coming out of transistor saturation.

Nonsense. Look at a minor loop of a B-H curve. The
inductance(i.e., differential inductance) changes
discontinuously when the direction of H changes. The
upper and lower lines followed by B meet in the corner
at the same value of B, but the slope of the line,
proportional to L, changes discontinuously at this
corner upon reversal of H.

Well, untill I get some more real data on real cores I
will have to pass on further discussion on this point.

That is the problem. You do not know what you're talking
about. Your treatise was about a discontinuity causing a
voltage spike. The discontinuity is real, the spike is not.
You starting the discussion with a stupid statement that
LTspice wasn't doing as I explained. OK, so I take you
as a fool for saying such a stupid things for not only
were you mistaken, but you didn't check what you were
doing before making such a stupid assertion. It's not
like there isn't lots of clear documentation and a working
example in the help and other places.

--Mike

 

[R. Steve Walz]

Roger Gt wrote:

X-No-Archive: yes
"John Larkin" wrote
: "Roger Gt" wrote
: >"Chuck Harris" wrote
: ><snip
: >: I see more problems with your version of communism, than I
see
: >: with our current version of capitalism. -Chuck
:
: >There is NO viable form of communism! It is the dream of a
utopia
: >with no responsibilities nor problems.
: RSW would disagree. He wants to be responsible for the killing.
John

Perhaps his interest isn't the Communist government, it's the
killing! He's in a unique category.
------------

Nope.

-Steve
--
-Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public

 

[Mike Engelhardt]

Kevin,

Oh, didn't mean to post that last twice. OK, let's
try to have some fun like in the good old days.

...It doesn't show any non-linear *curves*. Only
straight lines, therefore how can it be implementing
the above referanced equations?

Because your example is broken...

Yeah. It looks like I didn't translate the set-up
correctly. I am not an expert in running LTSpice.
I seem to be able to get the basic curves to look
simular now.

It might go a bit beyond that. Magnetic core saturation
is quiet an abrupt effect, analogous to electrical
breakdown. If one's not aware of how abrupt it is
one can miss it as you did.

That was not the reason in the slightest.

I see. Well, it does happen so fast in your simulation
that you missed it which does hint at a lack of
understanding of the abruptness practical phenomenon.

My advice is usually to just use linear...

Oh dear...Here we go again... the personal insults...
{snip advice from a software engineer on designing
analogue electronics}

Now that's an attempt at an insult. Of course I am
certainly an accomplished analog design engineer and
have certainly found that advice on the mark as a rule
of thumb. With few exceptions, it's all the necessary
and all most SPICE simulation affords anyway.

You do have this habit of trying to imply people are
stupid.

No, Analog read the paper and really understood how
the B-H curves were transversed. I really doubt his
demonstration could have been stumbled into if he
didn't really understand all the cases of the minor
loops. It was a level of insightfulness I wouldn't
have expected form someone other than one who tried
to implement the model. No, it's just that I think
you're stupid. Stupid here isn't about IQ, it what
people get called when they insist on an opinion on
a matter that they don't really know much about.

I had a look at the corrected circuit, and LTSpice
seems to be handling this ok, with no jumps. What
did you do to achieve this?

I could tell you, but then I'd have to hire you.

Ahhh... So you admit that you actually had to do
something special to overcome an inherent issue.
That's all I need to know.

It was just a joke, a play on the expression joking
used in defense, "I could tell you, but then I'd have
to kill you."

BTW, if you read the article,

I have. Spent several days on it. Its explanation is
dreadful. It gives no explicit details, only
general guidelines.

[rubbish proof trying to prove something that
is false is true deleted]

Nonsense. If you could have seen an error, you would
have pointed it out. You have no argument to refute
my claim at all. Its that simple.

Idiot, I've said many times that the inductance is
discontinuous. That refuses the rest of your treatise
about voltage spikes due to discontinuities in inductance.
Here's the meat:

Nonsense. Look at a minor loop of a B-H curve. The
inductance(i.e., differential inductance) changes
discontinuously when the direction of H changes. The
upper and lower lines followed by B meet in the corner
at the same value of B, but the slope of the line,
proportional to L, changes discontinuously at this
corner upon reversal of H.

Well, untill I get some more real data on real cores I
will have to pass on further discussion on this point

You don't know at a B-H curve looks like. Your knowledge
to opinion ratio is not positive definite. I believe
in Usenet parlance one says you have your head up your
ass.

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

That is a really excellent analysis and interpretation.

Yep. So here we go again Mike. I point out, and show mathematically,
that the slopes at intersections can't match. You declare my correct
proof, false because you cant understand it, yet praise analog here
for pointing out that very same fact. Unreal dude. As I said, you
need to grow up a bit.

Analog actually knows what he's talking about. You do not.

Oh.. Like, so you have a mathematical disproof of my claim that the
intersection of the B_- loops and the average curve, can not have equal
slopes.

Vacuous claims are cheap dude, present your actual evidence. Come on
now...prove to us all that the B_- loops and the average curve intersect
with the same derivative.


Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

Oh, didn't mean to post that last twice. OK, let's
try to have some fun like in the good old days.

Oh. you made a mistake, and you admit to it. Things may be improving.

...It doesn't show any non-linear *curves*. Only
straight lines, therefore how can it be implementing
the above referanced equations?

Because your example is broken...

Yeah. It looks like I didn't translate the set-up
correctly. I am not an expert in running LTSpice.
I seem to be able to get the basic curves to look
simular now.

It might go a bit beyond that. Magnetic core saturation
is quiet an abrupt effect, analogous to electrical
breakdown. If one's not aware of how abrupt it is
one can miss it as you did.

That was not the reason in the slightest.

I see. Well, it does happen so fast in your simulation

Not in my version, as I said, I ran the wrong parameters in the LT one.
Thats all
there is to it. A simple error. Big deal.

that you missed it which does hint at a lack of
understanding of the abruptness practical phenomenon.

ROTFLMAO

Forget the bit about improvement.

Complete and absolute nonsense. Like I haven't been doing lots of
simulations on this
already? Like, I pointed out one of the applications, apparently unknown
to you, of correctly simulating flux unbalance ramp ups. Oh dear indeed.
I have *specifically* been looking at this model to show the fast ramp
up of
current during saturation. Thats the whole F&*^ing point. Its something
that has been on my mind for many years, like 25 years ago when I first
discovered that some commercially released PS products had 100% failures
due to this issue. dah...

All this shows is that I don't care much for simulating in LTSpice, and
that you take every childish opportunity you can to try and show that I
don't know my profession. Look, dude that's a non starter. It just wont
wash. Sure, I make mistakes, but that hardly negates my general
expertise.

My advice is usually to just use linear...

Oh dear...Here we go again... the personal insults...
{snip advice from a software engineer on designing
analogue electronics}

Now that's an attempt at an insult.

Well, you started it. nah...nah...nah.nah...nah...

Of course I am
certainly an accomplished analog design engineer

Oh...

and
have certainly found that advice on the mark as a rule
of thumb. With few exceptions, it's all the necessary
and all most SPICE simulation affords anyway.

You do have this habit of trying to imply people are
stupid.

No, Analog read the paper and really understood how
the B-H curves were transversed. I really doubt his
demonstration could have been stumbled into if he
didn't really understand all the cases of the minor
loops. It was a level of insightfulness I wouldn't
have expected form someone other than one who tried
to implement the model.

I agree, analogue seems to have a pretty good handle on the features of
the model. But your implication here is that I am also lacking such
basic knowledge of the method, despite the fact that I already posted
graphs (http://www.anasoft.co.uk/ssbhtest.gif) showing that I have
actually implemented the essentials of the method for all loops. The
*only* issue I have currently, is the very small discontinuity when used
in an inductor.

No, it's just that I think
you're stupid. Stupid here isn't about IQ, it what
people get called when they insist on an opinion on
a matter that they don't really know much about.

Such as?

I had a look at the corrected circuit, and LTSpice
seems to be handling this ok, with no jumps. What
did you do to achieve this?

I could tell you, but then I'd have to hire you.

Ahhh... So you admit that you actually had to do
something special to overcome an inherent issue.
That's all I need to know.

It was just a joke,

Don't give up your day job.

BTW, if you read the article,

I have. Spent several days on it. Its explanation is
dreadful. It gives no explicit details, only
general guidelines.

[rubbish proof trying to prove something that
is false is true deleted]

Nonsense. If you could have seen an error, you would
have pointed it out. You have no argument to refute
my claim at all. Its that simple.

Idiot,

Oh...good argument Mike.

I've said many times that the inductance is
discontinuous.

I know you have. Now, how about an actual argument to go with it?

That refuses the rest of your treatise
^^^^^^^

refutes

about voltage spikes due to discontinuities in inductance.

Yes you have, however, you have made no *mathematical* argument to back
up your claim, so your words are completly vacuous. What you have done,
is
indicate that you believe a sharp point must have a discontinuous
derivative. This is not true. A cats claw shape shows that this is not
necessarily the case. This is easy to see. Consider two different power
series, up to 2nd order. They can be made to intersect at a point, and
also have the same derivative at this point. I agree that this may have
been overlooked for magnetic bh loops, but maybe that is what really
happens. Anyway, irrespective of the physical reality, a simulation
model taking advantage of this fact should reduce convergence problems.
Do you dispute that such a set of BH curves can be constructed, such
that L is always continuous?

I think the issue is that you are confusing time changes with B/H
transfer function changes.

The reality is that you are simply not up the subtleties of the
mathematics. I have explained it once, but it looks like I'll have to do
it again.

Look, heres the deal, either disprove my *mathematical* argument, or
retract your claim, to wit:

V = d(flux)/dt = di/dt.d(flux)/di

noting L=d(flux)/di

Claim:
If di/dt is continuous, and d(flux)/di is discontinuous than V *must* be
discontinuous. The expression for V explicitly shows that this is the
case.

Provide an argument/example to refute this statement.

If di/dt is discontinuous it could conceivably cancel a discontinuity of
L=d(flux)/di but this is not the case I am addressing.

Claim:

If *both* current and voltage are smooth (continuous derivative), a
discontinuous L=d(flux)/di, is not possible.

Now... and read my lips. Actually produce a mathematical *reason* why my
claims are false, or admit that you have no idea how a discontinuous L
can result in simultaneous continuous I and V derivatives, and that it
was just something you read while sitting on the lavatory pan.

What is interesting is that a sine wave in LTSpice, shows no
discontinuity in slopes of V or I. This is very impressive. From this I
would guess that you have some advanced general algorithms that
automatically smooth discontinuities in models. You may have even
forgotten the effect of such methods and subsequently been lead to
believe that a discontinuous L was of no consequence. Either that, or
you can provide an actual mathematical proof as to how a true
discontinuous L (d(flux)/dH)can result in both continuous derivatives of
V and I, but I wont hold my breath on this last one.

Here's the meat:

Nonsense. Look at a minor loop of a B-H curve. The
inductance(i.e., differential inductance) changes
discontinuously when the direction of H changes. The
upper and lower lines followed by B meet in the corner
at the same value of B, but the slope of the line,
proportional to L, changes discontinuously at this
corner upon reversal of H.

Well, untill I get some more real data on real cores I
will have to pass on further discussion on this point

You don't know at a B-H curve looks like.

Oh come on now, you don't give up do you. You are one sad puppy indeed.
Your claim is
truly senseless sour grapes. Don't you realise that you have no chance
in convincing anyone that I am completly clueless in BH curves, so whats
the point of making such a statement? It achives zero. How do you
propose
such a sorry state of affairs could possible have occurred?

I know what typical curves are purported to look like. Most don't
question the *exact* details. Most don't have the equipment or the
desire to go and measure them accurately.

The curves I do see (e.g. http://www.coilws.com/magneticandhow.html)
show that the cats claw shape may well be what is happening. Even
the main minor loop graph (fig.2) in that Chan paper implies that this
is what
is happening. As I said, I don't know what the exact details are, I
certainly admit this lack of knowledge. However, I am very sceptical
when nature has proposed discontinuities. Its an intuitive sort of
thing. I can well envisage a transfer function such that as one goes up
and turns back around again, that the initial down slope is the same as
the up slope. If you go up and turn around very, very slowly, I don't
see that nature will make a step change in slope at the turnaround
point. Sure, maybe something strange is really going on, and that's
always a possibility, but extra-ordinary behaviour require
extra-ordinary proof. Care to provide some?

Your knowledge
to opinion ratio is not positive definite.

Get real. Again, this simply won't wash. All you do is show that chip on
your shoulder. Its pretty obvious to anyone that I have significant and
useful
knowledge. I certainly would not believe that you are completely
clueless just because you have some omissions in your own knowledge. No
one knows it all, but such lack does not imply anything remotely
approaching a "negative K/O ratio". This is simply kindergarten name
calling. As I said, you need to grow up a bit.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Kevin Aylward]

Kevin Aylward wrote:

Mike Engelhardt wrote:
Kevin,


I agree, analogue seems to have a pretty good handle on the features
of the model. But your implication here is that I am also lacking such
basic knowledge of the method, despite the fact that I already posted
graphs (http://www.anasoft.co.uk/ssbhtest.gif) showing that I have
actually implemented the essentials of the method for all loops. The
*only* issue I have currently, is the very small discontinuity when
used in an inductor.

Oh... dear I made a mistake here. I no longer have a main current issue
as noted. I discovered a minor error in my code that caused the
glitches. It was simply two minus signs in error that caused an
initialisation variable to be incorrect for some specific loop
trajectories. This resulted in the average loop being entered at the
wrong time. I now have smooth voltage and current waveforms (both
against time and current against voltage) that appear to match the
LTSpice ones. The, err...discrepancy... as sods law dictates, is that
the current magnitudes disagree by a factor of about two... oh well.

Now to figure out the air gap...

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

Oh.. Like, so you have a mathematical disproof of my claim that the
intersection of the B_- loops and the average curve, can not have equal
slopes.

Vacuous claims are cheap dude, present your actual evidence. Come on
now...prove to us all that the B_- loops and the average curve intersect
with the same derivative.

Stupid, I never said they do. There's no physical law that says inductance
has to be continuous, otherwise ferromagnetism won't exist, it'd be too
hard to make those football shaped minor hysteresis loops meet at a point
coming from two different directions. The error of your nonsense is thinking
that inductance has to be continuous. It's the flux you want continuous.

You really don't have a grasp on either the physics or electronics of
this. Plus, you're trying to revert to nonsense math proofs when it's already
been establish by many people that your treatise is wrong.

--Mike

 

[Mike Engelhardt]

Kevin,

Oh... dear I made a mistake here. I no longer have a main
current issue as noted. I discovered a minor error in my
code that caused the glitches. It was simply two minus
signs in error that caused an initialisation variable to be
incorrect for some specific loop trajectories. This resulted
in the average loop being entered at the wrong time. I now
have smooth voltage and current waveforms (both against time
and current against voltage) that appear to match the LTSpice
ones. The, err...discrepancy... as sods law dictates, is that
the current magnitudes disagree by a factor of about two...
oh well.

The point is that inductance can be discontinuous, but the flux
can not. There's no physical law that says inductance has to
be continuous, otherwise ferromagnetism won't exist, it'd be too
hard to make those football shaped minor hysteresis loops meet
at a point coming from two different directions. Chan's model
removes flux discontinuities of implementations of previous work
and gives a computationally lightweight manner to model
ferromagnetism with just three parameters from the BH curves.

Sorry to have offended you in the process, but you started off
with false assertion(that LTspice didn't implement the standard
equations in Chan's paper) with another false assertion(that the
inductance has to be continuous) with rubbish math equations that
further missed the point. Combined empty contradiction of well
established advice I give when to try to simulate nonlinear
inductors or not. It just a total heap of rubbish.

Now to figure out the air gap...

That will gloss over the discontinuities to some extent. But
you can still see them if you zoom in on the example posted
here or in LTspice's help pages.

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

Oh... dear I made a mistake here. I no longer have a main
current issue as noted. I discovered a minor error in my
code that caused the glitches. It was simply two minus
signs in error that caused an initialisation variable to be
incorrect for some specific loop trajectories. This resulted
in the average loop being entered at the wrong time. I now
have smooth voltage and current waveforms (both against time
and current against voltage) that appear to match the LTSpice
ones. The, err...discrepancy... as sods law dictates, is that
the current magnitudes disagree by a factor of about two...
oh well.

The point is that inductance can be discontinuous, but the flux
can not. There's no physical law that says inductance has to
be continuous, otherwise ferromagnetism won't exist,

I agree that there is probably no physical law that says inductance
*must* be continuous. However, true discontinuities don't crop up in
physics much, excluding QM.

it'd be too
hard to make those football shaped minor hysteresis loops meet
at a point coming from two different directions.

Indeed.

Chan's model
removes flux discontinuities of implementations of previous work
and gives a computationally lightweight manner to model
ferromagnetism with just three parameters from the BH curves.

Sorry to have offended you in the process, but you started off
with false assertion(that LTspice didn't implement the standard
equations in Chan's paper) with another false assertion(that the
inductance has to be continuous)

Nope. I made an inquiry as to why LTSpice was apparently giving
erroneous results. I requested clarification on the point.

with rubbish math equations that

Ho hum... The equations I posted were standard, well known equations,
which you obviosly don't understand.

As usual, your "blah...blah...blah.. its rubbish" approach shows
abundantly clear that you have no idea what's going on. You have simply
implemented something in ignorance.

For the 3rd time, post your mathematical refutation or shut the f'up
about on this point. Your only embarrassing yourself. SHOW ME A PROOF AS
TO WHY A DISCONTINEOUS INDUCTANCE DOES NOT NECESSARILLY RESULT IN A STEP
IN VOLTS OR CURRENT. You can make simple assertions all you like, but it
proves nothing. Maybe there is way, but have no idea why if so.

further missed the point. Combined empty contradiction of well
established advice

Leave it out mate. Now your blathering.

I give when to try to simulate non-linear inductors or not.

Oh dear, your in fantasy land again. I don't recall giving any advice as
to when to simulate non-linear inductors. I do remeber posting:

{snip advice from a software engineer on designing analogue electronics}

Just where would this supposed advice of mine be?

It just a total heap of rubbish.

Which you seem quite unable to refute by any actual argument whatsoever.
Just admit it, your clueless about the math. You just been told
something that you parrot off ad-infinitem.

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

Oh... dear I made a mistake here. I no longer have
a main current issue as noted. I discovered a minor
error in my code that caused the glitches.

You were doing better when you simply realized
you made a mistake in interpreting how it works
and tried to be man about admitting it.

Anyway, since I don't seem to be able to
get through to you, why not study the help
documentation and references. Don't
forget you can try out a working example of
all this in LTspice, where I certainly did
understand the physics, electronics, and
math well enough to implement it from
scrach, if that could possilby be an indication
of anything. BTW, it got implemented pretty
fast, too. The thread started on 4/4/04 and
LTspice's nonlinear model was released in
response on 4/7/04 response. You've already
wasted two days. I didn't even have to insult
John Chan et al. or any others I've never met.

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

Oh... dear I made a mistake here. I no longer have
a main current issue as noted. I discovered a minor
error in my code that caused the glitches.

You were doing better when you simply realized
you made a mistake in interpreting how it works
and tried to be man about admitting it.

This makes no sense, as despite any discussions here, my implementation
of the code is still the same as it was from square one. I simple had a
missing minus sign that caused an error for low H, on some loops. Sure,
I had some initial trouble understanding the theory in complete detail,
but this made no difference whatsoever in writing the code. My loop
traversing code works, and is independent of any theory as to why.

Anyway, since I don't seem to be able to
get through to you, why not study the help
documentation and references.

Its not relevant now, as my code works. I could care less as to why. As
I have stated many times, this software bit is just a sideline.

Don't
forget you can try out a working example of
all this in LTspice,

Indeed. I use LTSpice as a check on my own work quite a bit.

where I certainly did
understand the physics, electronics, and
math well enough to implement it from
scrach, if that could possilby be an indication
of anything.

Not really. As I have explained, my own code now works perfectly, and
none of it has been in response to any discussions here, or any of my
electronics or physics knowedge.

There is no requirement to *understand* any of the physics or
electronics details of the model at all. The only science needed to know
is geometry in order to calculate the turning points, e.g. with a
quadratic formula. Its sums and code. Nothing more.

However...

There is a still a small issue. I have a test circuit (see below). It
shows the initial fast ramp, flattened main curve and the ramp up as
saturation occurs.

The inductor spec in SS is:

Hc=1 Br=250m Bs=300m a=1 lm=1 n=14 lg=0

However, to get a match in LTSpice it needs:

Hc=1 Br=283m Bs=300m a=1 lm=1 n=14 lg=0

That is, a 1.136 discrepancy in Br. (or could be Bs)

And I mean a good match. All measured points on the LT graph and the SS
graph match up well enough to conclude that both of the implementations
themselves are esentially correct with regard to the basic formula, so
there is something strange going on.

Do you have some sort of nominal scaling factor, maybe temperature? have
you checked your scaling with other implementations. Of hand, I can't
see anything in my code that would account for this. Its essentially, a
verbatim copy of the formulas, and a staright gain error would not
explian it.

BTW, it got implemented pretty
fast, too.

I agree, you are a fast worker. Do you perform sex in the same manner?

The thread started on 4/4/04 and
LTspice's nonlinear model was released in
response on 4/7/04 response. You've already
wasted two days.

So, what's a few days. Anyway, I bet you had looked at this before, as
how come you got the idea in the first place? Its was totally new to me.


*******
Version 4
SHEET 1 880 680
WIRE -208 144 -352 144
WIRE -128 144 -48 144
WIRE -48 144 -48 176
WIRE -48 256 -48 288
WIRE -48 288 -224 288
WIRE -352 288 -352 224
WIRE -224 288 -352 288
FLAG -224 288 0
SYMBOL ind -64 160 R0
SYMATTR InstName L1
SYMATTR Value Hc=1 Br=283m Bs=300m a=1 lm=1 n=14 lg=0
SYMATTR SpiceLine Cpar=1u
SYMBOL res -112 128 R90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R1
SYMATTR Value 1m
SYMBOL voltage -352 128 R0
WINDOW 3 24 104 Invisible 0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR Value PULSE(0 1 0 1m 1m 4 10000)
SYMATTR InstName V1
TEXT -352 368 Left 0 !.probe
TEXT -352 408 Left 0 !.tran 0 4 0 1m
**************

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

Oh... dear I made a mistake here. I no longer have
a main current issue as noted. I discovered a minor
error in my code that caused the glitches.

You were doing better when you simply realized
you made a mistake in interpreting how it works
and tried to be man about admitting it.

My loop traversing code works, and is independent of
any theory as to why. Its not relevant now, as my
code works. I could care less as to why.

Eh, so which way is it going to be? A mathematical
proof that the method doesn't work or empirical evidence
that is does? No fair looking at real B-H minor loops
for guiding evidence here or working simulation examples.
That would make too much sense.

Anyway, since I don't seem to be able to
get through to you, why not study the help
documentation and references. Don't
forget you can try out a working example of
all this in LTspice, where I certainly did
understand the physics, electronics, and
math well enough to implement it from
scratch, if that could possilby be an indication
of anything.

Not really. As I have explained, my own code now works
perfectly, and none of it has been in response to any
discussions here, or any of my electronics or physics
knowedge. There is no requirement to *understand* any
of the physics or electronics details of the model at
all.

Amazing. Implementing something like this with no
knowledge. Fascinating. See, I would not have been
able to do that. Maybe that's because I didn't have
a trusted working example in simulation before I wrote
it.

However...

There is a still a small issue. I have a test circuit
... lg=0 ...
That is, a 1.136 discrepancy in Br. (or could be Bs)

Hard to say what the problem is. Since this is the
comparatively trivial ungapped case, maybe you aren't
integrating the differential equations correctly. The
xspice/spice3f5 integrator needs a bit of work for this
puppy. Those use a single integrator for every reactance,
I used my experience in writing about 18 new integrators
for other two terminal reactances in LTspice to write a
19th for the Chan model. Maybe that has someting to
do with it. Could be.

Do you have some sort of nominal scaling factor,
maybe temperature?

Shouldn't be the problem, but temperature scaling is
implemented in LTspice's nonlinear inductor. See the
original paper or LTspice help for how Hc, Bs, and Br
scale with T.

So, what's a few days.

Depends how much time you spend insulting those
who have done prior work in the field, making multiple
false assertions, and otherwise generally making an ass
of yourself. Your knowledge to opinion ratio sucked.

Anyway, I bet you had looked at this before,

I was familiar with the existence and significance of
the paper from general familiarity with the field, but
hadn't implemented it nor trusted prior implementations
because I was aware of some problems in how it hadn't
been done correctly in at least one commercial
SPICE program. I never delved into it before because
nonlinear inductors aren't important for most simulation
purposes. More often than not one should just use a
linear inductor, do the simulation, and then check if the
inductor went into saturation. For most things that seems
to be better design methodology. SPICE programs
typically don't offer much more and people design
SMPS's in SPICE with such alarming regularity. BTW,
appended is a nonlinear inductor working in a SMPS.
You can see the thing go into staturation while it starts
up. The breakdown's pretty sharp here, it would have
been easier to have run the linear inductor case and
then seen the peak current that is required for the
inductor to handle. In the nonlinear simulation, you
see it's saturating, but don't know the peak current
the inductor has to handle because it did saturate.

as how come you got the idea in the first place?
Its was totally new to me.

Google.

--Mike

--- SMPS.asc ---
Version 4
SHEET 1 3000 1528
WIRE 928 1280 928 1264
WIRE 2192 1424 2192 1360
WIRE 2384 1424 2384 1296
WIRE 2288 1424 2288 1296
WIRE 1968 912 1968 880
WIRE 1728 1232 1728 1200
WIRE 1008 1408 1008 1392
WIRE 1072 1056 1008 1056
WIRE 2112 1088 2112 1328
WIRE 2096 1088 2112 1088
WIRE 2192 1088 2112 1088
WIRE 2192 1168 2192 1088
WIRE 2288 1088 2192 1088
WIRE 2288 1232 2288 1088
WIRE 2384 1088 2288 1088
WIRE 2384 1216 2384 1088
WIRE 1152 848 1152 768
WIRE 1728 912 1728 768
WIRE 1968 768 1728 768
WIRE 1968 800 1968 768
WIRE 1056 1184 1072 1184
WIRE 1680 1184 1520 1184
WIRE 1680 992 1520 992
WIRE 928 1184 992 1184
WIRE 2000 1088 2000 1264
WIRE 1904 1088 2000 1088
WIRE 2016 1088 2000 1088
WIRE 2144 1392 1520 1392
WIRE 2144 1264 2144 1392
WIRE 2192 1264 2144 1264
WIRE 2192 1280 2192 1264
WIRE 2192 1248 2192 1264
WIRE 1728 1088 1728 1008
WIRE 1728 1104 1728 1088
WIRE 1824 1088 1728 1088
WIRE 1552 1088 1520 1088
WIRE 1408 1488 1408 1456
WIRE 1184 1488 1184 1456
WIRE 1440 848 1440 816
WIRE 1440 816 1552 816
WIRE 1552 816 1552 848
WIRE 1552 912 1552 928
WIRE 1552 928 1520 928
WIRE 1552 1072 1552 1088
WIRE 1552 1008 1552 928
WIRE 1552 1088 1728 1088
WIRE 1152 768 1728 768
WIRE 1520 1264 2000 1264
WIRE 1520 1328 2112 1328
WIRE 1296 848 1296 816
WIRE 1072 928 1040 928
WIRE 1648 816 1552 816
WIRE 1072 1312 1008 1312
WIRE 1008 1312 1008 1328
WIRE 944 1056 928 1056
WIRE 1648 896 1648 880
FLAG 928 1280 GND
FLAG 928 1056 GND
FLAG 2192 1424 GND
FLAG 2384 1424 GND
FLAG 2288 1424 GND
FLAG 1968 912 GND
FLAG 1728 1232 GND
FLAG 1008 1408 GND
FLAG 1648 896 GND
FLAG 1408 1488 GND
FLAG 1184 1488 GND
SYMBOL res 912 1168 R0
SYMATTR InstName R2
SYMATTR Value 10K
SYMBOL res 2176 1152 R0
SYMATTR InstName R3
SYMATTR Value 20K
SYMBOL res 2176 1264 R0
SYMATTR InstName R4
SYMATTR Value 20K
SYMBOL res 2000 1072 M90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R1
SYMATTR Value .006
SYMBOL cap 1536 1072 M180
WINDOW 0 24 64 Left 0
WINDOW 3 24 8 Left 0
SYMATTR InstName C5
SYMATTR Value .22ľ
SYMBOL cap 1056 1168 R90
WINDOW 0 0 32 VBottom 0
WINDOW 3 32 32 VTop 0
SYMATTR InstName C4
SYMATTR Value 330p
SYMBOL cap 992 1328 R0
SYMATTR InstName C2
SYMATTR Value 43p
SYMBOL cap 1008 1040 R90
WINDOW 3 32 32 VTop 0
WINDOW 0 0 32 VBottom 0
SYMATTR Value .0001ľ
SYMATTR InstName C3
SYMBOL cap 2272 1232 R0
WINDOW 39 24 100 Left 0
SYMATTR SpiceLine x4
SYMATTR InstName C6
SYMATTR Value 180ľ
SYMBOL nmos 1680 912 R0
SYMATTR InstName M1
SYMATTR Value FDS6680A
SYMBOL nmos 1680 1104 R0
WINDOW 0 -1 17 Right 0
WINDOW 3 38 105 Right 0
SYMATTR InstName M2
SYMATTR Value FDS6680A
SYMBOL voltage 1968 784 R0
SYMATTR InstName V1
SYMATTR Value 5
SYMBOL polcap 1632 816 R0
WINDOW 3 25 56 Left 0
SYMATTR Value 4.7ľ
SYMATTR InstName C7
SYMBOL schottky 1536 848 R0
SYMATTR InstName D1
SYMATTR Value 1N5818
SYMBOL res 2368 1200 R0
SYMATTR InstName R5
SYMATTR Value .5
SYMBOL PowerProducts\\LTC1735 1296 1120 R0
WINDOW 0 -1 -149 Center 0
SYMATTR InstName U1
SYMBOL ind 1808 1104 R270
WINDOW 123 -49 49 VBottom 0
WINDOW 39 -22 52 VBottom 0
WINDOW 40 -79 52 VBottom 0
WINDOW 0 32 56 VTop 0
WINDOW 3 5 56 VBottom 0
SYMATTR Value2 A=5u Lm=2m
SYMATTR SpiceLine Lg=.11m N=5
SYMATTR SpiceLine2 Rser=10m Rpar=1K
SYMATTR InstName L1
SYMATTR Value Hc=16 Bs=.44 Br=.1
TEXT 1640 1440 Left 0 !..tran 1 startup steady nodiscard

 

[Terry Given]

"Mike Engelhardt" <pmte@concentric.net> wrote in message
news:c76b79$fhu@dispatch.concentric.net...

Kevin,

[snip]
I was familiar with the existence and significance of
the paper from general familiarity with the field, but
hadn't implemented it nor trusted prior implementations
because I was aware of some problems in how it hadn't
been done correctly in at least one commercial
SPICE program. I never delved into it before because
nonlinear inductors aren't important for most simulation
purposes. More often than not one should just use a
linear inductor, do the simulation, and then check if the
inductor went into saturation. For most things that seems
to be better design methodology. SPICE programs
typically don't offer much more and people design
SMPS's in SPICE with such alarming regularity. BTW,
appended is a nonlinear inductor working in a SMPS.
You can see the thing go into staturation while it starts
up. The breakdown's pretty sharp here, it would have
been easier to have run the linear inductor case and
then seen the peak current that is required for the
inductor to handle. In the nonlinear simulation, you
see it's saturating, but don't know the peak current
the inductor has to handle because it did saturate.

I would argue that a good nonlinear model is well worth using, and even a
bad non-linear model too. Startup (and shutdown) tend to be the areas where
problems arise, and also are ignored by many engineers. Unless inrush
limiting is employed, LC filter response to startup is governed by the
inductor's non-linearity. If you rely on a linear model, you'll very likely
underestimate the peak input current by an order of magnitude or more.

I normally do my basic design with linear (often ideal) components. Then,
when its all running OK, add in the non-linear inductors and start to give
the circuit a hard time.

If you also apply the "people are stupid" theory (which states that, on
average, most people are stupid) then they will be too dumb to remember to
check the peak current. A nonlinear model that saturates will at least let
them know there is a problem.

cheers
terry

 

[Mike Engelhardt]

Terry,

Thanks for the interest.

I would argue that a good nonlinear model is well worth
using

Well, buy popular demand, LTspice has one. Let's hope
it's not just a case of giving people enough rope to
hang themselves.

Startup (and shutdown) tend to be the areas where
problems arise, and also are ignored by many engineers.
...If you rely on a linear model, you'll very likely
underestimate the peak input current by an order of
magnitude or more

Sure. That example I posted has a start up issue. However,
for that SMPS, it has a soft-start, so the design question
is what is the peak current. The linear inductor would
let you find that for the non-saturating inductor and then
you could finish the practical circuit by picking an
inductor that has enough head room to handle production
scatter and temperature. For me, it's exactly the
information I want. If the inductor saturates in the
simulation, that just tells me I need a different inductor,
not which one.

A nonlinear model that saturates will at least let
them know there is a problem.

Sure, but there's a very serious potential pitfall. Macro-
models of the SMPS controller often to usually exhibit
typical performance at room temperature. So if someone
designs the power supply by swapping out inductors until
one finds the smallest one that doesn't saturate, then that
power supply design will fail *each* and *every* single
time over production scatter and temperature. The issue
is that saturation flux density goes down monotonically
with temperature. It's a fundamental property of all
ferromagnetic material. So again, you need to use the
linear inductor to find the peak current, apply production
scatter, and then pick an inductor with enough headroom
over temperature. It's really an analysis you should do
yourself and not rely on the simulator to do for you in
my opinion and experience. So while LTspice has now has
a good nonlinear model you can use, if you want to do
something like design a SMPS, I really recommend
analytically dealing with the saturation current rating
of the supply's primary inductor that is used for the
actual power conversion.

But yes, for your input EMI filter, a nonlinear model
in simulation has value there, especially if the SMPS
controller doesn't do/have soft-start, because it's
probably okay for it to saturate for a few milliseconds
so it's nice to give the supply a plausible input
test vector.

--Mike

 

[Terry Given]

"Mike Engelhardt" <pmte@concentric.net> wrote in message
news:c76u6d$fhv@dispatch.concentric.net...

Terry,

Thanks for the interest.

I would argue that a good nonlinear model is well worth
using

Well, buy popular demand, LTspice has one. Let's hope
it's not just a case of giving people enough rope to
hang themselves.

Alas, spice aint a panacaea for understanding. LTSpice is pretty neat
though.

Startup (and shutdown) tend to be the areas where
problems arise, and also are ignored by many engineers.
...If you rely on a linear model, you'll very likely
underestimate the peak input current by an order of
magnitude or more

Sure. That example I posted has a start up issue. However,
for that SMPS, it has a soft-start, so the design question
is what is the peak current. The linear inductor would
let you find that for the non-saturating inductor and then
you could finish the practical circuit by picking an
inductor that has enough head room to handle production
scatter and temperature. For me, it's exactly the
information I want. If the inductor saturates in the
simulation, that just tells me I need a different inductor,
not which one.

A nonlinear model that saturates will at least let
them know there is a problem.

Sure, but there's a very serious potential pitfall. Macro-
models of the SMPS controller often to usually exhibit
typical performance at room temperature. So if someone
designs the power supply by swapping out inductors until
one finds the smallest one that doesn't saturate, then that
power supply design will fail *each* and *every* single
time over production scatter and temperature.

Hooray, someone who understands this!! The three T's - Time, Temperature and
Tolerance.....if its an iron powder inductor, look at how it ages too.

The issue
is that saturation flux density goes down monotonically
with temperature. It's a fundamental property of all
ferromagnetic material.

I once re-designed a "faulty" flyback transfomer (3C85) with a peak flux
density of about 370mT. They worked when cold, but all failed at 70 degrees
C. It was a battery charger, and a dead battery with a couple of shorted
cells would force the charger to run for a long time at high current,
raising xfmr temp, then BOOM! A belly-band to reduce flux leakage also
raised the temp enough to kill it under load.

the same designer was responsible for a current xfmr in a 1.5kW full bridge
where the copper loss in the 1T sense winding was enough to raise the
ferrite past its 140C curie point, causing it to saturate, which forced the
CM controller to crank up the duty cycle to max and ignore the output
current - BOOM!

So again, you need to use the
linear inductor to find the peak current, apply production
scatter, and then pick an inductor with enough headroom
over temperature. It's really an analysis you should do
yourself and not rely on the simulator to do for you in
my opinion and experience. So while LTspice has now has
a good nonlinear model you can use, if you want to do
something like design a SMPS, I really recommend
analytically dealing with the saturation current rating
of the supply's primary inductor that is used for the
actual power conversion.

good call. I've done quite a few rework jobs, and one of the first things I
check is the saturation current of the various magnetic devices.

But yes, for your input EMI filter, a nonlinear model
in simulation has value there, especially if the SMPS
controller doesn't do/have soft-start, because it's
probably okay for it to saturate for a few milliseconds
so it's nice to give the supply a plausible input
test vector.

--Mike

cheers
Terry

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,



Anyway, since I don't seem to be able to
get through to you, why not study the help
documentation and references. Don't
forget you can try out a working example of
all this in LTspice, where I certainly did
understand the physics, electronics, and
math well enough to implement it from
scratch, if that could possilby be an indication
of anything.

Not really. As I have explained, my own code now works
perfectly, and none of it has been in response to any
discussions here, or any of my electronics or physics
knowedge. There is no requirement to *understand* any
of the physics or electronics details of the model at
all.

Amazing. Implementing something like this with no
knowledge. Fascinating. See, I would not have been
able to do that.

I said I didn't *use* any of my electronics or physics knowledge for
that part of the problem. If you used such knowledge, ignoring the air
gap as I agree this requires some basic physics, please explain that
piece of such knowledge that you actually used to implement the
equations.

Maybe that's because I didn't have
a trusted working example in simulation before I wrote
it.

Well, we don't know if yours is trusted yet. Most of your work has been
on improving on existing results that you can compare with. This new mag
stuff is unchecked, so you could have some discrepancies.

However...

There is a still a small issue. I have a test circuit
... lg=0 ...
That is, a 1.136 discrepancy in Br. (or could be Bs)

Hard to say what the problem is. Since this is the

comparatively trivial ungapped case,

Which should be of more concern. One has to walk befor one can run.

maybe you aren't
integrating the differential equations correctly.

Like, I have modified the spice integrate code?. Right on. I only change
things I have to.

Its a discrepancy that I think should be accounted for. I can post both
graphs so your can see that they are the same. I haven't made the same
mistake twice.

The
xspice/spice3f5 integrator needs a bit of work for this
puppy.

It seems to get by. I have checked it with a few examples. There are
some conditions where it has a convergence problem, but overall, it
seems basically ok.

Those use a single integrator for every reactance,
I used my experience in writing about 18 new integrators
for other two terminal reactances in LTspice to write a
19th for the Chan model. Maybe that has someting to
do with it. Could be.

Could be. If the parameters are identical, the LT peak at 4 seconds is
about 2.5 times larger, the mid range remains about the same, with the
initial range low by around a facter of two.

XSpice builds a magnetic device in two steps, in a .subckt. It has an
L_couple and a Core. The L_couple does the inductance bit by presenting
two terminals to the outside world. It has an output (mmf=I.NTurns) upon
which the Core is loaded. The core is nothing more than a non-linear
resister, and can have any transfer function you like. I have not looked
much at the L_couple code, but is just a few lines calling the main
cm_analogue_integrate() routine. I would be very surprised if there is a
problem here as it would imply that the whole of XSpice is incorrect, as
it uses the same integrator for everything.

You should see this as an opportunity for evaluating you own code as
much as I use yours for evaluating mine. You may not like it, especially
as I am just a hack code wise, but spice is relatively specialised,
maybe < 1% of EE's have any significant knowledge of it at all, such
that it is quite hard to get any *independent* checks of ones own work.
I would seem to be your best option on this

"When asking for advice, one is usually looking for an accomplice"

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.

 

[Mike Engelhardt]

Kevin,

You should see this as an opportunity for evaluating you
own code as much as I use yours for evaluating mine. You
may not like it, especially as I am just a hack code wise,
but spice is relatively specialised, maybe < 1% of EE's
have any significant knowledge of it at all, such that
it is quite hard to get any *independent* checks of ones
own work. I would seem to be your best option on this

Good point, thanks, I'll keep that option in mind. Now I
see I've been wasting my time/money using my full PSpice
9.2.3, and PSpice 10.0.0 as well as my hspice licenses and
some specialty simulators for LTspice checks. That's the
trouble with conservative physics types like me. I
shouldn't have also implemented the diagnostics that allow
*verification* of LTspice's Chan model implementation but
be comparing the implementation to the behavior of an
implementation from the guy who BOTH proves that it
mathematically isn't possible AND implements it, which goes
to totally prove he really knows what he's doing both ways.

Heck, this probably exposes an even a larger problem in society.
It's probably at the root of why physics or technology never
seems to advance fast enough -- at least not as fast as in the
science fiction novels. They don't calibrate their instruments
with the equipment from source insisting that things like
Maxwell's equations have it all wrong.

Thanks again for the tip. We're onto a constructive
relationship now.

Best Regards,

--Mike

 

[Kevin Aylward]

Mike Engelhardt wrote:

Kevin,

You should see this as an opportunity for evaluating you
own code as much as I use yours for evaluating mine. You
may not like it, especially as I am just a hack code wise,
but spice is relatively specialised, maybe < 1% of EE's
have any significant knowledge of it at all, such that
it is quite hard to get any *independent* checks of ones
own work. I would seem to be your best option on this

Good point, thanks, I'll keep that option in mind. Now I
see I've been wasting my time/money using my full PSpice
9.2.3, and PSpice 10.0.0 as well as my hspice licenses

Non of these, to my knowledge, support this particular model.

and

some specialty simulators for LTspice checks.
That's the
trouble with conservative physics types

Ahmmm...

like me. I
shouldn't have also implemented the diagnostics that allow
*verification* of LTspice's Chan model implementation but
be comparing the implementation to the behavior of an
implementation from the guy who BOTH proves that it
mathematically isn't possible AND implements it, which goes
to totally prove he really knows what he's doing both ways.

Indeed.

It still looks like there is a discrepancy in the dynamic behaviour of
the model though. Maybe there is an issue with the xspice integration,
maybe there is not.

Heck, this probably exposes an even a larger problem in society.
It's probably at the root of why physics or technology never
seems to advance fast enough -- at least not as fast as in the
science fiction novels. They don't calibrate their instruments
with the equipment from source
insisting that things like
Maxwell's equations have it all wrong.

Maxwell's equations are wrong. This was conclusively proved by the photo
electric effect around the early 1920's.

Best Regards,

Kevin Aylward
salesEXTRACT@anasoft.co.uk
http://www.anasoft.co.uk
SuperSpice, a very affordable Mixed-Mode
Windows Simulator with Schematic Capture,
Waveform Display, FFT's and Filter Design.