FDTD takes a lot of memory, but being a time-domain thing, it can model time-dependent systems such as photoresist or nonlinear optics. I sort of backed into needing to code my own--I needed an optimizing simulator to design very nonintuitive devices (near-IR metal antennas coupled to
0.25x0.45 micron SOI waveguides), and I couldn't buy one at the time (2004ish).So I took a well-tested FDTD engine, Berkeley Tempest 6.0, for which I had the source, and wrapped it in a giant REXX script that functioned like a math program, geometry generator, and optimizer. It took about three or four months, but it worked great.
Then I ran out of CPU cycles, so I wrote a clusterized FDTD that used the same subset of the TEMPEST syntax that I'd used in the script, and added some cluster-specific stuff. On a 14-core cluster (7 dual Opteron boxes), it ran about 12 times as fast as the uniprocessor version, and more than 20 times faster than TEMPEST on the same hardware. It was nice having TEMPEST to compare with, because that let me do apples-to-apples sanity checks on the same exact simulation. That sped up debugging a lot, I can tell you. The Linux thread scheduler is completely fascist--if you aren't root, you can't even _reduce_ the priority of some of your own threads to indicate which ones are time-critical, and if you are root, making one thread real time priority makes threads in the process real time, and the user interface freezes till the computation is done. Brain dead.
Coding something like that wasn't really in my job description, so I had to do it as a part-time task, but I had a lot of fun doing it.
There's still some obscure bug in the dispersive metal support (metals like copper, silver, and gold, where n < k, i.e. the real part of the dielectric constant is negative). I'll fix it one of these days.
Cheers
Phil Hobbs