developerWorks : aW : IBM Electromagnetic Field Solver Suite of Tools : curious PROPCALC warning / EMITPKG vs. ...

duroid

Posts: 16
Registered: May 12, 2008 11:20:27 AM

curious PROPCALC warning / EMITPKG vs. PROPCALC
Posted: Jan 04, 2009 10:51:21 AM

The EIP distribution includes a file WORKSHOP/Workshop_Day_2/meshprop.modl that serves as a demonstration of PROPCALC. I'm currently trying to use PROPCALC for the first time as modeling mesh-like structures explicitly makes EMSURF quite slow.

When I build an input file from the included meshprop.modl and run propcalc, the results seem OK. However, if I add two further conductors (signal lines) to the model (in the "obvious" spots: identical to the two conductors already there, except with y coordinates -0.8...-0.7 and 0.7...0.8) , this warning appears:

This warning appears:

C OR L MATRICES ARE UNBALANCED
                  SUSPECT PROBLEM WITH REFERENCE POINTS OR SHRINK

What does this mean, exactly? Is "SHRINK" a noun here, or a verb? The results seem OK, so perhaps I can ignore this message?

As an aside, I wonder if I am doing the right thing in using PROPCALC. It seems it should do what I want, but at the same time EMITPKG also looks like it should do the right thing. Using EMITPKG, I don't have to model the entire length of the structure I am trying to model, and thus can get away with using just a small piece of explicit mesh structure. Are there any particular advantages or disadvantages to be aware of when deciding between PROPCALC and EMITPKG?

Developer-R

Posts: 10
Registered: May 09, 2008 08:17:54 AM

Re: curious PROPCALC warning / EMITPKG vs. PROPCALC
Posted: Feb 06, 2009 02:19:05 PM

in response to: duroid's post

Reply

The problem you described occurs because, for the initial guess in normalized propagation delay (1.01) one of the four solutions for eigenvalue (modes) did not converge. If you use 1.03 instead, you will find that propcalc gives you the correct solution.

To check for convergence, look at the sub-tables of convergence for the terms NORM. DELAY and EVAL-MAG; proper convergence would be fairly obvious and occur when EVAL-MAG is less than about 1e-3.

The message with SHRINK (facility that no longer exists) will no longer appear.

Please remember that the unit cell you have now constructed has adjacent periodic extensions of the four signal lines--you might consider adjusting your unit cell to be larger in the y direction to include two vacant spaces and so introduce a buffer region to reduce that coupling.

The advantage of propcalc over emitpkg for this structure is that only one unit cell is needed and there is no need for a source region and related extentions and so the structure can be modeled with fewer unknowns. The disadvantage is that the periodic nature of the unit cell (along each direction grid must be uniform) may force the user to adjust the structure accordingly. emitpkg gridding is more relaxed.

duroid

Posts: 16
Registered: May 12, 2008 11:20:27 AM

Re: curious PROPCALC warning / EMITPKG vs. PROPCALC
Posted: Feb 10, 2009 10:28:54 PM

in response to: Developer-R's post

Reply

Thanks - changing the delay guess did get propcalc to converge and the results look reasonable.

Unfortunately, I am still having convergence issues. It seems that, once resistance is added, propcalc's per-signal-line "Initial guess" of Dnorm can result in a situation where the sign of the attenuation alternates each iteration while the delay alternates between values greater and less than 1.

The following propin file demonstrates the problem.

Comment Line for PROPCALC
    0.000080    0.001600    0.000175    3.000000   20.000000   -2.000000
    2   80    5    7    0    0    0    0    200001
  'D'  'F'  'R'  'C'  'C'  'C'  'C'
    1    2    2    1    1    1    1
   0.0000000   0.0000000   0.0000000   0.0000800   0.0016000   0.0001750
   0.0000400   0.0000000   0.0000350   0.0000800   0.0000000   0.0001400
   0.0000400   0.0016000   0.0000350   0.0000800   0.0016000   0.0001400
   0.0000400   0.0000000   0.0000000   0.0000800   0.0016000   0.0000350
   0.0000400   0.0000000   0.0001400   0.0000800   0.0016000   0.0001750
   0.0000000   0.0006600   0.0000700   0.0000800   0.0007000   0.0001050
   0.0000000   0.0007400   0.0000700   0.0000800   0.0007800   0.0001050
   0.0000000   0.0008200   0.0000700   0.0000800   0.0008600   0.0001050
   0.0000000   0.0009000   0.0000700   0.0000800   0.0009400   0.0001050
 0.30000E+01 0.30000E+01 0.30000E+01
 0.00000E+00 0.00000E+00 0.00000E+00
 0.00000E+00 0.00000E+00 0.00000E+00
 0.26000E-07 0.26000E-07 0.26000E-07
 0.26000E-07 0.26000E-07 0.26000E-07
 0.26000E-07 0.26000E-07 0.26000E-07
 0.26000E-07 0.26000E-07 0.26000E-07
    0   25
  0.1050D+01 -0.4000D+00

