Waveguide workflow guide

Background 

The waveguide workflow is capable of collecting CML Compiler source data for compact modeling of a wide variety of waveguides. 

What data do I need for my compact model?

• Wavelength dependent properties:
  • Effective index, neff
  • Group index, ng
  • Dispersion, D
  • Loss
• …As a function of width, radius, temperature
• …For TE and TM modes

How do I get this data?

• Ideally as much data as possible comes from experimental measurement.
• At a minimum, loss should come from measurement, as it strongly depends on scattering from surface roughness, which is process dependent and very difficult to accurately simulate.
• Group index can be extracted from interferometer or resonator device measurements, from the free spectral range measurement.
• Effective index and dispersion are typically more challenging to extract from measurement. It is common to use data from simulation for these properties.
• It is common to have measured data for the default (or center range) parameter values, and typically more challenging to have data across all possible parameter sets. Simulation can be used to help predict how the properties will vary between sparse data.

How can the workflow help me with this?

• It offers an automated simulation to calculate for the data you are missing from measurement.
• It offers different options to reliably integrate measurement and simulation data automatically. To highlight some of this workflow’s capabilities:
  • Have some data but not all? The workflow automatically runs simulations and can lock supplemental simulation data to experimental values.

• • Noisy experimental data? Use self-consistency enforcement to achieve physical model data 

• And it generates data files for different waveguide types ready for parameterized or back-annotation compact modeling using CML Compiler. For back-annotation modeling, it also generates data files for the third-party tool for creating layout P-Cell.

Summary

The waveguide workflow is capable of collecting CML Compiler source data for a wide variety of waveguides. There are several different data processing options which allows calibration of the compact models to various types of experimental data. The workflow fills in the data you don’t have by running customizable FDE simulations to determine the missing values. You can use this workflow to generate source data for waveguide models if you have only loss data, a few group index measurements, expansion coefficients for effective index, or a set of highly sampled experimental values for optical indices and waveguide dispersion. Regardless of the input data you have available, there is certainly a configuration of the flow which will allow you to prepare your data to be used in CML Compiler. In the waveguide workflow package, you can find following templates each of which is customized for a certain available experimental data and hence different data processing and configuration setting is used.

For an example of using the waveguide workflow please see Waveguide Workflow.

Requirements

• Required license: One Lumerical IDE (e.g. MODE, INTERCONNECT, etc)
• Optional (highly recommended) licenses: MODE, INTERCONNECT, CML Compiler
• Required version: 2020 R2.4 or higher.

Data Requirement

This workflow requires different data to be provided to generate CML Compiler ready data file which includes experimental data, configuration data and driver data. Below you can find more information about each of these requirements.

1. Experimental Data 

Experimental data should be provided under input_data folder.

Experimental data is provided to the waveguide flow using a CSV file. The CSV file must follow a specific format so that the workflow can parse it, and the data must be provided for a set of wavelengths, parameters, and modes which are accepted by the workflow.

For information about how the CSV file must be formatted, see the CSV Data File Format section, and for information on how the data must be laid out, see the Data Layout section.

CSV Data File Format

Experimental data is provided to the workflow through a comma-separated-values file in the input_data folder. This data is parsed through script and then processed before being included in the model source data in the output_data folder.

Since this file needs to be understood by the parsing scripts, it must be provided in the appropriate format. It’s expected that the data is laid out with various types of data (waveguide loss, group index, expansion coefficients, etc…) along with waveguide parameters (wavelength, width, curvature, temperature) each provided in a column. For example, consider the loss data provided for wg_1_experimental_loss template:

Notice that the header contains two rows - one which denotes the type of data being provided (wavelength, loss, etc…) and one which denotes the mode it corresponds with (TE/TM). This header is parsed by the workflow to determine what each column contains. Optionally, you can provide information about each column within the config file - if multiple datasets are contained within a single CSV file, or providing a header with this formatting isn’t desired. For an example of this, see the configuration for wg_5_experimental_loss_ng_highly_sampled_advanced template. For more details about this, see the external config section.

