This directory contains files of questions and answers from users

memory1     -   A problem running out of memory on a seemingly small problem

partial_inductance  -  A confusion about partial inductance?

uh_oh          We get a multitude of messages:  uh oh, segs don't seem parallel

current_dist   Ground Plane current distribution problem

images         A question about modeling image current

3d_curr_dist   These people want more than just ground plane current distrib.




          Running out of memory on a small problem

Questions are prefaced with  ">"

>I have this geometry which I was able to
>solve successfully with FastHenry using a 7x7 discretization of the
>line conductors. But when I changed the discretization to 9x9, I
>got a segmentation fault. Would you be interested in examining the
>problem? I have attached the input file to the bottom of this message.
>I would appreciate any assistance you could provide. Thank
>you in advance.

I'm not sure why you got a segmentation fault, but 
I suspect this was caused by a memory problem since it seemed to
run fine on our machines.  

But certainly, Fasthenry should be able to handle such a small problem.  
Here is an explanation of what is going on.


The long winded explanation:

You may say 3000 filaments is not a large problem for the multipole
algorithm, but in order for the multipole algorithm to be efficient in
execution time and memory, it must be able to divide space into a grid
of small enough cubes such that no given cube containing more than a
small number of filaments.  In addition, for the multipole expansions
to be valid, no filament can be larger than the cube it is contained
in.

This presents a problem for long conductors which are finely
discretized, such as 9x9.  In this case, from fasthenry's output, you
can see that it only decended 3 partitioning levels, which means it
divided the domain into an 8x8x8 grid of cubes.  This is not very fine
and the few cubes toward the center of your geometry will contain most
of the filaments.  The multipole algorithm would have liked to go down
many more levels, however in going down to level 4, many of the filaments
would have been longer than the cube.  In order to descend, the
filaments would have to be cut in half, but this would nearly double
the number of filaments.  In this case, FastHenry decided the extra
cost to compute approximations for the added filaments would be more
expensive than descending a level so it stopped at level 3.

So now, since a small set of cubes contain most of the filaments, the
multipole algorithm isn't really being used and much of the problem is
being solved with direct matrix-vector products. This is inefficient
in time and memory but not unbearable (65MB).  What is really killing
you is actually the space required to form the default (cubeL)
preconditioner.  The preconditioner inverts a sparsified version of
the system, but it bases it's sparsification on the multipole cubes.
So it is forming and factoring a large part of the problem and there
is a lot of fill-in.  This consumes a lot of memory and takes a long
time to factor.  (around 100MB!)



Cure #1:

Use a preconditioner that is not so expensive in memory.  
I ran it with 

fasthenry yipw-bug -psegm

and it was much faster and the preconditioner only consumbed 20MB.



Cure #2:

Instead of increasing the number of filaments from 7x7 to 9x9,
consider changing the rh and rw values.  The "Discretization Error
Analysis" section of the manual describes this in more detail.


Note that the above discretization problem does not arise for ground planes
since the filaments become shorter as the discretization is refined.



>Thank you for your explanation for possible cause of the segmentation fault.Is
>the selection of proper pre-conditioner documented anywhere? I'll also try the
>option -psegm once I am done with using the default.

It's use is talked about a little in the "Discretization Error Analysis"
section, and is described in more detail in my thesis. 




     A confusion about partial inductance?


>Regarding my other question on inductance,I am sorry that I did not explain it
>very well. Let's assume that there is a line conductor over a ground plane.The
>two end points of the line conductor are designated A and B. The point on the
>ground plane directly underneath A is designated C, and that directly underneath
>B is designated D.
>
>In case 1,there is NO electrical connection between the line conductor and the
>ground plane. The port is defined to go from A to B.
>
>In case 2, B is electrically connected to D via the .equiv statement. The port
>is defined to go from A to C.
>
>The two cases would result in slightly different port inductance. If you use the
>flux linkage definition of inductance, it seems that the two cases are
>equivalent. Could you explain the difference in inductance?

Flux linkage doesn't make sense when you don't have a complete loop as
in case 1.  This is where the term 'partial inductance' comes in.  The
inductance from A to B can be thought of as the partial inductance of
the entire loop, A to C.  If you define two ports, A to B and C to D,
then you will get a 2x2 matrix

 Z11  Z12
 Z21  Z22

with Z12 = Z21 

The total loop inductance, Zloop, (case 2), is related to the matrix
(case 1) by:

Zloop = Z11 + Z22 - 2 * Z12   (may be +2 Z12 depending on the port definition)

So there is your relation.  





Question:  On the simple file below, I get the following:

   uh oh, segs don't seem parallel -3.04744e-07

What is it?

