Creating Paths

[dha010]

Hi,

I am wondering whether it is possible to make Nazca create paths in some cases, as in a center line and a width, instead of polygons?

[Ronald]

Dear dha010,

The viper method may be what you are looking for, see

viper() method

Ronald

[dha010]

Hi Ronald, thanks for the reply.

Indeed that does what i need, at least logically. However in the exported gds file, the output is still a polygon. I need to have the structure defined as a path in the gds file itself due to requirements for some processes by a foundry. As far as i can tell Nazca always uses polygons or boxes, and i am wondering if there is a way of changing that? Or some methods that do output paths?

See example at http://s000.tinyupload.com/?file_id=90343711839218552542

In this case the upper structure is defined as a rectangle, while the lower one is defined as a path.

Daniel

[Ronald]

Dear Daniel,

I may have over interpreted your question.
For a path (polyline) simply use the Polyline method:

import nazca as nd
nd.Polyline(points=[(0, 0), (10,0)], width=3.0, layer=2).put(0)
nd.export_gds()

Ronald

[dha010]

Dear Ronald,

 

The only problem now is that as far as I can tell most other methods to create structures, like bends and curves etc. all seem to employ polygons rather than polylines.  I guess I’ll just have to make these myself then

 

thanks

[Ronald]

Dear Daniel,

Polygon discretization can be more accurately controlled than polylines. Also, the latter have to be “interpreted” leading to a less deterministic outcome in various readers than polygons. Another limitation for polylines is that they can not describe a change in width or an asymmetric waveguide. Hence, Interconnect objects in Nazca use polygons to describe waveguides (and e.g. metal lines).

There may be other situations where you want to use polylines. You still can use Interconnects.py methods to get to polylines. Polygons are only the final step in creating interconnects. Each interconnect has a “_solve” method that returns a polyline/path. Hence, call the _solve method to get a path = [(x1, y1), (x2, y2, …], which you then use as nd.Polyline(points=path, width=2.0).put().

Alternatively, it is quite straight forward to add a switch to mask_elements.py methods to produce a polyline rather than a polygon, with the above mentioned limitations of polylines.

Ronald

[dha010]

Dear Ronald,

 

Yes, I can see there are benefits to using polygons rather than polylines, and I am not trying to argue the case for general use of polylines instead.

I’ve had a look at the Interconnects.py methods. They do not return a set of points, rather parameters that define the geometry. However implementing some functions that parse the parameters and spits out the required list of points should not be too much work I think. Or as you say, modifying the mask_elements methods could also be a solution.

Thanks for the help!

DAniel

[Ronald]

Dear Daniel,

Indeed, the interconnects were a step too high up (they return lists of connecting elements) and true that you didn’t argue for polylines as polygon replacement. See it as general background information in the discussion as this topic pops up now and then.

I had a look a few days ago into the polylines when defining interconnects, and actually I implemented the polyline already as an option when adding a layer to a xsection (setting polyline=True) for some elements (strt, bend, taper). The execution is mainly in mask_elements.py. It will be available in Nazca-0.5.6. Having polylines in a xsection can be useful in some EBPG processes. There is a catch though: The interconnects generate a set of connecting polylines, not a single long polyline. Not sure if that would ruin the party for your use case. If you could share how you use polylines that may help defining a better implementation if needed.

Ronald

[Author]

Posts