support coaxial lumped ports

[dmarek-flex]

Related to issue 523.

Adding support for coaxial ports. This requires adding support for lumped elements with coaxial geometry as well. The basic idea is the same as for the original rectangular lumped port except now:

• Current source is radially symmetric and implemented as a CustomCurrentSource
• Path integral for current computation has to use the core conductor of the port, rather than the lumped resistor itself. This means the port definition requires a direction parameter, which tells the port on which side of the port plane to compute the path integral for current.
• The geometry related to the port is an annulus instead of a rectangle

[dmarek-flex]

Ok this PR is ready for review now! A couple of things that I was not confident about:

• I had to use this "noqa" commands to get rid of ruff errors in test_medium.py
• Also in docstrings I had to use the format ":class:.Simulation" to get the proper linking in the docs, but I think it is usually suggested to use double back ticks. I don't know if this matters at all.

[tylerflex]

Thanks for this massive contribution @dmarek-flex

I had a lot of small comments, but I wasn't able to fully go through everything in total detail.

As you can probably gather, I'm a fan of trying to use the more declarative helpers (eg pop_axis) whenever possible. There's a lot of necessary lower-level data manipulation in these new features. Whenever possible, I think it helps a lot to try to separate this from the higher level, more declarative stuff. For example, try to hide the procedural code into methods (like pop axis) so it can be reused as much as possible.

I gave some suggestions where I saw things, but there were many places where the same operations pop up.

As the RF /microwave codebase grows in complexity, eventually you'll probably hit a point where you'll want as much of this abstracted away as possible, so I'd just consider that moving forward.

Anyway, thanks a lot for the great work! I'm going to add @QimingFlex as a reviewer too to get another pair of eyes on it, specifically the physics part. and so he gets some review experience

[weiliangjin2021]

This is tons of work! First pass except for custom path integral part. All look solid and easy to follow. One question when you compute the current by using a loop in the middle of the two conductors: I assume the current computation will depend on the loop size if the dielectric material between the two conductors is lossy. How is lossy dielectric usually handled in lumped port?

[dmarek-flex]

This is tons of work! First pass except for custom path integral part. All look solid and easy to follow. One question when you compute the current by using a loop in the middle of the two conductors: I assume the current computation will depend on the loop size if the dielectric material between the two conductors is lossy. How is lossy dielectric usually handled in lumped port?

At the end of the day the computation for current is an approximation. It should be more accurate at low frequencies, when fields are closer to TEM, when path is close to the surfaces of conductors. As long as the lossy material does not impact the field distribution a lot, the computation should still be accurate.

We could allow for an optional parameter for the user to place the contour where ever they want. The reason I chose the midpoint is that usually there are only a handful of grid cells in the port and I want to make sure that the path is far enough away from the conductors, so that staircasing and conformal mesh affects to the fields are avoided.

[weiliangjin2021]

A few minor comments. Otherwise looks good.

[tylerflex]

@dmarek-flex looks good to me, barring a few changes to get the tests working, I think this should be basically good to go?

[dmarek-flex]

@dmarek-flex looks good to me, barring a few changes to get the tests working, I think this should be basically good to go?

Yep, think I just need to rebase and the tests will pass again.

[tylerflex]

looks like it just needs submodule update?

[dmarek-flex]

looks like it just needs submodule update?

Yea, but I am also trying to diagnose a regression on the backend tests that I just noticed before merging.

Ok fixed, it was something that I was testing that somehow snuck into the commits