Metric - Modes and mode arrays

The mode analysis procedures take an object of class ModeArray as a reference argument. On completion of the searching process, the data structure is filled with the found Mode objects. This data constitutes the output of the mode solver.

Objects of class Mode as defined in slamode.h and slamode.cpp play a twofold role in the Metric collection: On the one hand, they implement what is meant by a guided mode, i.e. a physical wave profile that propagates without depletion along a longitudinally homogeneous, laterally unbounded dielectric channel. On the other hand, in the context of the scattering problems, Mode objects defined on a finite transverse computational window serve as basis elements for expansions of general 2-D optical electromagnetic fields.

In the mode eigenvalue problems, the squared propagation constant appears as the principal eigenvalue. This real value is part of the Mode objects as a member betaq. Depending on the sign of betaq, a mode is called either "propagating" for positive betaq, or "evanescent", if betaq happens to be negative. This propagation type is viewed as an internal property of the Mode object. Further, with each mode profile shape two directional variants are associated: The mode object can be treated as a "forward" traveling wave, or as a mode that travels "backward". While in the case of propagating fields this distinction is rather obvious (phase fronts that propagate forward in the positive z-direction or backward in the negative z-direction), for evanescent modes it is a matter of a more or less arbitrary definition. Here evanescent modes that decay in the positive z-direction are called "forward traveling", and evanescent fields that grow exponentially with z are called "backward traveling".

Internally the modes are handled in terms of the six real functions E_x, E_y, E_z, H_x, H_y, and H_z that represent the electric and magnetic components of the mode profile, and a real value beta for the propagation or decay constant of the mode. The mapping of these quantities to physical fields depends on the propagation type and the propagation direction of the mode:

In both cases the upper signs apply to forward traveling fields, the lower signs are meant for backward traveling waves.

Modes can be copied and assigned. The objects provide members and methods that correspond to the two usage aspects of Modes:

