GDSII integration and Basic Shape/Structure Definitions

[tfryett-zz]

It would be helpful to have direct support of GDSII files (i.e. both importing into MEEP geometry and exporting). This would appeal to many researchers who use FDTD methods to optimize photonic crystal cavities, or other nanodevices which then require the pattern to be written to a GDSII file for fabrication. Furthermore, it would be helpful to include a quick and simple way to add common geometries such as circles, rectangles, to aid in rapid development.

[stevengj]

There are certainly lots of CAD formats out there that could be reasonable to import from; DXF is another one. GDSII seems to be defined by a sequence of layers (piecewise-constant cross-section) of polygons, and it would be pretty easy to write a routine to read this and evaluate whether points are in polygons to define the dielectric function (would have to be in C++ for efficiency). Of course, you'll have to figure out how to assign epsilon values to these polygons (via some annotation in the file?).

I'm not opposed to this sort of thing, but I've never been motivated to write such code myself. GUI interfaces for setting the geometry have never seemed useful to me for our own work in Meep and MPB, because we never do simulations with a single geometry—in our research, we are always looking at lots of related geometries produced by varying different parameters, so it has always been more convenient to control the geometry with a script. GUIs are good for drawing a structure once, and are friendlier for first-time users.

[tfryett-zz]

I am actually in complete agreement with you about CAD programs - I find it to be faster and easier to script the geometries, and find CAD GUIs to be rather cumbersome. My motivation is simply to streamline the design and fabrication process as GDSII is the standard file format for electron beam lithography (aka nanolithography) stoftware which is required to make devices such as photonic crystals which typically have feature sizes on the order of 10 nm.

I was actually also thinking of making a GUI interface as my following contribution, but the main point would not be to replace scripting, but provide fast feedback for what the geometry you have defined actually looks like so you can quickly implement the geometry you had in mind. But that is a large project that is not in the near future.

[stevengj]

@tfryett, that makes sense to me, and a GDSII import function would be welcome.

One option would be to handle it similarly to the epsilon-input-file functionality currently in Meep (which reads ε from an HDF5 file). You would specify the GDSII file, which would be loaded in and parsed, and there would be a C++ function to evaluate a point and test what polygon of the GDSII file it is in (and hence what ε). This would then be used as a replacement for default-material — i.e. any other geometry objects would go on "top" of the GDSII file.

However, I'm not very familiar with GDSII. Is it just a 2d format? If it is only 2d, then you will need to somehow specify where and how thick it is in the computational cell. One possibility would be to instead define a GDSII file as a kind of "material" that you can assign to an object, like a block. Then you place the block wherever you want in the computational cell, and fill it with the GDSII "material", which really "draws" the GDSII file inside the block. See, for example, the (undocumented) material-grid type in MPB, which is implemented in roughly this way to fill an object with a 1d/2d/3d grid of values (used for topology optimization).

[tfryett-zz]

@stevengj GDSII is a 2D format. Usually what happens is that you use the pattern to extrude to a 3D object (this is what Lumerical FDTD does). I think both of your suggestions are good, but I think I should read more of the source code so I can have a better idea of how the implementation will actually work for each case so that I can make a more informed decision.

[soamaven]

probably ya'll can close this one now? :)

[oskooi]

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