Data Layout

Experimental data must be provided for some set of wavelengths and parameter values (width, curvature, temperature). In particular, it must be provided on a “dense”, “semi-sparse”, or “sparse” grid. Data which is provided on a “semi-sparse” or “sparse” grid will be filled in by assuming that data varies independently for each parameter.

A “dense” grid is one which contains input data (loss, group index, etc…) for all possible combinations of wavelengths, parameters (width, curvature, temperature), and modes within some domain. This is quite hard to obtain through measurement, so it’s more likely that you will provide data in one of the other formats.

A “sparse” grid is one which contains input data along each axis. That is - data is provided for some ‘origin’ value, and then variation of the input values according to wavelength, parameters, and modes are provided independently. For example, see the following figure. It depicts a sparse dataset in three dimensions.

A “semi-sparse” grid is one which contains input data densely along some axes and sparsely along others. Data might be provided for all wavelengths and modes, but variation of the other parameters (width, curvature, temperature) is provided independently. For example, see the following figure. It depicts a “semi-sparse” dataset - wherein data is provided independently (or “sparsely”) in horizontal planes for all width values. These examples are shown in three dimensions, but note that the waveguide dataset is actually 5-dimensional (wavelength, width, curvature, temp, mode.)

2. Configuration Data 

Configuration files must be provided in the input_data folder for all the waveguide types desired in the format of <element_name>_model_config.* where * is lsf, json or mat. Please beware that the required information will vary according to the photonic model that is used. 

2.1 Parameterized Waveguides 

These files contain information required by cml compiler CML Compiler to generate straight, arc and s-bend parameterized waveguide compact models. For more information on the data required for CML Compiler please visit wg_parameterized - CML Compiler Photonic Model and Parameter Script File section. The workflow will use this information to combine with measurement and simulation data to have the source data ready for CML Compiler. These include: 

1. Parameterized waveguide data requirement: Data required listed in wg_parameterized - CML Compiler Photonic Model will be filled in by default values except for CML/notes and Length information which should be provided by user.
2. Invisible parameters: You can have one or more parameters invisible to compact model user by defining an invisible_parameters cell. This cell can include any of the parameters, width, temperature and curvature that you need to hide from the end user. For an example please see wg_strip_sbend_parameterized_model_config.lsf.
3. Statistical parameters: For a statistically enabled compact model, "stat_parameters" cell should be provided in this file as described in Waveguide Straight (Parameterized, Statistical) - Lumfoundry Template under Statistical Data. Any of the waveguide parameters (eg. width), FOMs (eg. loss) and core thickness (height) can be set as statistical parameters. Please see Statistical Data Collection for more information.

2.2 Back-annotation Waveguides

These files contain information required by  CML Compiler to generate waveguide compact models that can communicate with third-party layout tool for layout geometric-specific waveguide properties. For more information on the data required for CML Compiler please visit waveguide_back_annotation – CML Compiler Photonic Model and Waveguide Back Annotation - Lumfoundry Template. The workflow will use this information to combine with measurement and simulation data to have the source data ready for CML Compiler and third-party tool. These include:  

1. Back-annotation waveguide data requirement: the data listed in  Waveguide Back Annotation - Lumfoundry Template will be filled with default values, except that CML/notes information should be provided by user.

3. Driver Data

Driver data is provided in run_waveguide_colection.lsf file which includes all the settings and controls for running the workflow. It is recommended to run this in MODE. If no simulations need to be run, it can also be run into any other IDE, except INTERCONNECT.

NOTE: This workflow performs read/write actions on multiple files during the execution. As such, before running the flow, it is required that the “safe mode” being disabled for any Ansys Lumerical products used.

General

The high-level config for the workflow includes all of the filesystem information that the workflow requires to run, as well as some information about the final model which is used throughout the flow for all generated models.