`wg`	The `Waveguide` the mode was calculated for, including the vacuum wavelength.
`pol`	The mode `Polarization`, `TE` or `TM` as defined in gengwed.h.
`k0`	The vacuum wavenumber, `k0=2 PI/wg.lambda`.
`betaq`	The squared propagation constant of the mode. The sign of this real value decides whether the object represents a propagating or an evanescent mode, cf. the remarks above.
`beta`	The propagation constant of the mode, a real positive value. The mapping to the harmonic or exponential dependence on the propagation distance depends on the type of the mode and on the propagation direction, see the remarks above.
`neff`	The effective mode index, `neff=beta/k0`.
`npcB`	A normalized effective mode permittivity, `npcB=(betaq/k0/k0-nmin^2)/(nmax^2-nmin^2)`, where `nmin` and `nmax` are the default values for effective indices of guided modes supported by the underlying waveguide `wg`. For guided modes, the value of `npcB` between `0` and `1` indicates "how far the mode is away from cutoff", where the value of `0` represents the cutoff level. For waveguides with `nmin>=nmax`, the quantity is undefined.
`ppt`	The `Propagation_type` of the mode, either `PROPAG` or `EVANESC` as defined in gengwed.h. See the remarks above on propagating and evanescent modes.
`bdt_b`, `bdt_b`	The types of boundary conditions for the principal mode component used during the mode computation at the bottom (`bdt_b`) and top end (`bdt_t`) of the computational window. These are quantities of type `Boundary_type` as defined in gengwed.h, with possible values `OPEN` (infinite computational interval in the respective direction), `LIMD` (a homogeneous Dirichlet boundary condition), or `LIMN` (a homogeneous Neumann condition). Cf. the remarks on the Metric mode solvers and the specification of boundary conditions.
`bdp_b`, `bdp_t`	The x-positions of the boundaries at the bottom (`bdp_b`) and at the top end (`bdp_t`) of the computational interval. These levels are irrelevant if `bdt_b==OPEN`, or `bdt_t==OPEN`, respectively.
`ord`	The order of the mode, the number of nodes in the principal field component in the interior of the computational interval. Exception: Modes with a nonzero `special` value (see below), here `ord` is set to the index position in the "native" `ModeArray` of the mode.
`ids`	A identifier string for the mode, composed of the polarization and mode order ("`TE0`", "`TM1`", "`TE41`"). An `x` is added in case of a field with a nonzero `special` value (see below).
`cbeta`	The directional complex propagation constant, a `Cvector(2)`, to be invoked as cbeta(FORW) or cbeta(BACK) to select forward or backward traveling fields (identifiers of type `Propdir`, defined in gengwed.h). Values are `beta` for forward traveling propagating modes, and `-CCI beta` for forward traveling evanescent modes. For the backward versions, the values are multiplied by `-1`.
`field`	The mode profile at a given position x on the waveguide cross section. The function returns real values for the six components of the electric and magnetic field, or for the longitudinal component of the Poynting vector, identified by an argument of type `Fcomp` as defined in gengwed.h, one of `EX`, `EY`, `EZ`, `HX`, `HY`, `HZ`, or `SZ`. Depending on the component and the propagation type of the mode, the return values represent either the real or the imaginary part of the complex mode profile (see the above description). An optional argument of type `Propdir`, (see also gengwed.h), one of `FORW` or `BACK`, can be supplied to select the proper signs for the forward or backward variant of the mode profile.
`cfield`	The complex directional mode profile at a given transverse coordinate x. The function returns complex values for the six components of the electric and magnetic field, or for the longitudinal component of the Poynting vector, for the forward or backward variants of the mode profile, as specified by arguments `EX`, `EY`, `EZ`, `HX`, `HY`, `HZ`, or `SZ`, and either `FORW` or `BACK` (types `Fcomp` and `Propdir` as defined in in gengwed.h). An optional distance argument can be supplied to evaluate the spatial mode evolution along the longitudinal z-axis (see the method `efac` below).
`efac`	A complex factor that represents the change in phase (for a propagating mode) or amplitude (for an evanescent wave) of the mode field along the longitudinal z-axis, for given direction of propagation (`FORW` or `BACK`) and given z-distance. A complex propagation constant shift can be supplied as an optional argument to evaluate the effects of small perturbations of the supporting permittivity profile.
`power`	The modal power (for propagating modes), evaluated by integrating the z-component of the Poynting vector over the transverse computational interval, i.e. over the full x-axis in case of a guided mode. For evanescent fields, a corresponding expression composed by bidirectional variants of the mode is integrated over the finite window. Used for normalization purposes (method `normalize`); all modes established by the Metric mode solvers are normalized to `power()==1`. Cf. also the description of the `overlap` routines.
`writeprofile`	Export discretized mode profile data into an external file. For a given number of output points and a display `Interval`, the function writes a file (type .xyf) in ASCII format with real (x, field(x))-pairs in two columns. The forward variant of the mode profile is evaluated. A `Fcomp` identifier selects the field component. An additional argument of type `Afo` (one of `MOD`, `ORG`, `SQR`, `REP`, or `IMP`, see the section on output visualization) specifies how to convert the complex field profile into the real output values. Two character arguments and the mode properties are used to generate a default filename. A variant of the method supplies default values for all parameters (data for the original real field of the principal mode component on a default mesh for the respective waveguide), except from the filename identifiers.
`plot`	Generate a .m-script that produces a plot of a mode profile component when executed in MATLAB. See the section on visualization of mode profiles.
`phaseshift`	The first order shift of the propagation constant due to different kinds of small perturbations, calculated by evaluating perturbational integrals / expressions. Besides a propagation direction, the variants of this method accept either an object of type `Perturbation` (defined in gengwed.h), a layer interface index and a displacement value, or a wavelength shift to calculate the response to small uniform permittivity perturbations (here anisotropic and attenuating contributions are allowed), to small shifts of the dielectric interfaces in the waveguide profile, or to a small change in the vacuum wavelength, respectively. Cf. the section on single mode perturbations for more details.
`translate`	Shift the `Mode` object over a given distance along the x-axis. The underlying waveguide `wg` is altered accordingly.
`write`, `read`	Write all data that constitutes the mode object to a file (ASCII format, extension `.smo`), or read the data to reconstruct the object. Two variants of each of the methods accept either the handle of an open `FILE`, or two character arguments (and a `Polarization` identifier for `read`) to generate / access a file with default name.
`equal`	Compare the present object with another `Mode`. The routine assumes that both objects are properly normalized eigenfunctions of their respective waveguide.
`special`	If nonzero, this mode has been computed as part of a decoupled structure, or with modified boundary conditions (cf. the remarks on the Metric mode solver), or a proper classification of the profile is not possible. A letter `x` is added to the mode identifier string `ids`.