Answer:  This warning is an internal warning that doesn't matter in
this case (and rarely appears).
It results from two filaments being almost parallel.
One point of the code considers them parallel, but later, a different
'back up test' thinks they are not.  I probably should have taken
this message out, but never did.  The value can be thought of as (1 - cos(e))
where e is the angle between the filaments.  The routine that calls
this is for computing the mutual inductance between filaments 
which are NOT close together, so treating them as non-parallel is 
even less important.  In the example below, the error occurs
between pairs such as E1 and E6 which are essentially parallel.


This is a n-gon of radius 1 and n= 10
.units m
.default z=0.0
.default h=0.1
.default w=0.1
.default sigma=5e+06
.default nhinc=1
.default nwinc=1
N1 X=1 Y=0
Nend X=1 Y=0
N2 X=0.809017 Y=0.587785
E1 N1 N2
N3 X=0.309017 Y=0.951057
E2 N2 N3
N4 X=-0.309017 Y=0.951057
E3 N3 N4
N5 X=-0.809017 Y=0.587785
E4 N4 N5
N6 X=-1 Y=5.35898e-08
E5 N5 N6
N7 X=-0.809017 Y=-0.587785
E6 N6 N7
N8 X=-0.309017 Y=-0.951056
E7 N7 N8
N9 X=0.309017 Y=-0.951057
E8 N8 N9
N10 X=0.809017 Y=-0.587785
E9 N9 N10
E10 N10 Nend
.external N1 Nend
.freq fmin=1 fmax=1e10 ndec=1
.end


unix% fasthenry circ.inp -l0 -mdirect 

Running FastHenry 2.0 (15Aug94)
  Date: Sun Dec 11 15:55:11 1994
  Host: lyapunov
Solution technique: ITERATIVE
Matrix vector product method: DIRECT
Preconditioner: ON
Error tolerance: 0.001
Reading from file: ../../ssm/circ/circ.inp
Title:
This is a n-gon of radius 1 and n= 10

all lengths multiplied by 1 to convert to meters
Total number of filaments before multipole refine: 10
Total number of filaments after multipole refine: 10

Multipole Summary
  Expansion order: 2
  Number of partitioning levels: 0
  Total number of filaments: 10
Scanning graph to find fundamental circuits...
Number of Groundplanes : 0 
Number of filaments:         10
Number of segments:          10
Number of nodes:             11
Number of meshes:             1
          ----from tree:                   1 
          ----from planes: (before holes)  0 
Number of conductors:         1   (rows of matrix in Zc.mat) 
Number of columns:            1   (columns of matrix in Zc.mat) 
Number of real nodes:        11
filling M...
filling R and L...
uh oh, segs don't seem parallel -3.04744e-07
uh oh, segs don't seem parallel -3.06595e-07
uh oh, segs don't seem parallel -3.0567e-07
uh oh, segs don't seem parallel -3.0567e-07
uh oh, segs don't seem parallel -3.38095e-07
uh oh, segs don't seem parallel -3.36243e-07
uh oh, segs don't seem parallel -3.37169e-07
uh oh, segs don't seem parallel -3.37169e-07
uh oh, segs don't seem parallel -3.0567e-07
uh oh, segs don't seem parallel -3.7146e-07
uh oh, segs don't seem parallel -3.73312e-07
uh oh, segs don't seem parallel -3.72386e-07
uh oh, segs don't seem parallel -3.72386e-07
uh oh, segs don't seem parallel -2.71378e-07
uh oh, segs don't seem parallel -2.69527e-07
uh oh, segs don't seem parallel -2.70452e-07
uh oh, segs don't seem parallel -2.70452e-07
uh oh, segs don't seem parallel -3.72386e-07
Total Memory allocated: 16 kilobytes
Frequency = 1
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 10
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 100
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1000
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 10000
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 100000
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1e+06
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1e+07
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1e+08
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1e+09
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 
Frequency = 1e+10
multiplying M*(R + jL)*transpose(M)
putting in frequency 
Forming sparse matrix preconditioner..
conductor 0 from node n1
Calling gmres...
1 

All impedance matrices dumped to file Zc.mat

Times:  Read geometry   0.02
        Multipole setup 0
        Scanning graph  0
        Form A M and Z  0.04
        form M'ZM       0
        Form precond    0.01
        GMRES time      0.01
   Total:               0.08





     Current distribution doesn't look right, but when 
       grid1g1 and grid2g1 are switched, it looks ok


>hi, there seems to be a bug in the output current distribution.
>In particular, in the Fasthenry User's Guide, 13 Sep 1994, page 32,
>we need to reverse the order of 'grid2g1' and 'grid1g1' in the
>'quiver...' matlab command, to get reasonable looking current
>distribution.  Please confirm. Thank you very much,
>tpham@aslan.sp.trw.com
>

See the second paragraph of Section 4.1 on page 29.
grid1g1 is for the current in the "seg1" direction which is 
the vector from (x1,y1,z1) to (x2,y2,z2) defined in you input file.  
If this happens to be parallel to the y axis and "seg2" happens to be 
parallel to the x axis, then it makes sense that you will have to
switch them.





           Modeling image current

