Fdtd and Tempest, Tempest patches | IBM Release 1.93 manual

Appendix B.: Configuration

An axiom of programming is that in setting up a new development system, once you can get "Hello, World" to compile, link, and run, you’re most of the way there. With POEMS, the equivalent point is when you have the REXX interpreter working and VIS5D’s demos running in X. If you’re new to FDTD simulation, you may encounter some puzzling behaviour, especially numerical divergences if you try to pack things in too tightly. This appendix is intended to make these things easier.

B.1. FDTD and TEMPEST

B.1.1. tempest patches

a. Floating-point errors FDTD codes in general are highly vulnerable to floating-point errors, e.g. overflow and divide-by-zero. Since the updates to each point depend on the values of all fields at all neighbouring points, if a cell generates a floating-point error condition on step n, all its neighbours will do so on step n+1, and so on. Thus the error propagates throughout the simulation domain at the speed of light, and all information is lost.

Floating point errors can cause exceptions to be generated, in which case TEMPEST will abort. The generation of FP exceptions is controlled by the floating-point control register. If a given exception type (e.g. EM_ZERODIVIDE is masked off, the FP unit will do its best to continue, usually producing an invalid floating point number. IEEE floating-point arithmetic has special values for some of these cases: NaN (not a number) and infinity. The version of TEMPEST supplied with POEMS masks EM_DENORMAL (unnormalized floating- point number, a result too small to be represented properly with full significand precision), EM_UNDERFLOW (values so small they underflow to zero), and EM_INEXACT (the result of the last FP operation was not an exactly representable number).

The main source of FP errors is divergence. Divergences typically result from too-cavalier use of PMLs or monkeying with the time step (you should use the default almost always).

b. Other bugs. Various coding problems, e.g. not bothering to return a value from main() and not rounding object coordinates correctly. The ones I know about are fixed or worked around in the version supplied with POEMS.

c. Increasing MAXORDERSOURCES and MAXPOINTSOURCES. TEMPEST limits us to 1000 plane waves and 100 point sources, which means we can’t build good beams or modefile sources. In this release, these have been increased to 5000 each.

d. Reducing the process priority. Both FIDO/TEMPEST and EMPOST run at reduced priority level (nominally 8 steps and 5 steps below normal, respectively). This is to avoid dragging other, less CPU-intensive tasks down and making the computer less responsive to the user. If you have CPU-intensive programs running at normal or high priority on the same machine as POEMS, your simulations will run very slowly.