port_symmetries on gtidy3d.write_sparameters seem broken

[jan-david-fischbach]

Describe the bug
When using port symmetries it seems to execute the wrong simulations and not copy over the s-parameters correctly

To Reproduce

c = gf.components.mmi2x2()
symmetry = {
  "o1": {
    "s11": ["s22","s33","s44"], "s21": ["s12","s34","s43"], "s31": ["s13","s24","s42"], "s41": ["s14","s23","s32"],
  }
}
df = gt.write_sparameters(c, overwrite=True, port_symmetries=symmetry, is_3d=False, verbose=True)

Expected behavior
Execute a single simulation (not three) and copy the s-parameters as advised by the dict.

Suggested fix
I will open a PR

[jan-david-fischbach]

Additionally it seems to break with the old s-parameter notation. So either we should autoconvert from the old notation to the new one (assuming fundamental mode), or we should fix the docs...

[joamatab]

it seems still has issues

@lucas-flexcompute

[lucas-flexcompute]

The problem seems to be the name of the ports. The names coming from the component are 'o1', 'o2', but the symmetry definition uses another naming scheme, so this if clause is never true.

[jan-david-fischbach]

I had been "fixing" the issue according to the [doc string] (

gdsfactory/gdsfactory/simulation/gtidy3d/write_sparameters.py

Line 87 in 23a8aa1

port_symmetries = {"o1":

). There the port names are used as keys. The format specifying the excite port actually makes sense to me, so we would have to adjust the symmetry definitions. What do you think @joamatab?

[jan-david-fischbach]

• And we should add some tests to avoid breakage in the future :)

[joamatab]

we have tests for the tidy3d plugin and are failing at the moment

[jan-david-fischbach]

Interesting... I'll have to check why the tests passed on my machine...

[jan-david-fischbach]

Regarding the top level keys of the symmetry dicts: do we stick to using the excitation port?

[joamatab]

when you work on a fork that has no credentials for tidy3d it skips those tests

I think i found a fix, see PR