• config.input_dir is a string containing the full path to the input data directory.
• config.output_dir is a string containing the full path to the output data directory.
• config.working_dir is a string containing the full path to the working directory for the flow.
• config.element_names is a cell array containing strings which each have the name of a compact model. These names will be used to locate the element configuration files in the input directory, and for generating the output file names.
• config.output_extension is a string containing the desired extension of the output data. Options are “json” or “mat”.
• config.photonic_model is a string containing the photonic model that is used. Options include “wg_parameterized” and “back_annotation_waveguide”. 
• config.mode_data is a cell array containing information about the modes for the final compact models. It contains the names and IDs of each mode.
• config.wavelength is a vector containing the wavelength points (in meters) for the final compact model. This will control the wavelengths used during the simulation sweeps as well.
  • Note: It’s highly recommended that, for multi-band waveguides, at least three wavelength points are used per band. For single-band waveguides it’s okay to use just a single wavelength per band.
• config.width is a vector containing the waveguide widths (in meters) over which the final compact model is parameterized. This will control the widths used during the simulation sweeps as well.
• config.curvature is a vector containing the curvatures (in inverse-meters) over which the final compact model is parameterized. This will control the curvatures used in the simulation sweeps as well.
• config.temperature is a vector containing the temperatures (in kelvin) over which the final compact model is parameterized. This will control the temperatures used in the simulation sweeps as well.

External

Often times compact models are built using some amount of external data. The config for this module is provided with config.external.

• config.external.use is a flag which determines whether or not external data should be used. Set to “true” if you want to use external data, and “false” otherwise
• config.external.filename is the filename of the CSV file which contains external data. This filename is referenced to the input data folder provided in the high-level config (see the General section).

     Optional Settings

• config.external.columns [optional] is the description of columns located within the CSV file. This is not required - if it is not provided, the header of the CSV file will be parsed to determine what each column contains. For an example please see templates/wg_5_experimental_loss_ng_highly_sampled_advanced/run_waveguide_collection.
• config.external.bands [optional] is the description of the frequency bands supported by the device. This is not required - by default the workflow will automatically determine the appropriate band settings by comparing the wavelength data available against the typical definitions of O, C, and L bands. For an example please see templates/wg_5_experimental_loss_ng_highly_sampled_advanced/run_waveguide_collection.

Simulation

The automatic simulation setup for the waveguide flow can be configured using the settings within config.simulation.

• config.simulation.use is a flag which determines whether or not simulation data should be used in the final model.
• config.simulation.run is a flag which determines whether or not simulation data should be generated during this run of the workflow. This should be set to true to begin with, and can be set to false in subsequent runs if you’d like the flow to just use the previously generated simulation results.
• config.simulation.material_name is a string containing the material which should be used for the waveguide. This material must already exist within the material database in MODE.
• config.simulation.thickness is a number containing the thickness of the waveguide in meters.

     Optional Settings

