IBM Release 1.93 manual

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.