The first two signal lines will appear to converge rapidly, but the third will run 'forever' (to the 25 iteration limit in this case). The problem appears to be that for the third signal line, the inital guess is:

Initial guess: Dnorm=     0.950629 Atten.=     0.358314

The model file (as an ASCII dump) used to generate this propin was:

# Platform:  FFFFFFF0        Version:  0
# Number of bodies:  9
# All dimensions here are in mm
Body 3  Box (solid)
        0.0000000000    -0.0014000000   0.0003500000
        0.0008000000    -0.0010000000   0.0000000000
   Attribute Material=C: 0.000000026 1
   Attribute Color=Wheat
Body 4  Box (solid)
        0.0000000000    -0.0006000000   0.0003500000
        0.0008000000    -0.0002000000   0.0000000000
   Attribute Material=C: 0.000000026 2
   Attribute Color=Wheat
Body 5  Box (solid)
        0.0000000000    0.0002000000    0.0003500000
        0.0008000000    0.0006000000    0.0000000000
   Attribute Material=C: 0.000000026 3
   Attribute Color=Wheat
Body 6  Box (solid)
        0.0000000000    0.0010000000    0.0003500000
        0.0008000000    0.0014000000    0.0000000000
   Attribute Material=C: 0.000000026 4
   Attribute Color=Wheat
Body 10  Box (solid)
        0.0004000000    -0.008000000    -0.0007000000
        0.0008000000    0.008000000     -0.0003500000
   Attribute Material=R:Cond_grounded 0
   Attribute Color=Wheat
Body 11  Box (solid)
        0.0004000000    -0.008000000    0.0007000000
        0.0008000000    0.008000000     0.0010500000
   Attribute Material=R:Cond_grounded 0
   Attribute Color=Wheat
Body 12  Box (skin)
       0.00040000    -0.00800000     -0.00035
       0.00080000    -0.00800000      0.00070
   Attribute Color=Wheat
   Attribute Material=F:Cond_floating 0
Body 13  Box (skin)
       0.00040000     0.00800000     -0.00035
       0.00080000     0.00800000      0.00070
   Attribute Material=F:Cond_floating 0
   Attribute Color=Wheat
Body 14  Box (solid)
        0.0000000000    -0.008000000    -0.0007000000
        0.0008000000    0.008000000     0.0010500000
   Attribute Material=Unit_cell 3.00
   Attribute Color=Transparent
# Units code: 5 (microns)
# Comment:

Is there any way to disable this "initial guess" feature, and have propcalc always use the initial guess supplied in the propin file? Or am I doing something fundamentally wrong?

Developer-R

Posts: 10
Registered: May 09, 2008 08:17:54 AM

Re: curious PROPCALC warning / EMITPKG vs. PROPCALC
Posted: Feb 14, 2009 09:27:19 AM

in response to: duroid's post

Reply

The issue you raise is valid--skill is often required to find a single guess that will yield converged solutions for all the modes. The eigenvalue search procedure was designed to yield a new guess after each mode is found and would require simple modification to allow it to reuse the initial guess. I suggest work-arounds if you cannot find a suitable guess through intelligent trial and error.

But first, looking at your resistivity, please note that resistance is in ohm-cm and your values suggest you might have thought it to be in ohm-meter.

Second, I suggest that you may have really intended for all conductors (R, F,C) be given resistance, not just the signal lines (as you have done).

Work-arounds:

If you give three of the four signal lines the attribute of F (floating) instead of C (conductor), then the code will search only for a single mode and stop. This way, you can separately search for each mode separately and the initial guess will apply to just that mode. Once you know all four modes, you might be able to find a single guess that leads to the four solutions when all signal conductors are given the C attribute.

Now, if you can find each mode separately but cannot find a suitable guess that yields all four modes, you could capture each mode (propagation constant and modal current distribution) from the output, and then apply the equations 6,7 given in the Rubin, MTT May 1984 paper to find the R, L, and C matrices from these solutions and thus bypass the code for this calculation. However, there may not be sufficient resolution in the printed results for this to work.

You could try find two or three modes at a time (by selectively attributing F to only some of the signal lines) and even alternate which lines are given F and C attribute to generate partial R, L, C matrices; there might be some way to combine these to find the full 4-by-4 matrices, but I am not sure.