• config.simulation.slab_thickness [optional - default: 0]  is a number containing the slab thickness in case of a rib waveguide. If this value is not provided, thickness of zero will be assumed.
• config.simulation.save_sim_files [optional - default: false] is a flag which determines whether or not the individual simulations from the parameter sweep should be saved. If set to true - a simulation file will be saved for every parameter combination within the sweep.
• config.simulation.log_filename [optional - default: "simulation_log.log"] is a string containing the name of the simulation log file. This file records automatic simulation log.  The file will be saved within the working directory of the workflow.
• config.simulation.lms_filename [optional - default: "routing_waveguide.lms"] is a string containing the name of the .lms file to use for the simulations. If this file doesn't exist, the workflow will copy a default file with this name into the working directory and work with that. Otherwise, the workflow will attempt to load the simulation file with this name from the working directory, and use it for the parameteric sweep.
• config.simulation.data_filename [optional - default: "simulation_data"] is a string containing the filename for the simulation data within the working directory. After the simulations are run, the sweep results will be saved into a .mat file with this name, and used by the rest of the flow to generate the final model data. If config.simulation.run is set to false, and config.simulation.use is set to true, then the workflow will attempt to load previous simulation results from the file in the working directory with this name.
• config.simulation.num_trial_modes [optional - default: 10] is an integer containing the number of trial modes used for each FDE simulation. If this is set too low, it's possible that the proper TM mode will not be within the set of trial modes - and the mode tracking will fail during the parametric sweep. Setting this very high will make the simulations take longer.
• config.simulation.overlap_threshold [optional - default: 0.6] is a number (fraction of 1) containing the overlap required for a mode to be considered a "match" while doing the parametric sweep. If this is set too high, the algorithm will not be able to identify the matching mode from one parameter value to the next. If it's set too low, it may select the wrong mode from one parameter value to the next, and therefore produce erroneous sweep results.
• config.simulation.width_buffer [optional - default: 1.5e-6] is a number containing the amount of space to put between the edge of the waveguide in the width direction and the edge of the simulation region (in meters). Setting this higher will produce more accurate simulations (since the boundary will be further from the mode center), however the simulation time will be increased.
• config.simulation.height_buffer [optional - default: 1.5e-6] is a number containing the amount of space to put between the edge of the waveguide in the height direction and the edge of the simulation region (in meters). Setting this higher will produce more accurate simulations (since the boundary will be further from the mode center), however the simulation time will be increased.
• config.simulation.curvature_buffer [optional - default: 1e-6] is a number containing the amount of additional buffer to introduce to the width_buffer when simulating curved waveguides.
• config.simulation.mesh_override_dx_dy [optional - default: 10e-6] is a number containing the cell size of the mesh-override placed at the corner of the waveguides (in meters). This mesh override is used to ensure that there is always a cell boundary at the material boundary (mesh grid has overlap with the edges of the waveguide). Setting this value too high may mean that the simulation mesh won't have a boundary at the material boundary. If you are unsure that the simulation mesh will be appropriate, it's recommended that you set config.simulation.save_sim_files to true, and inspect some of the simulation files saved during the parametric sweep to ensure they have a proper mesh.
• config.simulation.set_target_mesh_by_dx_dy [optional - default: false] is a flag which determines how the FDE will determine it's target mesh. If it's set to true, then the simulations will use dx and dy to determine the target mesh, otherwise they will use the number of cells to determine the target mesh.
• config.simulation.FDE_mesh_cells_x [optional - default: 50] is an integer containing the target number of mesh cells in the x (width) direction for the FDE simulation region. This is only used if config.simulation.set_target_mesh_by_dx_dy is false.
• config.simulation.FDE_mesh_cells_y [optional - default: 50] is an integer containing the target number of mesh cells in the y (height) direction for the FDE simulation region. This is only used if config.simulation.set_target_mesh_by_dx_dy is false.
• config.simulation.FDE_mesh_dx [optional - default: 40e-9] is a number containing the target mesh cell size in the x (width) direction for the FDE simulation region (in meters). This is only used if config.simulation.set_target_mesh_by_dx_dy is true.
• config.simulation.FDE_mesh_dy [optional - default: 40e-9] is a number containing the target mesh cell size in the y (height) direction for the FDE simulation region (in meters). This is only used if config.simulation.set_target_mesh_by_dx_dy is true.
• config.simulation.PML_layers [optional - default: 16] is an integer containing the number of PML layers to use for the boundary conditions of the FDE simulation region.
• config.simulation.use_PML_on_top_and_bottom [optional - default: false] is a flag which determines whether or not PML boundaries should be used in the y (height) direction. Setting this to true will reduce numerical error but also increase simulation time.

Override

The override module provides several data processing options which ensure that the compact model will behave as expected.

• config.override.type is used to select which method of data override is desired for optical index information (neff/ng/D). There are three options: “prioritize_simulation”, “lock_to_external”, and “prioritize_external”.
  • “prioritize_simulation” will use optical index information (neff/ng/D) from simulation in the final model. External values for this option will only be used to compare simulation and external results (see config.override.force_match)
  • “lock_to_external” will process the simulated optical index information (neff/ng/D) such that it matches externally provided data at the center of each frequency band. For more information on how this is done - see the section on locking simulation results to external data.
  • “prioritize_external” will use external data wherever possible, and fill in missing optical index information (neff/ng/D) with results from simulation. If any information is missing from the external dataset (for example - waveguide dispersion is not measured), or if the enforce_consistency option is set to ‘true’, the resulting combined data will be processed to ensure self consistency in the final model data. For more information on this processing, see the section on enforcing consistency. 
