compute the actual line width. This is more difficult when the limits are complicated. I
hope that experience will show how important this is in practice.
e. The version of TEMPEST we’re using is a uniprocessor implementation, so it can’t yet be
used with grid computing. POEMS’s own FDTD engine is currently in the alpha stage--it
produces correct simulations using collections of point sources and materials with n>k
(i.e. dielectrics and normal metals at low frequencies). It is multithreaded, supports
multiple processors, and is about 3 times faster than TEMPEST on a 2-processor Xeon
machine. Its speed comes from using two processors, of course, but also from
precomputing a strategy once, then iterating on that (TEMPEST uses a big switch statement
inside its inner loop, effectively computing the strategy each time through). Still to be
implemented are PML materials, dispersive materials, and plane wave sources.
f. Current-density computation is not yet implemented. Voltage can be computed as an
integral of the appropriate E field component over a sufficiently small region.
g. The computation of the Poynting vector is currently just Re{E cross H*} computed on
the array values. TEMPEST, like all other FDTD programs, actually computes E and H on
two interpenetrating lattices, so that the E and H values correspond to positions
staggered by half a step in each direction. Accordingly, computing the Poynting vector
requires interpolating one or the other, so that the two values multiplied together
represent fields at one place. This problem makes the Poynting vector plots in regions of
index discontinuity look as though energy is being created and destroyed in adjacent
boxes straddling material boundaries.
Due to the different updating equations at material boundaries vs. uniform media, getting
the interpolation scheme right is nontrivial. For now, don’t be worried if you see energy
sources and sinks in adjacent cells right at material boundaries.
h. The bitmaps don’t allow annotation, and the axes are always chosen in cyclic order, i.e.
XY plane (Z perpendicular) : +X right, +Y up, +Z out of screen
YZ plane (X perpendicular) : +Y right, +Z up, +X out of screen
ZX plane (Y perpendicular) : +Z right, +X up, +Y out of screen
This way the coordinate system is always right-handed, and the positive-going sense of
the perpendicular direction is always out of the screen towards you.
i. LIST statements don’t work with far field parameters. Given that the far-field bitmaps
are so boring (since propagating orders typically cover 0.5% of the area in k-space), the
LIST statement is likely to be much more useful.
86