Slab waveguide » field animation (0.7MB)
Introduction
Program structure Prerequisites Output files

The Metric program collection combines a series of semianalytical tools for the simulation and design of structures or devices from integrated optics / photonics. The programs are meant for frequency domain modeling of configurations in one, two, or 2.5 spatial dimensions, with (mostly) piecewise constant, isotropic, lossless, and preferably rectangular permittivity distributions.

Optical electromagnetic fields are represented by series of eigenmodes associated with 1-D, piecewise constant refractive index profiles. Accordingly, a reasonably robust and general mode solver for dielectric multilayer slab waveguides is found at the center of the tool collection. Apart from standard guided mode analysis, the mode solver routines include facilities for the generation of orthonormal modal basis sets on finite 1-D intervals, where the mode spectrum is discretized by Dirichlet- or Neumann boundary conditions.

Scattering problems (Helmholtz problems) are addressed by semianalytical mode expansion along one (bidirectional eigenmode propagation, BEP) or two coordinate axes (quadridirectional eigenmode propagation, QUEP). The BEP procedures are meant for configurations that can be represented adequately as a sequence of longitudinally homogeneous waveguide segments, laterally enclosed by Dirichlet boundary conditions, with half-infinite entry and exit segments. The QUEP model becomes relevant for dielectric structures on a rectangular computational domain, where omnidirectional (2-D) propagation and guided or nonguided influx and outflux across all four boundaries is important. A given structure is to be encoded into simple objects for waveguides, sequences of waveguides, or rectangular integrated optical “circuits”. The objects that hold the resulting optical fields provide facilities for a detailed evaluation and inspection of the relevant electromagnetic quantities, including routines for the static or time-animated visualization.

Due to the semianalytical field representation, the incorporation of small additional effects is straightforward in terms of perturbational expressions or coupled mode theory. This concerns effects like low levels of attenuation, small uniform refractive index modifications e.g. due to electro- or magnetooptic tuning, specific cases of anisotropy, or the weak interaction of guided modes. However, so far the corresponding expressions are only partly implemented systematically.

Adhering to the continuous development, the underlying algorithms have been the subject of a couple of papers concerned with the bidirectional and quadridirectional mode expansion technique, and with the related applications. For a more detailed account on the Metric procedures we refer to these publications. Many of the simulation examples given there can be reproduced using the programs that come with this document.

Program structure

Currently, the Metric collection consists of a number of C++ library files. For a new application, you will have to write a C++ program including the main() procedure, or to edit one of the supplied application examples for your own purposes (this should be the easiest way to get started). Compiling the application together with the library produces the executable.

This organization has the disadvantage of frequent program recompilations, and may seem to be discomfortable at the first glance. The second reveals, that only the usually short application file has to be multiply compiled and linked, which should be a matter of not more than a few seconds. The time overhead is negligible, while in this way the full functionality of the C++ language becomes available for the applications. For a design task which usually involves sweeps over various geometrical or material parameters, or spectral scans, this organization seems to be more appropriate than clicking through a kind of session management or learning a new and probably restricted script language. It also keeps the code portable and open for own extensions.

The library files are accessed via the single header file metric.h. Apart form the declarations of the routines and data structures that are described on the following pages, the header provides a couple of more general, supportive routines:

What concerns the routines for complex numbers and linear algebra, these are present mainly for historical reasons; you may wish to replace these by the standard library functions or by more sophisticated (and probably more efficient) linear algebra subroutine libraries of your choice.

Relevant source files: metric.h; complex.h, complex.cpp, matrix.h, matrix.cpp, gengwed.h, gengwed.cpp.

Prerequisites

The program structure obviously requires some knowledge of the C++ programming language and a working C++ compiler. So far, the code has been executed mainly on a number of PCs with Linux operating system, where the free GNU Compiler Collection is available. While the Metric programs should work well with that compiler (also on other platforms), on some occasions we have observed executables produced with the native compilers of the operating systems to be considerably faster. Thus, if possible, one should use a programming environment which is optimized for (i.e. comes with) the underlying operating system / machine.

The Metric programs do not include tools for visualizing the numerical output data. One will need at least a means to view two dimensional curves (something like the Gnuplot utility) and a program package to display three dimensional data. For this purpose, subroutines have been added to the Metric collection which put out valid MATLAB scripts (.m-files). Therefore it is most convenient to work within an environment where this tool is available (not necessarily the very latest version). Otherwise, the output routines would have to be adapted.

Part of the functionality for numerical linear algebra relies on subroutines as provided by the Eigen library. This package needs to be downloaded and appropriately placed in addition to the Metric programs.

Naming convention, output files

The application files may be regarded as the input to the Metric programs. The output consists of the (stderr) text stream on the one hand. This includes control information about the structure under investigation, log information about the progress of the routines, notification about file input and output, and results according to the instructions in the driver file. On the other hand, the solvers return numerical data in files of one of the following types, identified by their extensions (all output files are in ASCII format):

Frequently, a program run generates many output files, differing e.g. in polarization, in the plotted field components, or in the type of plotted information. To get rid of the task of inventing filenames, most functions that output these files accept only two character arguments to specify the filename (which can be conveniently connected to a loop index, cf. e.g. tlwg.cpp). Where appropriate, the remainder of the filename is composed of some of the following ingredients:
Contact
Home
Top
Next