GDS Update

[smartalecH]

The MEEP docs mention that MEEP intends to support GDS import/export come mid 2018.

Can the community contribute in any way? There are several of us interested in developing/using this feature. Before we start from scratch, we'd like to know what's been done and what the intended direction is.

Maybe we could start a "project" for this feature?

[oskooi]

@HomerReid has been leading the development of this feature. Currently, we are working on adding a new prisms object to the material geometry (#218). This will facilitate GDS import/export. A previous PR (#38) had attempted to provide this functionality but unfortunately the geometry library (libmeepgeom) had limitations then when calling from C++. These have since been resolved.

Perhaps you can provide some examples we can use for testing?

[HomerReid]

I second Ardavan's request for examples---if you have any GDSII files for geometries you'd like to study with meep, that would be very helpful.

Also, one open question is how to specify the thicknesses and material properties of layers, since the GDSII geometry primitives only describe 2D cross-sectional profiles, and there seems to be no universal convention for embedding layer thickness/material information in the file itself or in accompanying files. If you have ideas on how to handle this we'd be interested in suggestions.

[smartalecH]

Absolutely! I have several test files I can provide. Do you prefer me to upload them to the project via a pull request?

Most commercial simulator packages I've used rely on the user to specify thickness/material properties after the import. I've also used some design apps that interface with the simulator directly by providing the geometry in GDSII and the properties in another arbitrary file format.

While not the most elegant, a simple function that reads in the GDS file, the cell, and optional properties would probably be the most flexible:

polygonObject = importGDS("filename.gds","cell name", layerNumber, thickness, center, myMediumObject)

A general structure like this makes it easy to interface design packages (like KLayout) with Meep.

[HomerReid]

If you could just post a couple of your sample GDSII files here, or email them to me, that would be great.

Also, your proposal for how to specify layer thickness and material information sounds good---it seems unfortunate that the geometry description would be split into two separate pieces (one describing layer cross sections and the other describing layer thicknesses and materials), but it seems that's standard practice for GDSII files, and this will certainly be easy to implement.

[smartalecH]

Great to hear. I attached several silicon photonic devices stemming from UBC's SiEPIC Design Kit.

sampleGDS.zip

For large, complex structures, would it be advantageous to generate a "material_function" rather than individual prisms? For example, Bragg gratings could contain thousands of individual prisms that compose the entire structure. I've read that native MEEP geometries perform much faster than material_functions, but I'm not sure how well that scales with size.

Designs that use Bezier curves will also have a similar problem (since the GDS compiler rasterizes the curves to the grid).

Let me know if there is any other way I can contribute.

[HomerReid]

Thanks for these helpful sample files.

As you suggest, any geometry that will be possible to simulate with meep's built-in GDSII support can already be studied by writing a user-defined material function, and then the performance will be determined by how quickly your material function (which will be called for every pixel in the entire simulation grid) runs. For small to moderate-scale problems there should be little performance difference either way. The main issue is that meep doesn't do subpixel averaging for user-defined materials, so in general you will need to run at higher grid resolution to get the same accuracy for physical output quantities. Of course, with a little effort you could effectively implement the subpixel smoothing yourself in your user-defined material function, but making this computationally efficient requires some effort, so whenever possible it's best to define geometries as unions of the built-in geometry primitives (including the new extruded-polygon primitive that will be available when GDSII support is ready) for which the computational optimizations needed for fast subpixel smoothing are already implemented for you.

As for Bezier curves, in most cases the polygonal approximants produced by GDS compilers should be perfectly adequate, as differences between a smooth curve and its rasterized version should exist only on lengthscales that are too small to affect the simulation---if the quantity you are trying to compute is sensitive to such fine-grained details you're going to have trouble with any finite-difference approximation.

You could try playing around with this already, by defining an elliptical object

• (a) exactly using the built-in ellipse primitive,
• (b) approximately as a collection of N blocks sized and positioned appropriately so that the union of their outer boundaries approximates the ellipse.

For any physical quantity that you can expect to compute accurately in FDTD, results for case (b) should converge rapidly to those for case (a) already at moderate values of N.

[smartalecH]

Thank you for your comprehensive response. I look forward to the release.

[raghavendra-swamy]

Dear all,

• First of all I want to thank you soo much for providing wonderful open source software and also providing constant support to it by adding new feature like GDSII, which can be used for tape-out of chip / IC fabrication.
• I read through the whole conversation on the GDSII import/export support. Currently I see that GDSII files can be imported into the meep environment, but can you confirm that the meep script created designs can directly exported to GDSII format instead of HDF5.

Again, Thank you.

[oskooi]

Closed by #357, #392, and #495.