• config.override.loss_type is used to select which method of data override is desired for waveguide loss. There are three options: “sum”, “use_external”, and “use_simulation”.
  • “sum” will take the sum of the loss from simulation and from external data for use in the final model. This is appropriate for most cases - where the user provides measured roughness loss and adds radiative loss from simulation results. Use this if you want your final model to have variable radiative loss due to curvature, but don’t have this information in your external dataset.
  • “use_external” will use only externally provided loss values for the final model. Use this option if you’re confident in the provided loss values and don’t want to use any data from simulation
  • “use_simulation” will use only simulated loss values for the final model. This option should only be used if you cannot obtain loss values experimentally. The loss values of the final model will likely differ greatly from reality using this option, since it is not easy to capture losses from waveguide roughness in simulation.
• config.override.force_match is used to force a close match between values from simulation and experiment. Set this to “true” if you want the workflow to terminate when there is significant mismatch between simulation and experiment, and set it to “false” if you want the flow to continue regardless.
• config.override.X_tol [where X is “neff”, “ng”, or “D”] is the relative tolerance for comparing simulation and experimental results. The workflow will either throw a warning or terminate if the mismatch between simulation and experiment exceed this value, depending on the “force_match” setting.
• config.override.enforce_consistency is only used when the “prioritize_external” option is selected, or simulation data is disabled and processing of the external data is desired. Set this to true if you want to ensure consistency even in the case where data is only sourced from the .csv file, and not from the simulation.
• config.override.X_enf_tol [where X is ‘neff’, ‘ng’, ‘D’] is the allowed relative tolerance for doing the polynomial fit of each of neff/ng/D. For more detail on how this is used, see the section on enforcing consistency. 

     Optional Settings

• config.override.model_order [optional, default - 3] is the polynomial fit order to start with for the consistency enforcement algorithm. For more detail on how this is used, see the section on consistency enforcement.
• config.override.model_type [optional, default - "prioritize_external"] is the method used for combining information from neff/ng/D when doing consistency enforcement. Options are "mean", "highest_order", "prioritize_external", or "prioritize_X" where X is neff, ng, or D. For more information on how this is used, see the section on consistency enforcement.

Height Sensitivity

The height sensitivity module provides options to find the sensitivity of mode data to core thickness from simulation to generate a statistical compact model having delta_height as one of the statistical parameters..

• config.height_sensitivity is a flag which determines whether or not height sensitivity information needs to be extracted from simulation. 
• config.height_sensitivity_sigma  is core thickness standard deviation in meters. This values is also used as the normalization factor to record mode data height sensitivity in the output data file. 

Visualization

The visualization module shows visualizations of the data as it’s processed, as well as the final dataset going into the compact model. It has several options, all of which have default settings - so if you’re okay with just using the default visualizations, you can skip this section. Configuring this module is optional.

• config.visualization.show_processing is a flag which determines whether or not the data processing should be visualized. If set to true, the workflow will show visualizations whenever the locking algorithm or consistency enforcement algorithms are used.
• config.visualization.param_values is a vector which contains the default parameter values for visualizations. This is used for determining which cross-section of the data to show in all visualizations throughout the flow. This should be provided in ["wavelength value", "width value", "curvature value", "temperature value", "mode ID"] order. 
• config.visualization.show_final_data is a flag which determines whether or not the final model data should be visualized. When set to true, the workflow will plot the data after all processing and before exporting into the CML Compiler source files.
• config.visualization.data_to_plot is a cell array containing the list of data to plot throughout the workflow. The contents of the cell array must be strings matching “neff”, “ng”, “D”, or “loss”. If this is not provided, the workflow will show as much data as is relevant for each step.
• config.visualization.dimension_to_plot is a string containing the dimension to use as the x-axis for the final data visualization. This string should match “wavelength”, “width”, “curvature”, “temperature”, or “mode”.

