document pcells implicit dependency on gdsfactory

[proppy]

When starting klayout, the following error is raised when gdsfactory is not installed causing the pcells not to load:

ERROR: /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/draw_fet.py:22: No module named 'gdsfactory'
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/draw_fet.py:22
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/fet.py:19
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/cells/__init__.py:21
  /home/proppy/silicon-2-env/share/pdk/gf180mcuC/libs.tech/klayout/tech/pymacros/gf180mcu.lym:9 (class ModuleNotFoundError)

This effectively means that the PDK is now dependend on gdsfactory, we should make sure that this is explicitly documented (as most people won't have it installed by default when using klayout and/or volare).

My feelings is that we'd prefer the base klayout integration not to depend on gdsfactory, and have a separate gdsfactory based PDK similar to what @joamatab did with https://github.com/gdsfactory/skywater130/.

curious what @mithro and @joamatab thinks?

[proppy]

Looks like the dependency was introduced in 5805c8f

[joamatab]

yes, i agree that we should keep the gdsfactory PDK separate from the pure klayout PDK, so we avoid implicit dependencies
the gdsfactory flow is meant to be used for the python scripted flow and should be install-able through pip

if you want to keep it this way we can create a klayout package for gdsfactory and gf180 pdk and mark it as a dependency

[atorkmabrains]

@proppy and @joamatab

We had the pure klayout implementation before. Due to the more powerful tools provided with gdsfactory, I decided to remove the pure klayout implementation. gdsfactory has very strong tools allowing easier manipulation of pcell code and parameterization.

BTW, https://github.com/gdsfactory/skywater130/ might be old implementation for the pcells and also this repo is for skywaters which different than gf180mcu pcell implementation.

As for the requirement of GDS factory, Please check the requirements.txt file. It lists gdsfactory as a requirement.

[atorkmabrains]

@FaragElsayed2 Could you please add the documentation that the user need to install the requirements.txt?

[proppy]

As for the requirement of GDS factory, Please check the requirements.txt file. It lists gdsfactory as a requirement.

But that would get installed in the Python environment embedded in klayout per default, and gdsfactory also brings native dependencies like gdstk that mirror some of the functionality already present in klayout.

BTW, https://github.com/gdsfactory/skywater130/ might be old implementation for the pcells

That's a PDK specifically for gdsfactory, so it's meant to be used outside of klayout when working directly on a design with gdsfactory.

We had the pure klayout implementation before.

That seems desirable to keep this for the klayout integration, and to have a separate gdsfactory PDK for usage within the gdsfactory ecosystem.

[atorkmabrains]

@proppy https://github.com/gdsfactory/skywater130/ was written to work with Klayout mainly using gdsfactory backend.

[atorkmabrains]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

[proppy]

@proppy https://github.com/gdsfactory/skywater130/ was written to work with Klayout mainly using gdsfactory backend.

I don't think that's the case, according to https://gdsfactory.github.io/skywater130/notebooks/intro.html this is mainly design for interactive/scripted usage within a regular python environment outside of klayout.

[proppy]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment.

Additionally, this most likely would end up installing the klayout wheels inside the klayout python environment (since gdsfactory depends on it), so I'm assuming we'll effectively end up with two duplicate copy of klayout pya and klayout.db within the same process?

[atorkmabrains]

I don't think that's the case, according to https://gdsfactory.github.io/skywater130/notebooks/intro.html this is mainly design for interactive/scripted usage within a regular python environment outside of klayout.

@proppy We are the ones who developed those pcells. @joamatab took what we have and taken our backend implementation to demonstrate how gdsfactory works for analog pcells as well.

Our intent was to allow both use cases, scripted through gdsfactory and interactive using klayout with the same backend implementation.

@joamatab Could you please comment on this?

[atorkmabrains]

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment.

Additionally, this most likely would end up installing the klayout wheels inside the klayout python environment (since gdsfactory depends on it), so I'm assuming we'll effectively end up with two duplicate copy of klayout pya and klayout.db within the same process?

yes it may have some issues. but careful usage and documentation should help. For the interactive user, it would be seamless according to our testing.

[proppy]

@proppy We are the ones who developed those pcells. @joamatab took what we have and taken our backend implementation to demonstrate how gdsfactory works for analog pcells as well.

Are you referring to this PR? gdsfactory/skywater130#40

Our intent was to allow both use cases, scripted through gdsfactory and interactive using klayout with the same backend implementation.

Wouldn't it make sense to use klayout 'pya` as the lowest common denominator? is gdsfactory able to import a klayout pcells and expose them as a component?

The alternative could be to make the backend of gdsfactory plugable, so that it can work both when embedded in the klayout app (importing pya) and in standalone mode using using pypi's klayout (importing klayout.db).

@proppy My thought process is that whatever is working at the backend. It doesn't matter for the end user as long as the pcells are generating the correct output.

This does have some implication on packaging, and making sure the dependencies are accessible from the klayout environment: Klayout has it's own way to discover python dependencies which differ from platform to platform, see the paragraph on https://www.klayout.de/doc-qt5/programming/python.html#:~:text=The%20Python%20macro,Python%20%3E%3D%203.x). about KLAYOUT_PYTHONPATH usage.

yes it may have some issues. but careful usage and documentation should help. For the interactive user, it would be seamless according to our testing.

Currently the PDK is distributed as a standalone archive thru volare which doesn't include an automated way to python -m pip install additional dependencies.

gdsfactory also comes with a lot of dependencies that you don't actually need for drawing pcells (netlist editing, routing, 3d rendering, simulator interface, etc), so unless the primitive are exposed as separate package (https://github.com/gdsfactory/kfactory?) you would require the users to install transitively a lot of unecessary packages.

On possibility avenue could be to bundle the drawing primitive from gdsfactory as a standalone pure python module that we vendor and distribute with the klayout pcells as part of the pdk build process.

Maybe https://www.klayout.de/doc/about/packages.html#:~:text=the%20subversion%20equivalent.-,Installation%20Hooks,-Scripts%20can%20register could be useful here, if we were packaging the klayout integration as a klayout package, we could rely on hooks to fetch/install dependencies.

@klayoutmatthias @joamatab @mithro any thoughts here?

[mithro]

@joamatab - Any thoughts?

[joamatab]

At the moment, the gdsfactory klayout package only contains the gdsfactory klayout integration (live updates, shortcuts ...)

We can register gdsfactory as a klayout package and mark it as a dependency for the gf180mcu-pdk

[atorkmabrains]

@proppy and @mithro original PCells for skywaters 130nm written using GDS Factory: https://github.com/efabless/sky130_klayout_pdk/tree/main/sky130_tech/tech/sky130/pymacros/cells

[joamatab]

it actually works well on linux, but probably not yet on MacOs and Windows

you can install gdsfactory as part of the pdk initialization

aa99e01

[joamatab]

Amro, the run drc does not work from the macro @atorkmabrains

[proppy]

@joamatab is gdsfactory using pya and not klayout.db when ran inside klayout?

[joamatab]

gdsfactory uses klayout.db only, but is an optional dependency for nicer visualizations

the way mabrains did gf180 is different from the skywater 130nm pure python package (which does not use klayout API at all)
i prefer this type of packaging where you can pip install sky130

in the sky130 the klayout integration provides layercolors, DRC ... but not PCells on the GUI

[proppy]

@joamatab the thing I dislike about the current gf180mcu pcell integration, is that it will leverage gdsfactory to save a temporary gds file to disk and then re-read it thru klayout API to integrate it in the current layout, see:
https://github.com/efabless/globalfoundries-pdk-libs-gf180mcu_fd_pr/blob/main/cells/klayout/pymacros/cells/draw_fet.py#L2693-L2694

If we want to use an higher level API like gdsfactory, I'd prefer us to do so on top of existing klayout pya primitive, maybe kfactory could allow this? (see gdsfactory/kfactory#53).

[proppy]

Another question for @joamatab, would it make sense to provide an alternative klayout backend in gdsfactory, where pya or klayout.db/lay can get used instead of gdstk when serializing the cells here:
https://github.com/gdsfactory/gdsfactory/blob/9c2c9727642eff8f877e717e76218249283b5c78/gdsfactory/component.py#L1709-L1713

Happy to contribute here too if you think it makes sense.

[sebastian-goeldi]

There is a test ongoing for that. For that case I wrote the CplxKCell https://github.com/gdsfactory/kfactory/blob/main/src/kfactory/kcell.py#L1620 . This will allow a rather quick integration of kfactory into gdsfactory

Although these cells have a risk of being off grid unless proper care is taken (no safeguards in there yet).

[sebastian-goeldi]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore.

Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python.

And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

[atorkmabrains]

Thanks @sebastian-goeldi .

Appreciate this summary.

[atorkmabrains]

@sebastian-goeldi and @proppy Caravel chip "Without user design" has around 1 million to 2 million polygons for diffusion and poly alone.

BTW, @sebastian-goeldi I'm not undermining Klayout at all. For me it's an amazing tool. An it's the open source tool of choice for editing and viewing layouts. But when it comes to DRC/LVS and other heavy batch processing jobs like layer manipulation, basic pcell generation, ease of automation for layout, I think gdsfactory wins in that space.

[proppy]

Caravel chip "Without user design" has around 1 million to 2 million polygons for diffusion and poly alone.

And what is average number of polygons for the gf180 primitives instantiated by the PCells we've been discussing here?

[atorkmabrains]

@proppy It's very low (20 to 100 polygons). That's not the problem. Again, the main driving factor here is the advanced relative layout functionality that comes with gdsfactory.

[sebastian-goeldi]

No worries. I know that the klayout API seems not super user friendly when coming from a python world. I just got it a lot that "klayout is so complicated". And I understand where the people are coming from, but I disagree. It has a steeper learning curve, but once there, I personally like it so much more (and the people that I know that invested the time to learn it a bit as well). I don't want to create a new cell every time just for a boolean (especially in photonics) for example, which is the case in gdstk/gdspy.

And I think overall, kfactory aims to do the same thing as gdsfactory when it comes to usability and features. So, you wouldn't need to load everything in the layout, you can just hook into the layout, or at works copy on a C++ level from one layout to another (whichever is preferable).

[atorkmabrains]

On side note, @sebastian-goeldi we are working with @klayoutmatthias to optimize the performance of klayout DRC/LVS engine. We have done and advanced profiling for the klayout C++ core code and issues that we will open source soon to understand the the bottlenecks in klayout.

Thanks to @klayoutmatthias, he helped a lot optimizing our DRC code for large layouts.

Just FYI, I have digged in klayout C++ deeply, I understand how it works in and out specially for DRC/LVS side.

[klayoutmatthias]

@atorkmabrains It's good news you understand the C++ code!
That means
1.) It is comprehensible
2.) You can explain it to me
Nope, sorry. Just kidding on 2.) :)

Matthias

P.S. do you plan to attend FSiC2023 in Paris?

[klayoutmatthias]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore.

Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python.

And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

There is no specific measure to make sure polygons are well-behaving. The only compromise KLayout makes is to create a copy of the polygons that go into the target layout. If you're talking about Python-generated layout, it's for sure unrealistic to have 1-50meg polygons generated by Python. C++ PCells are possible which may be able to generate such big things, but in general PCells are not the right place to put elaborate algorithms into. That is the domain of generators which produce ready-to-integrate and verified hard macros such as the OpenRAM generator.

For fun this creates a C++ PCell (Basic library) with something like 1..2M polygons:

ly = pya.CellView.active().layout()
top_cell = ly.top_cell()

text = []
for l in range(0, 1000):
  line = ""
  for t in range(0, 125):
    line += "%07d " % (t + 125 * l)
  text.append(line)
text = "\\n".join(text)
  
long_text = ly.create_cell("TEXT", "Basic", { "text": text, "layer": pya.LayerInfo(1, 0) })
top_cell.insert(pya.CellInstArray(long_text.cell_index(), pya.Trans()))

It executes in a few seconds in my case (only a very small portion shown):

[atorkmabrains]

@atorkmabrains It's good news you understand the C++ code! That means 1.) It is comprehensible 2.) You can explain it to me Nope, sorry. Just kidding on 2.) :)

Matthias

P.S. do you plan to attend FSiC2023 in Paris?

A little bit rusty, but it's there. The last time I coded serious C++ was about 12 years back, LOL.

Unfortunately, I was hoping to attend the conference. But I can't may be next year.

[atorkmabrains]

Yes, so then a small remark. For a layout with 1-50 mio polygons, KLayout PCells are definitely the wrong choice, no matter whether you want to use gdstk or klayout. You will get retired by the time you are done. I understand that klayout is a lot slower when it comes to loading polygons etc. Afaik that is due to KLayout making sure the polygons are well behaved, which gdstk (and gdspy for that matter) ignore.
Also, when doing such a boolean, it is important to utilize the proper tools, e.g. klayout can do booleans hierarchical by using the deep shape storage. Also for XOR there are tools that can use the tiling mode in order to split the work on more workers and do it directly internally instead of having to go to ruby/python.
And finally, when using the PCells of the UI, if you have concerns about the stability, I think that might be much more related to the PCell interface rather than the actual core KLayout parts. In my previous project, I found that the PCells sometimes execute code twice (or at least used to), so that can can give you a gigantic performance hit if not properly taken care of. gdsfactory takes care of that (kinda) by caching the cell functions. This is also possible by using a klayout backend (kfactory for example does this).

There is no specific measure to make sure polygons are well-behaving. The only compromise KLayout makes is to create a copy of the polygons that go into the target layout. If you're talking about Python-generated layout, it's for sure unrealistic to have 1-50meg polygons generated by Python. C++ PCells are possible which may be able to generate such big things, but in general PCells are not the right place to put elaborate algorithms into. That is the domain of generators which produce ready-to-integrate and verified hard macros such as the OpenRAM generator.

For fun this creates a C++ PCell (Basic library) with something like 1..2M polygons:

ly = pya.CellView.active().layout()
top_cell = ly.top_cell()

text = []
for l in range(0, 1000):
  line = ""
  for t in range(0, 125):
    line += "%07d " % (t + 125 * l)
  text.append(line)
text = "\\n".join(text)
  
long_text = ly.create_cell("TEXT", "Basic", { "text": text, "layer": pya.LayerInfo(1, 0) })
top_cell.insert(pya.CellInstArray(long_text.cell_index(), pya.Trans()))

It executes in a few seconds in my case (only a very small portion shown):

Nice, but I think for pcells the main reason, we moved to gdsfactory was relative object functionality and ease of access to such functionality in gdsfactory.

[klayoutmatthias]

@sebastian-goeldi Our tests are on layouts that has from 1 million to 50 million polygons shows that the loading speed for gdstk and doing a simple AND operation is much faster than klayout. Again, we develop all our DRC on klayout because gdsfactory doesn't provide similar functionality. gdstk is very good to do basic manipulation and hierarchical data. Also, gdstk has this "RawCell" concept that allow even further optimization into speed and memory conception. gdsfactory doesn't add a lot of data for each polygon on top of what is in the main backend tool. Which makes it perfect solution for optimized layout handling for us.

@proppy The main driving reason for using gdsfactory here for PCell specifically is not the memory rather it's the advanced alignment features that gdsfactory has. Memory conception is for large layouts and not the main concern here. I only mentioned the memory here just to highlight that klayout has it's limitations as well.

And finally without intending to fuel this discussion more than necessary: performance is always relative. Give me a benchmark and I'll be happy to accept the challenge. KLayout's booleans are not always on the level of boost.polygon for example, but I know how to optimize them (which I can't claim on boost.polygon) and they are all-angle robust which for me is a very important feature.

I am myself using KLayout on a daily basis on very large layouts - we're not using GDS anymore, but OASIS. I am talking about full mask layouts with literally billions of polygons. Working with such layouts - for example density calculations, booleans or DRC is not snappy, but with enough CPU power quite manageable. However, you need to be careful to choose the right ways like tiling mode for flat data or deep mode for hierarchical data. You also need to have some understanding of the basic functionality to be able to optimize which BTW is also the case for the $$$ commercial alternatives. In contrast to the vendor tools, I did not spend much time in optimizing yet, but - again - drop me a benchmark and let me help. In most cases, there a low hanging fruits that improve performance by orders of magnitude sometimes.

And commenting on the PCells for devices: the true value of such an implementation does not lie in performance or actual code, but to provide a reference design for devices with appropriate parameters, their physical outline and - most importantly - the correlation with the models. To me it does not matter at all what tool the device primitives are implemented in. But it is very important that the implementation can act as a blueprint (i.e. is readable, comprehensible and executable) for other implementations, supplying the model to hardware correlation. In the end it's not realistic that every user of the devices uses the same single implementation - to attract a broad user community, you need to serve many kind of platforms. The goal should be to have a description of the polygons I need to draw in order to generate a device with predictable properties. If that is executable code, the better - whatever system you deploy that to, as long it is open source.

Matthias

[atorkmabrains]

As always @klayoutmatthias, perfectly said. Can't agree more. You're always helpful. Your insights on the performance were always helpful to my team.

[atorkmabrains]

@proppy Here is my recommendation:

• Keep the current implementation using gdsfactory.
• Document the need to add gdsfactory in the installation for PDK requirement.
• Make sure to clean up the temporary file generated after reading in klayout.

If you agreed with that direction, please confirm. If not, please let me know what is the direction that you want us to follow?

[proppy]

In the end it's not realistic that every user of the devices uses the same single implementation - to attract a broad user community, you need to serve many kind of platforms.

That's aligned with my thinking as well, to me the implementation of the PCell should have a strong affinity with the audience of the environment it is deployed on. If running inside Klayout it makes sense to target Klayout pya API so that Klayout community can easily read, learn from, troubleshoot, and contribute to them.

It also makes sense to have another gdsfactory implementation of the PCells, targeted to the gdsfactory community that want to draw layout programmatically outside of klayout using gdsfactory constructs.

We can always have test suites that verify the conformity of drawn devices with the PDK primitive specifications.

[proppy]

• Keep the current implementation using gdsfactory.
• Document the need to add gdsfactory in the installation for PDK requirement.
• Make sure to clean up the temporary file generated after reading in klayout.

I'd love to get @mithro input there, but I don't think this path is desirable.

While I think it's important to have a gdsfactory version of the PCells, using them for klayout creates significant environment and cognitive burden on the target audience: the klayout community:

• klayout has its own embedded python environment, it's standalone and doesn't require you to have python installed on your host
• gdsfactory comes with ~350M of transitive dependencies
• as commented in document pcells implicit dependency on gdsfactory #28 (comment) the current implementation is not "simple" and involve multiple roundtrip between disk and different memory respresentation of the same PCells.

Another observation:
pya is the documented and idiomatic way for implementing PCells in klayout; if the primary argument for ont using pya is the lack of "advanced relative layout and alignment functionality" and we all agree that this is important for implementing PCells: I'm sure @klayoutmatthias would love to get a feature request filed that document the missing functionalities in the pya API surface. We can all help adding those primitive to klayout python API and make its ecosystem better.

[atorkmabrains]

@proppy As discussed here, we will go back to the pya based implementation and remove dependency of gdsfactory for the pcells. I'll move the gdsfactory to another folder outside of klayout to be part of the PR repo. Also, I take the action to add multiple issues/enhancement requests to klayout as agreed above.

Thanks @proppy and @klayoutmatthias Appreciate all the help.

[klayoutmatthias]

I'm sure @klayoutmatthias would love to get a feature request filed that document the missing functionalities in the pya API surface. We can all help adding those primitive to klayout python API and make its ecosystem better.

@proppy Well ... "love to" may not be the right wording in that context, but I am ready to take the callenge :) Please go ahead and file a ticket!

[proppy]

@proppy Well ... "love to" may not be the right wording in that context

Sorry about speaking on your behalf (I should have used würde or hätte here!)

I'll move the gdsfactory to another folder outside of klayout to be part of the PR repo.

What about moving it to a separate repo under the gdsfactory org similar to https://github.com/gdsfactory/skywater130/? /cc @joamatab

we will go back to the pya based implementation

Thanks for considering it.

I thought about another issue that might arise with the current approach:
For a given klayout build, we have no guarantee (apart maybe for version properly packaged by linux distribution like debian) that the embedded python version that's linked to klayout is the same as the system python version. Given that the dependency tree of gdsfactory include native dependencies (like matplotlib, numpy, scipy or gdstk) we have no guarantee that if users python -m pip install gdsfactory, they 'll do it from a python environment that's compatible with the one linked to klayout.

[atorkmabrains]

@joamatab Could you please create a repo to move the gdsfactory implementation to? Also, please help us make it a python package installable just like skywaters.

[atorkmabrains]

@proppy BTW, Skywaters klayout support in the open_pdks still use gdsfactory: https://github.com/efabless/sky130_klayout_pdk/blob/main/sky130_tech/tech/sky130/pymacros/cells/draw_fet.py

Is that something you want changed as well?

cc @mkkassem @jeffdi @RTimothyEdwards

[proppy]

BTW, Skywaters klayout support in the open_pdks still use gdsfactory

is that different from https://github.com/gdsfactory/skywater130/, can we consolidate there and revert back to klayout based cells (for the same reason pointed out in #28 (comment) and #28 (comment))

/cc @mithro

[atorkmabrains]

https://github.com/gdsfactory/skywater130/ is an older version of the same pcells. I have filed an issue on that repo to update to the latest implementation:
gdsfactory/skywater130#63

BTW, we never had pya based pcells for klayout on skywaters like GF180MCU.

[proppy]

BTW, we never had pya based pcells for klayout on skywaters like GF180MCU

what about https://github.com/efabless/sky130_klayout_pdk/blob/14d268fac4df495b3d96e3d8f6058023d99d44c5/sky130_tech/tech/sky130/pymacros/sky130_pcells/imported_generators/nmos18.py ?

[atorkmabrains]

Those are corrupted and should be removed. Thanks for pointing this out. @proppy

[atorkmabrains]

Or in other words, not ready for production. @proppy

[joamatab]

See https://github.com/gdsfactory/gf180

still needs some work, PRs are welcome, see

gdsfactory/gf180#4

[atorkmabrains]

@proppy @klayoutmatthias Klayout issue has been opened: KLayout/klayout#1336

[atorkmabrains]

@proppy and @joamatab Also, I have created an issue on gdsfactory which I think might help here as well: gdsfactory/gdsfactory#1536