>As you will see from the FastHenry input file attached, the bondwires are
>actually looping over a conducting plane (the die attach paddle of the
>package). Except in specific cases (not shown) neither end of the bondwires
>touch the plane, they just pass over in making connection between the
>circuit pads and the package leads. However, an opposing image inductor is
>created in the plane which depending on the looping structure will reduce
>the effective partial inductance of the bondwires. I am not sure how to
>model this in FastHenry. The example of the L-trace over a ground plane
>in the documentation is similar, but I am not able to "tie" the nodes
>of the conductor (bondwire) to the plane in my case. Is the way I have it
>defined in my input file correct? Do you have any ideas?

Just the presence of the piece of metal (the plane) will properly
model the image.  I don't really understand why you cut a hole in the
plane in your input file.

For instance, here is the resistance and inductance of a copper ring at 3
frequencies:

Row 1:  n1  to  nend
Col 1: port name: 
Impedance matrix for frequency = 1 1 x 1
     0.0106558  +2.40402e-08j 
Impedance matrix for frequency = 10000 1 x 1
     0.0106558  +0.000240402j 
Impedance matrix for frequency = 1e+08 1 x 1
     0.0106558      +2.40402j 

Now here are the same values for a copper plane underneath the ring
(no connection)

Row 1:  n1  to  nend
Col 1: port name: 
Impedance matrix for frequency = 1 1 x 1
     0.0106558  +2.40232e-08j 
Impedance matrix for frequency = 10000 1 x 1
     0.0106674  +0.000238121j 
Impedance matrix for frequency = 1e+08 1 x 1
     0.0115895      +1.53387j 


As you can see, the presence of the plane decreased the inductance at
high frequency by more than 1/3.  Had the plane been a perfect
conductor, the high freq value would apply at all frequencies (since we are not
modelling frequency effects in the ring).  

Does this answer your question?  

Here is the input file I used.  A 50x50 discretization was probably
an overkill, but it still only took a few minutes to run.
Note, it produces the uh_oh warning described in Q_and_A/uh_oh.

* This is a plane to be placed under circ.inp

.units mm

gunder x1=-3 y1=-3 z1=0.2
+                x2=-3  y2=3  z2=0.2
+                x3=3   y3=3  z3=0.2
+  thick=0.1
+  seg1 = 50  seg2 = 50

*This is a n-gon of radius 1 and n= 10
.units mm
.default z=0.0
.default h=0.1
.default w=0.1
.default nhinc=1
.default nwinc=1
N1 X=1 Y=0
Nend X=1 Y=0
N2 X=0.809017 Y=0.587785
E1 N1 N2
N3 X=0.309017 Y=0.951057
E2 N2 N3
N4 X=-0.309017 Y=0.951057
E3 N3 N4
N5 X=-0.809017 Y=0.587785
E4 N4 N5
N6 X=-1 Y=5.35898e-08
E5 N5 N6
N7 X=-0.809017 Y=-0.587785
E6 N6 N7
N8 X=-0.309017 Y=-0.951056
E7 N7 N8
N9 X=0.309017 Y=-0.951057
E8 N8 N9
N10 X=0.809017 Y=-0.587785
E9 N9 N10
E10 N10 Nend
.external N1 Nend
.freq fmin=1 fmax=1e9 ndec=0.25
.end





        These people want more than just the ground plane current

>	we find the current distribution feature very nice.
>is it possible to see the non-ground plane current flow as well?

Well, I can tell you how to get it.  How you choose to visualize it
is your own matter.  I guess matlab might be able to do 3-d
visualization.

First, in induct.c,  here is where the ground plane stuff is dumped:

      if (opts->dumpMats & GRIDS)
	/* Do stuff to look at groundplane current distribution */
	makegrids(indsys, x0, ext->Yindex, m);

Go inside makegrids in fillM.c and you
will see the vector 'Ib' which is the filament current vector which is
what you want to dump.  You could insert some code to dump this whole
vector.  To dump a vector, look, for instance, at how the right hand
side vector, b, is dumped (also in induct.c) and write something
similar inside makegrids:

       if (opts->dumpMats != OFF)
  	 savecmplx(fb, fname, &b, 1, num_mesh);

Then when you run fasthenry, also specify -dRL and inside matlab, load
RL.mat which will also load a matrix called 'pos' which is a (fils x
3) matrix where pos(i,:) contains the x,y,z coordinates of the first
node of filament i, whose current you know from Ib(i).  (matlab
notation)

I think that is the info you will need.  

Actually, now you have a current associated with a point, but no direction.
In savemats() in induct.c, you could add code where 'pos' is dumped
to dump 'pos2' which would dump the other node associated with
each filament.  Then you would have a vector direction.

If you do anything with this, and want to share, please feel free to
send it to me and I can put it on the ftp site.