Data Processing

The waveguide flow is equipped with several data processing techniques which ensure that the resulting compact model will behave as expected within INTERCONNECT. All of the data processing techniques ensure that waveguide data (effective index, group index, and dispersion) satisfy the dispersion equations:

There are three different methods used within the flow to ensure these are satisfied, applied for specific types of input data and workflow configurations. This section will describe the three processing techniques, and what types of data they are appropriate for.

Locking Optical Index Data (to a few points)

When the locking algorithm is selected for the data override, the workflow will generate the final dataset by perturbing the simulation results to match the external data. The goal of this process is to allow easy creation of accurate compact models while requiring the minimum amount of measured results. This algorithm is capable of capturing parametric variation of the waveguide from simulation while matching a few externally provided data points exactly.

More specifically, the workflow will calculate the coefficients of a 3rd-order perturbation polynomial for the effective index. This process is done separately for each frequency band, waveguide mode, and parameter set (width, curvature, temperature) for which external data is provided. Then, the workflow will linearly interpolate these coefficients onto the final set of waveguide parameters, and apply the resulting perturbation to the entire set of simulated data. The result is a dataset which preserves any variation which is present only in the simulated dataset, and matches the external data at all of the provided points.

Enforcing Consistency (for highly-sampled datasets)

The consistency enforcement algorithm is used when highly sampled external data is provided. It can handle measurement noise/uncertainty, or filling in missing data (effective index, group index, and/or dispersion) without simulations. When the consistency enforcement algorithm is used, the workflow will generate the final dataset by doing a polynomial fit for neff/ng/D. The values for neff/ng/D may be sourced entirely from external data, or partially from external data and partially from simulation results, depending on the setting config.override.type.

This processing ensures that the final dataset will produce a smooth spectrum in INTERCONNECT, while matching a highly-sampled external dataset as accurately as possible. When this method is not applied, inconsistencies within the optical index information can cause inflection points in INTERCONNECT results.

More specifically, the algorithm functions by obtaining the polynomial coefficients of effective index, group index, and/or dispersion around the center of each frequency band and for each set of parameters. For group index and dispersion fits, the equivalent effective index expansion coefficients are calculated according to the dispersion equations. Using this method, multiple sets of coefficients for effective index are obtained, and they may differ. "Self-consistency" is enforced by combining the coefficients obtained from each piece of optical index data, and then reconstructing all optical index data from the combined coefficients.

There are multiple different options for taking combining coefficients - which are chosen by modifying the optional setting config.override.model_type.

• "prioritize_external" will weigh coefficients obtained from external data many orders of magnitude higher than coefficients used from simulation - effectively using the external coefficients wherever possible. This will cause the final model to match external values as close as possible. [This is the default option when both simulation and external data are used].
• "highest_order" will use the coefficients obtained from optical index data corresponding to the highest order derivative of effective index whenever possible. For example, if both effective and group index are provided (but not dispersion), then this algorithm will use the first coefficient from effective index, and all higher-order coefficients from group index. If dispersion is provided as well, the algorithm will use the first coefficient from effective index, the second coefficient from group index, and all higher-order coefficients from dispersion. [This is the default option when only external data is used and consistency enforcement is enabled]
• "mean" will weigh all coefficients equally. This is most appropriate when the expected accuracy of all optical index data is equivalent.
• "prioritize_X" [where X is "neff", "ng", or "D"] will weight the coefficients from a particular optical index (or dispersion) fit many orders of magnitude higher than the other values. This option is most appropriate when multiple values come from external data, but the measurement accuracy of one of the sets is much higher than the others. For example - if external data is provided for effective index and group index, but the effective index values are deemed less accurate than the group index values - this option should be set to "prioritize_ng".

Using a Polynomial Expansion

