You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Even when the resulting components are pretty much identical, the Tidy3DComponent does not plot the simulation geometry and instead crashes when using a Layer tuple as the layer argument in a cross section function. The bug is not present when using a str to access the layer from the activated generic PDK, though I am also struggling with this when defining own PDKs (actually, this is where this becomes really weird and messy but it would be too much to include here).
To Reproduce
fromfunctoolsimportpartialimportgdsfactoryasgffromgdsfactory.technologyimportLayerLevel, LayerStackimportgplugins.tidy3dasgt# Define a layer mapLayer=tuple[int, int]
classLAYER(gf.LayerEnum):
kcl=gf.constant(gf.kcl)
WAFER: Layer= (0, 0)
WG_new: Layer= (1, 0)
gf.kcl.layers=LAYER# this doesn't seem to make a difference# Create a layer stackLAYER_STACK=LayerStack(
layers=dict(
substrate=LayerLevel(
layer=(0,0),
thickness=1,
zmin=-1,
material="sio2",
info={"mesh_order": 99},
),
core=LayerLevel(
layer=(1,0),
thickness=0.5,
zmin=0,
material="si",
info={"mesh_order": 99},
)
)
)
# Create a waveguide cross sectionstrip_PASSES=partial(gf.cross_section.strip, layer='WG')
strip_FAILS=partial(gf.cross_section.strip, layer=LAYER.WG_new)
strip_ALSO_FAILS=partial(gf.cross_section.strip, layer= (1,0))
# Create a componentMMIPASS=gf.components.mmi2x2(width=0.5, cross_section=strip_PASSES)
MMI1=gf.components.mmi2x2(width=0.5, cross_section=strip_FAILS)
MMI2=gf.components.mmi2x2(width=0.5, cross_section=strip_ALSO_FAILS)
MMI1.show()
# Define PDKpdk1=gf.Pdk(name="fab1", layers=LAYER, cross_sections={'WG_new': strip_PASSES})
pdk1.activate()
# Define further cross sections depending on the PDKstrip_PDK_FAILS=partial(gf.cross_section.strip, layer=pdk1.get_layer("WG_new"))
strip_PDK_PASSES=partial(gf.cross_section.strip, layer='WG_new')
# Compare the layersMMI3=gf.components.mmi2x2(width=0.5, cross_section=strip_PDK_FAILS) # PDKMMIPASS_PDK=gf.components.mmi2x2(width=0.5, cross_section=strip_PDK_PASSES) # PDKprint(MMIPASS.layers, MMI1.layers, MMI2.layers, MMI3.layers, MMIPASS_PDK.layers)
print(MMIPASS.layers==MMI1.layers==MMI2.layers==MMI3.layers==MMIPASS_PDK.layers )
# Setup the tidy3d componentc=gt.Tidy3DComponent(
component=MMI1,
layer_stack=LAYER_STACK,
material_mapping=gt.material_name_to_medium,
pad_xy_inner=2.0,
pad_xy_outer=2.0,
pad_z_inner=0,
pad_z_outer=0,
extend_ports=2.0,
)
# Check the simulation geometryc.plot_slice(z="core")
Depending on which MMI or cross section is used, the simulation geometry is successfully plotted (MMIPASS or MMIPASS_PDK) or python crashes. The error message is the following:
--- Logging error in Loguru Handler #1 ---
Record was: {'elapsed': datetime.timedelta(seconds=5, microseconds=790321), 'exception': (type=<class 'pydantic_core._pydantic_core.ValidationError'>, value=2 validation errors for Section
layer.tuple[int, int]
Input should be a valid tuple [type=tuple_type, input_value=1, input_type=int]
For further information visit https://errors.pydantic.dev/2.8/v/tuple_type
layer.str
Input should be a valid string [type=string_type, input_value=1, input_type=int]
For further information visit https://errors.pydantic.dev/2.8/v/string_type, traceback=<traceback object at 0x00000189D21BAC40>), 'extra': {'stack': '<frozen runpy>:_run_module_as_main:198 > <frozen runpy>:_run_code:88 > ...\test_envs\\test_gplugins_bugs\\.venv\\Lib\\site-packages\\ipykernel_launcher.py:<module>:18 > ....\test_envs\\test_gplugins_bugs\\. ... (full report attached)
The simulation geometry should be plotted (and any ensuing simulation steps should work).
Suggested fix
I am not sure what is causing the error, but will post a workaround if I find one.
This could just be the tidy3d plugin, but it could also go deep into the gdsfactory.technology.
The weirdest part is that when defining own PDKs and importing them from elsewhere (as opposed to the above), this behaviour becomes seemingly non-deterministic, sometimes passing and sometimes not in subsequent executions.
Versions
gdsfactory version: gdsfactory==8.5.6
gplugins version: gplugins==1.0.2
fresh python 3.11.2 venv with only gdsfactory and gplugins (and deps) installed via
Okay, thanks for the update.
If you want to, I can try to get to the bottom of this in terms of gdsfactory, and if I find something, then close this issue and create the corresponding issue in https://github.com/gdsfactory/gdsfactory/issues .
But I feel like this may be fixed 'automatically' through the continuing improvements on gdsfactory8
Describe the bug
Even when the resulting components are pretty much identical, the
Tidy3DComponent
does not plot the simulation geometry and instead crashes when using aLayer
tuple as thelayer
argument in a cross section function. The bug is not present when using astr
to access the layer from the activated generic PDK, though I am also struggling with this when defining own PDKs (actually, this is where this becomes really weird and messy but it would be too much to include here).To Reproduce
Depending on which MMI or cross section is used, the simulation geometry is successfully plotted (
MMIPASS
orMMIPASS_PDK
) or python crashes. The error message is the following:error_message.txt
Expected behavior
The simulation geometry should be plotted (and any ensuing simulation steps should work).
Suggested fix
I am not sure what is causing the error, but will post a workaround if I find one.
This could just be the
tidy3d
plugin, but it could also go deep into thegdsfactory.technology
.The weirdest part is that when defining own PDKs and importing them from elsewhere (as opposed to the above), this behaviour becomes seemingly non-deterministic, sometimes passing and sometimes not in subsequent executions.
Versions
pip install gdsfactory --upgrade pip install "gplugins[devsim,femwell,gmsh,schematic,meow,meshwell,ray,sax,tidy3d]" --upgrade
requirements.txt
The text was updated successfully, but these errors were encountered: