Engineering convention for S-parameters in RF

[yuanshen-flexcompute]

This is a known issue, but I am creating this issue for tracking purposes.

Tidy3D uses physics convention, whereas other RF software typically use engineering convention. As a result, the calculated S-parameters (and any derivative quantities such as Z) differ by complex conjugation. It would be good to switch our RF convention to match the others.

Thanks.

[tylerflex]

Thanks @yuanshen-flexcompute , could you be more specific? would this be a change to the tidy3d.plugins.smatrix plugin?

[yuanshen-flexcompute]

My understanding is that at the point of calculation of the S-parameter, we apply np.conj() to the resulting value.

However from discussion with @dmarek-flex , we'd have to be careful about this, so that we do not mess with anything that would be used in optical sims (which follows physics convention).

For example, we probably shouldn't change it for the entire smatrix plugin, as ComponentModeler seems to be geared towards optical systems.

Perhaps it would be better make this change after the RF refactor is done?

@dmarek-flex @weiliangjin2021 are more familiar with the details, so feel free to weigh in 😄

[dmarek-flex]

Most users in RF would expect everything to be in engineering convention for time-harmonic fields ($e^{j \omega t}$). So at some point we may want support this convention. This would require changing many things like S parameters/impedances/em fields.

We could start with providing S parameters or other quantities provided by the TerminalComponentModeler in engineering convention, or at least a toggle that controls how the parameters are returned.

[momchil-flex]

Ah yeas the eternal battle of jwt vs -iwt.