The list of further members of the Mode objects includes variables and methods for internal use by the field evaluation routines (invommu, invomep0), for use by the mode solver (nodes, dnodes, classify, setids, maxF, setmaxF, checkmode, checkcontinuity, normalize, travres, revtravres, nummodesabove, travresinspect, localize, polish, expand, mirror), and additional supportive functions for the integration and overlap computation routines (integrate, overlap, cross_int, crossoverlap). Usually the Mode constructors need not to be accessed explicitly, with the exception of the empty constructor, that serves to generate a container to which an element of the modesolver output-ModeArray can be assigned.

Internally, a Mode is implemented as an array of SmPieces, corresponding to the layering of the underlying Waveguide. Along with the Modes these pieces of slab modes are defined in slamode.h, slamode.cpp. The SmPiece objects also provide several of the members and methods of the mode objects, but are restricted to a single layer. While in certain circumstances one can gain efficiency by the direct use of SmPiece methods (thus circumventing the repeated layer selection), usually the internal representation need not to be accessed from a driver program.

The driver files tlwg.cpp, disp.cpp, and spec.cpp provide examples on how to generate, handle, and inspect the Metric mode objects.

Integrated products of field components play a role at various places in the Metric programs, e.g. for computing initial mode amplitudes (overlaps with given fields), in the framework of coupled mode theory, or for projecting different field expansions around an interface in the BEP and QUEP algorithms. The following routines are provided, defined in slamode.h and slamode.cpp as methods of Mode objects or as functions:

integrate
Mode::integrate Functions / methods that compute the integral of two mode profile components over a given interval on the x-axis. If for each participating mode only the component identifier (of type Fcomp, here one of EX, EY, EZ, HX, HY, or HZ, defined in gengwed.h) is supplied, the functions apply the convention for real mode profile components (cf. the paragraph on mode objects and the remarks on the Mode::field method), and compute a double value. Alternatively, for each mode additionally an identifier for the propagation direction (of type Propdir, either FORW or BACK, defined in gengwed.h) can be provided, together with an integer that indicates whether the complex conjugate of the respective field is to be evaluated. Here the complex mode profile representation is applied (cf. the paragraph on mode objects and the remarks on the Mode::cfield method); the routines then return values of type Complex. Different variants exist for components of the same mode (methods of Mode), or for integrating products of two components that belong to the profiles of different modes (Mode methods that operate on another Mode-reference, alternatively functions that accept two Mode-references).

overlap
Mode::overlap

For two electromagnetic field profiles (typically Mode objects accompanied by identifiers of type Propdir for the propagation directions) with indices 1 and 2, the functions / methods compute the - in general complex valued - integral

$0.25 * int (E_{1x}^* H_{2y} - E_{1y}^* H_{2x} + H_{1y}^* E_{2x} - H_1x}^* E_{2y}) dx$

Note that here the symbols E_jc and H_jc represent the complex component of the respective mode profile / field. The product serves for purposes of projection in the BEP and QUEP formulations and is applied for normalization (method Mode::normalize()) by the Metric mode solver: For a normalized mode m the unit value of m.power() is equal to the real values of m.overlap(FORW, m, FORW) and overlap(m, FORW, m, FORW), if m is a propagating mode, or equal to m.overlap(FORW, m, BACK) and overlap(m, FORW, m, BACK), in case m is evanescent. The orthogonality properties of modes that belong to the same waveguide can be expressed quite conveniently with the help of this expression. The routine exists in two variants, as a Mode method that operates on another Mode-reference, or as a function that accepts two Mode-references.

A specific variant of the Mode::overlap-method accepts a Gaussian beam (an object of type Gaussianbeam, see the commented constructor in gengwed.h) as the second field. This allows to specify Gaussian profiles as input fields for the Helmholtz solvers; corresponding input methods are provided by the containers BepField and QuepField for BEP and QUEP solutions.

Further integration routines exist as methods of Mode-objects (cross_int, crossoverlap) or as functions (bidir_overlaps) which are less likely directly useful in a driver program. With the exception of the expressions where Gaussian profiles are involved, all integrals are evaluated analytically for the piecewise defined mode profiles.

Functions, methods: integrate, Mode::integrate; overlap, Mode::overlap.
Relevant source files: slamode.h, slamode.cpp.

Objects of type ModeArray as defined in slamarr.h, slamarr.cpp serve as containers to store the results of the mode analysis procedures, and they are part of the internal field representation used by the BEP and QUEP Helmholtz solvers. The parantheses operators () provide access to store and retrieve the Mode-entries. ModeArray-objects can be copied and assigned. The list of members includes the following variables and methods:

`num`	The number of entries in the array. The `Mode`s in a `ModeArray ma` are `ma(0)`, . . . , `ma(ma.num-1)`.
`clear`	Remove all entries, free the allocated memory; `num==0` afterwards. This function is invoked at the beginning of each call to a mode analysis procedure.
`add`	Enlarge the array by another `Mode`.
`remove`	Delete the entry with the specified index.
`merge`	Merge the entries of another `ModeArray` into the present object. The added array is cleared.
`sort`	Sort the mode entries in descending order according to their squared propagation constants.
`equal`	Compare the present object to another `ModeArray`.
`write`, `read`	Write all data that constitutes the mode object to a file (ASCII format, extension .sma), or read the data to reconstruct the object. Two variants of each of the methods accept either the handle of an open `FILE`, or two character arguments to generate / access a file with default name.
`field`, `endens`, `pfield`	For given amplitudes vectors, evaluate the electromagnetic field or the optical energy density for the mode superposition at a specified position. See the paragraph on mode interference evaluation.
`plot`, `fplot`, `phasemap`, `movie`, `fmovie`, `viewer`	Given suitable amplitude vectors, the methods write MATLAB .m-files that generate plots or animations of field components, of the local phase, or of the energy density, for a specified plot window. See the section on visualization of interference fields.

A few other methods (crossoverlap, orthonormality) exist that are intended for internal use by the Helmholtz solvers. Only an empty constructor is provided; mode entries can be inserted by the add or merge methods.

The Metric programs represent general optical electromagnetic fields as superpositions of directional modes of multilayer slab waveguide profiles. With objects of types ModeArray, BepField, and QuepField, three types of containers for such expansions exist. These objects provide (variants of) the following procedures as a basic means to evaluate the local field that results from the superposition:

`field`	The local electromagnetic field at a given x-z-position. An identifier of type `Fcomp` as defined in gengwed.h specifies the field component. Values `EX`, `EY`, `EZ` for the electric field, `HX`, `HY`, `HZ` for the magnetic field, and `SX`, `SY`, `SZ` for the three components of the Poynting vector are allowed. Hence the function also permits to evaluate the local intensity.
`endens`	The energy density of the optical electromagnetic field at a given x-z-position.
`pfield`	The local field in the presence of perturbations of the propagation constants, given a vector of propagation constant shifts. Typically the individual perturbations are computed by the `Mode::phaseshift` methods, where different kinds of effects can be considered (general locally uniform permittivity shifts, attenuation, shifts of dielectric interfaces, or wavelength shifts; see the section on single mode perturbations for details). So far implemented for unidirectional mode propagation and for `ModeArray`s only ...

Note that physically reasonable results can be obtained only for a unique underlying permittivity structure, i.e. all modes in the respective objects that are relevant for a specific position and are nonzero there need to belong to the same waveguide.

Typically the BepField and QuepField objects contain the results of an execution the BEP or QUEP Helmholtz solvers; mode amplitudes that correspond to the solutions are determined by the solvers and stored in the objects. The ModeArrays on the other hand do not include amplitude vectors. These must be supplied for each call of the above methods on a ModeArray object, where two variants exist (cf. the declarations in slamarr.h):

Internally, the BepField::field and QuepField::field methods rely on the second variant for the field evaluation on interior regions of the underlying SegWgStructs.

The mode functions introduced above relate to propagation along one of the Cartesian axes (z), with a mode profile that depends on a second coordinate (x), where the supporting structure and all optical electromagnetic fields are assumend to be constant along the third axis (y). All components of the mode profile can be derived from a single principal component, which satisfies a simple scalar 1-D TE or TM mode equation. If one now considers, still for a dielectric multilayer slab that extends infinitely in-plane along two coordinate axes (y, z), the propagation of, say, guided waves at arbitrary angles in this plane, then one observes that the former slab modes still constitute valid solutions, if only their vectorial mode profiles are rotated to match the direction of propagation. Propagating and evanescent fields of this type play a role as basis elements for the vQUEP solver. Please see the related journal article (Optics Communications 338, 447-456 (2015)) for further details.

A Mode object is prepared for use in this sense through providing a y-wavenumber ky through its vectorify-method, with the vM-member set to 1 afterwards. Several of the routines associated with mode objects switch accordingly to alternative procedures (names starting with "cV"). Typically these features need not to be accessed explicitly in a driver program, but are used only internally by the vQUEP solver.

Members, methods: Mode::vM, Mode::ky, Mode::vectorify, further members / methods Mode::cV(...) .
Relevant source files: slamode.h, slamode.cpp.