Re: [Help-gnucap] more than two taps on an inductor core ...

[Al Davis]

On Friday 08 October 2004 08:43 am, Lars Segerlund wrote:
>  I dodn't get any response on the below mail, so here I am
> again.
>
>  I have three things I would like to do:
>
>  Use more than two coils on a common core, ( it's stated in
> the docs that this wont work ), how hard would an undertaking
> to make this feasible be ?
>
>  Make som sanity checks on the inductors, ( they can stray
> away if not connected properly or something, which never
> happens in real inductors, probably akin to the
> current/voltage sorce internal resistance/power.
>
>  Make it possible to run control code in gnucap, ( either
> gnucap from other code, or other code from gnucap, whichever
> is smost simple ).
>
>  Now, any hints on how hard this would be to implement ?
>
>  ( and preferably a bit of pointers in the right direction
> :-) .... )
>
>  / thanks , Lars Segerlund.
>
>
> On Thu, 12 Aug 2004 21:34:03 +0200
>
> Lars Segerlund <address@hidden> wrote:
> >  Hi,
> >
> >   I am doing some simulations of switched mode power
> > supplies and I need to use more than two taps on a single
> > core ( which the docs say is not suppoerted ).
> >
> >   Is there a way around this or do I have to hack it to
> > work ?
> >
> >   If I have to try to hack it, does anybody have any
> > pointer on a good place to start and some reference
> > litterature ?
> >
> >  / best regards, Lars Segerlund.

Sorry about the delay.    The first one slipped through.

The inductor code is among the oldest.  It must be 20 years old.  
I did that part before I had access to Spice.

It is actually fairly easy to implement in principle, but an 
architectural artifact gets in the way.  

There is a significant difference in the implementation of 
inductors, and therefore mutual inductors, in Gnucap vs. Spice.

In Spice, inductors have an internal node.  You can think of 
inductors as this subcircuit:

.subckt inductor (1 2)
Ra   1 3   1
Rb   1 0   -1
Rc   2 3   -1
Rd   2 0   1
CL   3 0   <inductance>
.ends

Actually, it stamps the whole thing directly without the 
overhead of a subcircuit call.

For mutual inductance, it connects the internal nodes with a 
capacitor with value (k * sqrt(L1 * L2)).

So now a pair of coupled inductors could be:

.subckt two_inductors (1 2 3 4)
Ra1   1 5   1
Rb1   1 0   -1
Rc1   2 5   -1
Rd1   2 0   1
CL1   5 0   <L1>
Ra2   3 6   1
Rb2   3 0   -1
Rc2   4 6   -1
Rd2   4 0   1
CL2   6 0   <L2>
CM    5 6   <(k*sqrt(L1*L2))>
.ends

Although I have shown it as a subcircuit, it isn't really.  The 
internal nodes are global, so the "K" component just connects 
them together,

There is a significant performance hit with this approach.  The 
internal node messes up the matrix.  The matrix for a large RC 
network is positive definite, which allows for optimization in 
the matrix solution.  This is lost the internal node approach.  
You won't notice the difference if there are only a few 
inductors, but you will with something like the RLC network 
that could be extracted from a PC Board layout for signal 
integrity analysis.

Gnucap models simple inductors directly without an internal 
node.  Coupling is done using current controlled current 
sources.

.subckt two_inductors (1 2 3 4)
L1   1 2   <L1*(1-K*K)>
L2   3 4   <L2*(1-K*K)>
F1   1 2 L2   <-K*sqrt(L2/L1)>
F2   3 4 L1   <-K*sqrt(L1/L2)>
.ends

It isn't really a subcircuit like this.  It is really 2 
subcircuits, one for each inductor.  L1 and F1 go together and 
L2 and F2 go together,  There is a performance penalty for the 
subcircuits, which is countered by the incremental update, so 
performance should be fairly good.

I planned to extend this to any number of inductors, but got 
distracted,  Like I said, this was over 20 years ago.  I need 
to look at it again.

There is now a "poly_g" pseudo-component in gnucap, which I 
think I can use for any number of coupled inductors, without 
the subcircuit performance hit.  I need to look at that.

To keep the CCCS approach, and extend it, all of the changes 
would be in DEV_MUTUAL_L::expand() .

I didn't really answer your question yet.  Give me a few days.