-
Notifications
You must be signed in to change notification settings - Fork 83
/
introduction.html
267 lines (239 loc) · 14.4 KB
/
introduction.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML><HEAD>
<TITLE>Introduction</TITLE>
<LINK rel="Contents" href="index.html">
<LINK rel="Copyright" href="license.html">
<LINK rel="Start" href="index.html">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
Go to the <a href="installation.html">next</a> or <a href="index.html">main</a> section.
<hr>
<h1>Introduction</h1>
<p><strong>MIT Photonic-Bands</strong> is a software package to
compute definite-frequency eigenstates of Maxwell's equations in
periodic dielectric structures. Its primary intended application is
the study of <strong>photonic crystals</strong>: periodic dielectric
structures exhibiting a band gap in their optical modes, prohibiting
propagation of light in that frequency range. However, it could also
be easily applied to compute other optical dispersion relations and
eigenstates (e.g. for conventional waveguides such as fiber-optic cables).
<p>This manual assumes that the reader is familiar with concepts from
solid-state physics such as eigenstates, band structures, and Bloch's
theorem. We also do not attempt (much) to instruct the reader on
photonic crystals or other optical applications for which this code
might be useful. For an excellent introduction to all of these topics
in the context of photonic crystals, see the book <a
href="http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=0691037442"
title="the book at BarnesandNoble.com"><i>Photonic Crystals: Molding
the Flow of Light</i></a>, by J. D. Joannopoulos, R. D. Meade, and
J. N. Winn (Princeton, 1995).
<p>Some of the main design goals we were thinking about when we
developed this package were the following (see also the <a
href="http://ab-initio.mit.edu/mpb/index.html#features">feature
list</a> at the MPB home page):
<ul>
<li>Fully vectorial, three-dimensional calculations for arbitrary
Bloch wavevectors. (The only approximation is the spatial
discretization, or equivalently the planewave cutoff.)
<p><li>Flexible interface. Readable, extensible, scriptable...see
also the <a
href="http://ab-initio.mit.edu/libctl/doc/introduction.html">libctl
design goals</a>.
<p><li>Parallel. (Can run on a single-processor machine, but is also
supports parallel machines with MPI.)
<p><li>"Targeted" eigensolver: find modes nearest to a specified
frequency, not just the lowest-frequency bands. (For defect
calculations.)
<p><li>Leverage existing software (LAPACK, BLAS, FFTW, HDF, MPI, GUILE...).
<p><li>Modularity. The eigensolver, Maxwell's equations, user interface,
and so on, should be oblivious to each other as much as possible.
This way, they can be debugged separately, combined in various ways,
replaced, used in other programs...all the usual benefits of modular
design.
<p><li>Take advantage of inversion symmetry in the dielectric
function, but don't require it. (This means that we have to handle
both real and complex fields.)
</ul>
<h2><a name="freq-vs-time">Frequency-Domain vs. Time-Domain</a></h2>
<p>There are two common computational approaches to studying
dielectric structures such as photonic crystals: frequency-domain and
time-domain. We feel that each has its own place in a researcher's
toolbox, and each has unique advantages and disadvantages. <b>MPB is
frequency-domain</b>; that is, it does a direct computation of the
eigenstates and eigenvalues of Maxwell's equations (using a planewave
basis). Each field computed has a definite frequency. In contrast,
time-domain techniques iterate Maxwell's equations in time; the
computed fields have a definite time (at each time step) but not a
definite frequency <i>per se</i>. It seems worthwhile to say a few
words about each method, and to explain why we want a frequency-domain
code. (Our group has both time-domain and frequency-domain software,
and we use both techniques extensively.)
<p>Time-domain methods are well-suited to computing things that
involve evolution of the fields, such as transmission and resonance
decay-time calculations. They can also be used to calculate band
structures and for finding resonant modes, by looking for peaks in the
Fourier transform of the system response to some input. The main
advantage of this is that you get all the frequencies (peaks) at once
from a calculation involving propagation of a single field. There are
several disadvantages to this technique, however. First, it is hard
to be confident that you have found all of the states--you may have
coupled weakly to some state by accident, or two states may be close
in frequency and appear as a single peak; this is especially
problematic in higher-order resonant-cavity and waveguide
calculations. Second, in the Fourier transform, the frequency
resolution is inversely related to the simulation time; to get 10
times the resolution you must run your simulation 10 times as long.
Third, the time-step size must be proportional to the spatial-grid
size for numerical stability; thus, if you double the spatial
resolution, you must double the number of time steps (the length of
your simulation), even if you are looking at states with the same
frequency as before. Fourth, you only get the frequencies of the
states; to get the eigenstates themselves (so that you can see what
the modes look like and do calculations with them), you must run the
simulation again, once for each state that you want, and for a time
inversely proportional to the frequency-spacing between adjacent
states (i.e. a long time for closely-spaced states).
<p>In contrast, frequency-domain methods like those in MPB are in many
ways better-suited to calculating band structures and eigenstates.
(Here, we consider the case of an <em>iterative</em> eigensolver like
the one in MPB, which iteratively improves approximate eigenstates.
Dense solvers, which factorize the matrix directly, are impractical
for large problems because of the huge size of the matrix, and because
they compute many more eigenvectors than are desired. In iterative
methods, the operator is only applied to individual vectors and is
never itself computed explicitly.) First, you don't have to worry
about missing states--even closely-spaced modes will appear as two
eigenvalues in the result. Second, the error in the frequency in an
iterative eigensolver typically decays exponentially with the number
of iterations, so the number of iterations is logarithmic in the
desired tolerance. Third, the number of iterations typically remains
almost constant even as you increase the resolution (the work for each
iteration increases, of course, but that happens in time-domain too).
Fourth, you get both the frequencies and the eigenstates at the same
time, so you can look at the modes immediately (even closely-spaced
ones).
<p>A traditional disadvantage of frequency-domain methods was that you
had to compute all of the lowest eigenstates, up to the desired one,
even if you didn't care about the lower ones. This was especially
problematic in defect calculations, in which a large supercell is
used, because in that case the lower bands are "folded" many times in
the Brillouin zone. Thus, you often had to compute a large number of
bands in order to get to the one you wanted (incurring large costs
both in time and in storage). These disadvantages largely disappear
in MPB, however, with the advent of its "targeted" eigensolver--with
it, you can solve directly for the localized defect states (i.e the
states in the band gap) without computing the lower bands.
<h2><a name="history">History</a></h2>
<p>In order to shed some light on the past development and design
decisions of the Photonic-Bands package, I thought I'd write a few
paragraphs about its history. Read on to enjoy my narcissist
ramblings.
<p>Many different people have written codes to compute the modes of
periodic dielectric materials (although we don't know of any others
that have been freely released). I have had experience with several
programs written within our group, and this experience has guided the
design of MIT Photonic-Bands.
<p>The first program of this sort that I came in contact with, and the
code that was used in our group until the development of this package,
was initially written around 1990 (in Fortran 77) by R. D. Meade. As
this software grew organically over time, several problems became
apparent. First, the input format was inflexible (difficult to add
new features without breaking old simulations), sensitive to
whitespace and other formatting, and required repeated entry of
information that was often the same from file to file. Often, pre-
and post-processing steps were required using additional scripts and
tools. Second, the many parts of the program had become intertwined,
lacking modularity or a clear flow of control; this made it difficult
to follow or modify substantially. Parallelizing it, or removing
constraints that it imposed like inversion symmetry, or even replacing
the input format seemed impractical. Besides, even reading code with
variables named <code>gxgzco</code> (in common block
<code>cabgv</code>) (honest!) is a mind-altering experience.
<p>After an initial experience in the Spring of 1996 at writing a code
based on a wavelet, rather than a planewave, basis (which turned out
not to be practical), I set out to write a replacement for our Fortran
eigensolver. My main aims at this time (Fall 1996) were a more
flexible and powerful input format and a code that would be amenable
to parallelization. I succeeded in achieving a working code with
similar convergence to the old code (after <a
href="http://prola.aps.org/abstract/PRB/v55/p15942_1">some pain</a>),
but I discovered several things. I had lots of fun learning to use
<code>lex</code> and <code>yacc</code> (Yet Another Compiler-Compiler)
to make a flexible, C-like input format with variables and other
advanced features. Having input files that were almost, but not
quite, like a programming language made me realize, however, that what
I really wanted <em>was</em> a programming language--no matter how
many features I added, I always wanted one more "simple" thing. As
far as parallelization, I quickly realized that I had a problem: I
needed a parallel FFT, and the only ones that were available were
proprietary (non-portable), used incompatible data distribution
formats, and were often designed to be called only from special
languages like HPF. That, plus my dissatisfaction with the available
free FFTs, led me to embark on a side project (with my friend Matteo
Frigo of MIT's Laboratory for Computer Science) to develop a new, free
FFT library, <a href="http://www.fftw.org">FFTW</a>, that included
portable parallel routines. Also, I decided that attempting to
support too many models of parallel programming (threads, MPI, Cray
<code>shmem</code>) in one program resulted in a mess; it was better
to stick with MPI (supporting running only a single process too, of
course). Another mistake I discovered was that I allowed the
eigensolver to get too intertwined with the specific problem of
Maxwell's equations--the eigensolver knew about the data structures
for the fields, etcetera, making it difficult to plug in replacement
eigensolvers, test things in isolation, or to implement features like
the "targeted" eigensolver of Photonic-Bands (which diagonalizes a
different operator). The whole program was too mired in complexity.
Finally, in the interim I had learned about block eigensolver
algorithms. Not only can such algorithms leverage prepackaged,
highly-optimized routines like BLAS and LAPACK, but they also promised
to be inherently more suited for parallelization (since they remove
the serial process of solving for the bands one by one). All of these
things convinced me that I needed to rewrite the code again from
scratch.
<p>So, I started work on the new package (in Spring 1998), this time
determined to develop and debug each component (matrix operations,
eigensolver, maxwell operator, user input) in isolation. At the same
time, I was thinking about how I would implement the user control
language, wanting to develop a general tool that could be applied to
other problems and software in our research. It seemed clear that, in
order to get other people to use it in their programs, as well as to
avoid a lot of the manual labor that went into my previous effort, I
wanted to automatically generate the user/program interface from an
abstract specification. As for the control language, I briefly
considered implementing my own, but was happily led to GNU Guile
instead, which gave me a powerful language with little effort. So
armed, I set out to write libctl (which generates the Guile interface
from an abstract Scheme specification), partially as an experiment to
see how hard it would be and what the result would look like. After a
weekend of work, it was obvious that I had a powerful tool; I spent
couple of weeks adding some finishing touches, writing documentation,
and so on, and proudly showed it off to my groupmates in the hope that
they could use it for their programs. Without a real example of a
program using libctl, however, it was hard to convince them to plug a
scripting language into their existing, working codes. So, I went
back to puttering at my eigensolvers.
<p>Of course, all this time I was allegedly doing real research, and
long periods would go by with little progress on the Photonic-Bands
package. The original, Fortran code was still working, and in time
one learned to bear its quirks and limitations with stoicism, although
we cringed every time we had to show it to anyone else. By the summer
of 1999, I had a working block eigensolver (supporting several
iteration-scheme variants), a Maxwell operator to plug into the
eigensolver (including a "targeted" operator, whose convergence I was
unhappy with), and a test program to do convergence experiments on
bands of a Bragg mirror. I hadn't attached any general user
interface, field output, or other necessary components. At this
point, Dr. Doug Allan of Corning (a former student of
Prof. Joannopoulos), heard about the new code--in particular, the
targeted eigensolver--and began clamoring to try it out. Not put off
by my excuses, he asked for a copy of my current code, regardless of
its status, to play with. Not wanting to refuse, but aghast at the
prospect of someone seeing my masterpiece only half-painted, I told
him to give me a week...in which time I added the interface and
discovered that I had a useful tool. Over the next week, I added many
features, fixed bugs, and wrote documentation, drawing near to a
release at last...
<hr>
Go to the <a href="installation.html">next</a> or <a href="index.html">main</a> section.
</BODY>
</HTML>