abs(S11) (dB) becomes positive for the example Crosstalk Between Coplanar Waveguides for frequencies higher than 30GHz

[CosimoMV]

When I run Palace (v0.13.0-21-gfb480ff on Ubuntu 24.04) with the tutorial example “Crosstalk Between Coplanar Waveguides” for frequencies higher than 30GHz, I get abnormally big positive values for abs(S11) (dB):

31GHz -> |S[1][1]| = +3.101e+01,
32 GHz -> |S[1][1]| = +3.009e+01,
33 GHz -> |S[1][1]| = +2.914e+01

I tried to change the Solver order to 4, but i got the same behaviour.

abs(S11) (db) (the "Excitation" parameter is true only for port 1) could be 0 theoretically, and I could expect some “little positive” values due to numerical errors, but in this case there is something wrong.
To reproduce this behaviour, simply use the same configuration as in the example and increase the frequency range.

[sebastiangrimberg]

Hi @CosimoMV, thank you for bringing this up. You are correct that for the CPW example with wave ports, we do see these erroneous S11 values. The issue here is related to the second issue I mentioned in this comment. Namely, the frequencies where you see this behavior correspond to the wave port mode being identified as the odd mode of the CPW, also known as the slotline mode. Visualizing the port modes for wave port 1 (the excited port) computed at 30 and 32 GHz, we can see the difference:

• 30 GHz:
  

• 32 GHz:
  

I am not sure if there is a good way to avoid this ambiguity in a frequency sweep, but you can manually chose the correct mode using the "Mode" keyword to choose the right wave port mode index for the actual mode you care about. There also may be an error in the S-parameter calculation which is leading to the value being so much larger than 0 in this case, though I am not sure about that and this might require further investigation. If you are curious you can find the code for wave ports in waveportoperator.cpp and I would welcome any suggestions or fixes you have in mind.

[CosimoMV]

If I use Mode = 1 for the range 29-32 GHz, I obtain for the propagating eigen-mode wave vector:

@ 29GHz Port 1, mode 1: kₙ = 1.445e+03-3.779e-02i m⁻¹

@ 30GHz Port 1, mode 1: kₙ = 1.495e+03-3.910e-02i m⁻¹

@ 31GHz Port 1, mode 1: kₙ = 2.997e-02-1.491e+03i m⁻¹ <-------

@ 32GHz Port 1, mode 1: kₙ = 3.335e-02-1.432e+03i m⁻¹

If I use Mode = 2 for the range 29-32 GHz, I obtain for the propagating eigen-mode wave vector:

@ 29GHz Port 1, mode 2: kₙ = 2.437e-02-1.599e+03i m⁻¹

@ 30GHz Port 1, mode 2: kₙ = 2.700e-02-1.547e+03i m⁻¹

@ 31GHz Port 1, mode 2: kₙ = 1.545e+03-4.042e-02i m⁻¹ <-------

@ Port 1, mode 2: kₙ = 1.595e+03-4.173e-02i m⁻¹

As already mentioned in my last reply in the thread #251 , again it seems that the problem arises when S-parameters are calculated for evanescent modes.
Since the behaviour is known and is solved by changing the value of Mode, so that the same mode is always indexed, excluding evanescent modes, I think the bug can be closed. What do you say @sebastiangrimberg ?

[sebastiangrimberg]

Thanks @CosimoMV, I will close this issue and we can continue discussing in #251. There might be a way to discard evanescent modes with some cutoff in the eigenvalue search, so the value of "Mode" does not need to be modified at different points in the operating frequency spectrum. I will spend some time thinking about it.