Filter
Top Products
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.
81