I work on the theoretical side of things; I can say that I have in fact touched a beaker and used a pipet to move water from said beaker to another nearly identical beaker (I did this just to feel science-y and say I've done it) but I have no lab experience and would probably destroy everything in your lab if you let me use it. All this to say, though I can sort of describe these materials (whilst gesticulating with a pipe, and with a dreamy glaze over my eyes and lulling drawl to my voice) I -- me -- am incapable of producing them. So if I want to convince someone with a lab and knowledge (and a budget) to actually make them, I have to give more than my impressive pipe-gesticulations.
Hence, I use computer algorithms to make simulational models of the bizarre materials, send some simulated light in to them, and can thus prove to these experimental people with labs that the totally awesome sailing ship I just blew through a smoke ring can in fact be built and sailed through physical rings.
In these simulations, I use the FDTD algorithm, which is somewhat of a standard for electrodynamic simulations. At this point, I take off my purple conical hat, jump genres, put on my cowboy hat, and roll my own C++ code-- that's computational scientist lingo meaning I wrote my own code from scratch and didn't use a commercially-available software (but I did use this book). Because I typed it myself, it is very, very unsophisticated; the commercial codes have adaptive meshes and parameter smoothing and interactive GUIs and all kinds of things I can only dream of because I'd never bother actually understanding or coding them. And due to this unsophistication, my code is prone to errors that people using canned code don't really have to worry about.
Among them, the Courant condition.
But let's skip over that for now, and let me show you how things are supposed to work, when all the myriad buttons and dials in my program are set right. ("Myriad" here means "four")
In the center of the picture below is a cylinder. (It doesn't show up as anything because my code isn't that sophisticated, so I had to put a circle on it myself). This cylinder has an index of refraction of 2; it's opaque, but you could still see something through it. Just visible at the bottom of the screen is an incoming planewave, representing the z-component of the electromagnetic field of the incoming light. It goes up (blue) and down (yellow) like a sine wave. You might think of this as a particular frequency of light from some distant source, such as the sun. It's going to hit the cylinder.
The light on the sides goes around, the light in front of the cylinder bunches up, then some scatters and some is transmitted through the cylinder. The scattered light causes ripples in the front. The transmitted light gets kind of stuck inside, but some of it leaves. Because not all the light is transmitted, there is a shadow behind the cylinder, and this causes a kind of eddying effect behind it. We can keep going and things get more and more muddled, but everything here makes sense.
I saw this, and was thrilled. It works! I made something and it worked!
I then went on to try and simulate an invisibility cloak (yes, really).
With the cloak of invisibility, things didn't work so well. I kept getting weird behavior. I mean, you might be thinking, hey, it's an alleged cloak of invisibility, of course you're getting weird behavior. So forget the invisibility cloak for a second. I'm going to show you another simple cylinder. It's isotropic, and there's none of the singularities or infinities or other weirdness of invisibility devices. It's perfectly normal, except that now my index of refraction is going to be .1, instead of 2. That's the only thing I'm changing from the above-imaged simulation.
Here we go, there's the light, it's moving to the cylinder (marked by me),
|T=60, right when light first struck last time|
|T=80, my cylinder is eaten|
|T=220, all space is devoured|
It took me a long time to figure out what was causing this.
In short, inside the cylinder, light moves faster than the speed of light.
But that isn't actually a problem; light breaking its own barrier to speed inside of particular media is well documented theoretically and experimentally.
The real problem is that my program was written under the assumption of natural materials, materials for which the speed of light in the medium is always less than the speed of light in a vacuum.
The program takes the speed of light in to account using the aforementioned Courant condition. The calculation has a space which it divides up in to square cells. It then steps through time, at each time step updating all of the electromagnetic fields at each cell. The time step and the cell size are set so that light cannot cross an entire cell in a single time step. Since light in a medium can "never" move faster than light in a vacuum, this is satisfied easily for a "worst-case" scenario by making the time step less than twice the cell size divided by the speed of light in vacuum (we need at least root-two the cell size from Pythagorean theorem, and 2 is a round number and safer).
However, for my simulation, light can end up moving much faster, more than twice its normal value. Actually, the invisibility cloak calls for infinite light speed near the inner boundary. This causes the FDTD simulation to become unstable.
My advisor (who doesn't work with FDTD codes) initially suggested the problem is one of the program forcing information to travel faster than the speed of light. Which lighted up all kinds of science-fictiony places in my brain. My computer simulation can force the universe to misbehave, breaking one of the fundamental tenets of relativity, and I then simulate the resulting rift in the space-time continuum as it spreads like cancerous gangrene, devouring all life.
Here I go, running computer simulations of eldritch horrors awakening from the abyss.
|Seriously, tell me you don't see the similarities|
(picture courtesy this deviant art use).
(None of this to implicate my advisor in my personal zaniness... which is why I don't let out my last name or school... to protect the innocent... and the grant money...)
Of course, that isn't what actually happens, and really the opposite is true. The real problem is that I'm not processing information fast enough, and so light can outpace my recording of it. That still doesn't explain to me why the instabilities always start in places where there isn't any light at all. But that's what's happening. Allegedly.
Also, the real real problem is that I even need a Courant condition at all. This is because computers have to treat everything discretely. In the real world, the Courant factor is always zero, or somewhere near the Planck scale. Nature can't be duped like my poor C++ skills can.
Anyway, I was so initially intrigued by my advisor's suggestion that I wrote all of this. Then I thought about it, and was disappointed that it wasn't the case, but whatever. It was an error in my programing and nothing more, I fixed it now, and I had a brief misinterpretation of the error inspired more by science fiction than reality. It's still pretty fun, anyway.
And that's what I do on Saturday nights.