The third and final type of data processing is only applied when you have a set of polynomial coefficients available for effective index. This method takes those coefficients and expands them into the appropriate dataset for CML Compiler. Coefficients must be provided in the proper format (see the sections on CSV Data File Format and Data Layout). The method assumes that the coefficients are for an expansion in the units of meters around the center of the frequencies in the CSV file. This method is only applied if config.simulation.use is set to false, and the external dataset contains polynomial coefficients as shown in Template #3.

If necessary, the workflow will first expand these coefficients from a semi-sparse or sparse grid into a dense grid. Then, the workflow will loop over the entire set of frequency bands, parameter values, and waveguide modes to construct the optical index data according to the optical index equations. The result is a dataset which is prepared for use within CML Compiler, and is entirely defined by externally provided data.

Automatic Simulation

The waveguide flow is capable of automatically generating, running, and gathering data from FDE simulation sweeps of a variety of waveguides. It is equipped with a default simulation setup which can be configured using the inputs described in the Workflow Configuration, and is appropriate for simulations of silicon and silicon nitride slab waveguides. Currently, the automatic simulation module can only run sweeps over waveguide width, curvature, and temperature - therefore limiting the parameters which can be captured by the flow to these three.

In order to automatically sweep various geometric parameters and keep track of optical index data (neff/ng/D), a sophisticated mode-tracking algorithm was necessary. This is particularly important for tracking TM waveguide modes, since geometric variation can change their mode orders within FDE simulation results. Modes are tracked by keeping and updating a collection of previous mode profiles, and determining the corresponding modes in new simulations according to their overlap with this collection.

The Default Simulation File

If no simulation file is provided within the working directory of the workflow, a default simulation file will be used. The default simulation file contains configurable geometry for single-material waveguides with strip or rib geometries. The following diagram shows how some of the configuration variables in the Simulation section correspond to simulation geometry.

The cladding in the default simulation file is set to SiO2, and the waveguide material is modified by changing the string config.simulation.material. To use custom material data in the simulation file, modify the routing_waveguide.lms file in the working directory after the workflow has been run at least once.

Notice the mesh override regions at the corners of the waveguide geometry. This is to ensure that there is a simulation cell boundary at the material boundaries.

Statistical data collection (for parameterized waveguides only)

The waveguide workflow can generate a data file to build a statistically enabled compact model using CML Compiler. To do that, "stat_parameters" cell should be present in all desired waveguide types configuration files under "input_data" folder. This cell should be provided as described here. Different statistical parameters can be considered in the workflow which is described below. For an example please see templates\wg_6_statistical_experimental_loss_ng\input_data\wg_stat_X_straight_parameterized_model_config.lsf.

• "waveguide parameters": Waveguide parameters that the workflow supports ( eg. width, curvature and temperature ) can be set as a statistical parameter if multiple parameter values are defined in the "final device grid" section of the collection script. Since information for mode data vs parameter will be included in the workflow output data file, CML Compiler is able to find mode data sensitivity to the parameter automatically. To link a statistical parameter to a waveguide parameter, "use_parameter_data" field in the "stat_parameters" cell should be set to the parameter name (eg. "width"). In this case "normalization_factor" field also should be included in the "stat_parameters" cell to normalize the parameter sensitivities. 
• "FOMs": Waveguide Figure of Merits (FOMs), eg. loss, can be set as statistical parameters. In this case "stat_parameters" field for this statistical parameter should include sensitivity information from experimental data, eg. slope_loss. 
• "delta_height": waveguide core thickness can be set as a statistical parameter. In this case "stat_parameters" cell in the configuration file should contain "delta_height". If mode data sensitivities to core thickness is known, they should be provided in the "stat_parameters" cell.
  Mode data sensitivity to core thickness can also be extracted by the workflow automated simulation. height sensitivity section of the collection script should be set to true and the standard deviation be provided. Using this information, the simulation will be run for three core thickness values: nominal thickness, nominal thickness+config.height_sensitivity_sigma and
  nominal thickness-config.height_sensitivity_sigma for one point in the parameter set (the smallest value of each waveguide parameter) for all frequency points for all modes. The average value for the slope_neff, slope_ng and slope_D for each frequency band then will be added to the "delta_height" "stat_parameters" cell in the output file.