FXC-3517 add impedance calculations to mode solver #2837
Conversation
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
2 times, most recently
from
ceccb9e to
18ced37
Compare
Diff CoverageDiff: origin/develop...HEAD, staged and unstaged changes
Summary
tidy3d/components/geometry/utils.pyLines 653-661 653 strict_bounds=strict_bounds,
654 margin=-snap_margin,
655 )
656 if max_snap < min_snap:
! 657 raise SetupError("The supplied 'snap_margin' is too large for this contraction.")
658 return (min_snap, max_snap)
659
660 # Iterate over each axis and apply the specified snapping behavior.
661 min_b, max_b = (list(f) for f in box.bounds)tidy3d/components/microwave/base.pyLines 23-31 23 def _warn_rf_license(cls, values):
24 suppress_instantiation_warnings = values.get("suppress_instantiation_warnings")
25 # Skip warning during test runs or when built with suppression
26 if not is_running_pytest() and not suppress_instantiation_warnings:
! 27 log.warning(
28 "ℹ️ ⚠️ RF simulations are subject to new license requirements in the future. You have instantiated at least one RF-specific component.",
29 log_once=True,
30 )
31 return valuestidy3d/components/microwave/path_integrals/path_integral_factory.pyLines 123-132 123 v_integrals.append(None)
124 i_integrals.append(None)
125 continue
126 elif isinstance(impedance_spec, AutoImpedanceSpec):
! 127 v_spec = None
! 128 i_spec = auto_spec.current_spec
129 else:
130 v_spec = impedance_spec.voltage_spec
131 i_spec = impedance_spec.current_spectidy3d/components/mode/mode_solver.pyLines 1383-1391 1383 ) -> tuple[tuple[Optional[VoltageIntegralTypes]], tuple[Optional[CurrentIntegralTypes]]]:
1384 """Wrapper for making path integrals from the MicrowaveModeSpec. Note: overriden in the backend to support
1385 auto creation of path integrals."""
1386 if not self._has_microwave_mode_spec:
! 1387 raise ValueError(
1388 "Cannot make path integrals for when 'mode_spec' is not a 'MicrowaveModeSpec'."
1389 )
1390 return make_path_integrals(self.mode_spec)Lines 2023-2031 2023 )
2024
2025 mode_solver_monitor_type = ModeMonitor
2026 if isinstance(self.mode_spec, MicrowaveModeSpec):
! 2027 mode_solver_monitor_type = MicrowaveModeMonitor
2028
2029 return mode_solver_monitor_type(
2030 center=self.plane.center,
2031 size=self.plane.size,tidy3d/plugins/microwave/custom_path_integrals.pyLines 229-237 229
230 # Perform phase splitting into in and out of phase for each frequency separately
231 for term in path_currents:
232 if np.all(term.abs == 0):
! 233 continue
234
235 # Compare phase to reference for each frequency
236 phase_diff = term.angle - phase_reference
237 # Wrap phase difference to [-pi, pi] |
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
from
6996084 to
290484a
Compare
There was a problem hiding this comment.
Very impressive work, finished the first pass and left some comments. Additionally, it seems like many new classes AxisAlignedPathIntegralSpec, CustomPathIntegral2DSpec, CurrentIntegralAxisAlignedSpec, CustomCurrentIntegral2DSpec, CompositeCurrentIntegralSpec, CustomImpedanceSpec, etc are missing examples in docstrings
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
from
7ad7a12 to
2727e2f
Compare
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
from
917c3ad to
d23f936
Compare
|
Thanks @dbochkov-flexcompute for finding those docstring mistakes. It was a little bit harder than expected to get doc tests running correctly because of the log warning we have for rf and microwave components. I got it working by introducing the |
There was a problem hiding this comment.
Looks pretty good @dmarek-flex ! Just a few questions on very few API design considerations
tidy3d/components/mode_spec.py
Outdated
| GROUP_INDEX_STEP = 0.005 | ||
|
|
||
|
|
||
| class ModeSpec(Tidy3dBaseModel): |
There was a problem hiding this comment.
So yeah why simply not make a class MicrowaveModeSpec(ModeSpec) ?
There was a problem hiding this comment.
I did try this approach and it worked ok for the ModeSpec/MicrowaveModeSpec side of things. But then I felt like I would need to have a MicrowaveModeData/MicrowaveModeSolverData and that would require modifications all over the code base (frontend and backend) to provide the correct type hints and Pydantic fields.
And then following that logic we would need a MicrowaveModeMonitor/MicrowaveModeSolverMonitor/MicrowaveModeSimulation and it felt like maintaining the proper type hints would be a lot of extra work. From trying this out, inheritance did not seem the easiest approach for maintenance, and I decided that composition would be a better approach.
There was a problem hiding this comment.
@yaugenst-flex @tylerflex it'd be good to get your input here in terms of how we do separation of scope rather than mixing RF into the general ModeSpec as currently implemented in this PR per the following lines in this file. It is concievable that MicrowaveModeSpec(ModeSpec) keeps getting extended as well as future classes that Damian mentioned in order to provide custom RF functionality eventually, but it is a larger effort in terms of the API restructure that we also have to consider. The benefit though is a stronger separation of API, which is related to previous conversations we've had privately about product scope.
tidy3d/tidy3d/components/mode_spec.py
Lines 167 to 173 in a4c3c40
There was a problem hiding this comment.
Yea I'd rather make a dedicated MicrowaveModeSpec(ModeSpec) in a separate place vs mixing it into the component as microwave_spec: Optional[MicrowaveModeSpec] = pd.Field
eventually I think all of the RF-specific components should be moved into their own separate namespace, like a tidy3d.rf, and that includes terminal component modeler, MicrowaveModeSpec, and probably a separate RFSimulation.
To me that seems like the long term direction (a separate rf python package that extends tidy3d, but tidy3d proper can be independent of it)
There was a problem hiding this comment.
MicrowaveModeSpec makes sense but then I need to create new classes that accept it, which will lead to MicrowaveModeData/MicrowaveModeSolverData/MicrowaveModeMonitor/MicrowaveModeSolverMonitor/MicrowaveModeSimulation versions?
Or do I allow a ModeMonitor to accept both mode_specs but produce either ModeData or MicrowaveModeData depending on the spec?
There was a problem hiding this comment.
Ultimately, sounds like we should go this way in the long run @dmarek-flex though, and try to have a cleaner separation for RF. Happy to chat to scope this out if we want to do this for 2.10 too before getting to MicrowaveSimulation? This said it'd be good for the product council to discuss the extra effort this might take to start doing this separation in the RF product plans @tylerflex ?
There was a problem hiding this comment.
yea, it's a tough call, because we will start to have tons of classes, but I also feel it should happen eventually. Hopefully most of these could be very thin wrappers around the tidy3d objects that they inherit from?
Ideally we can get to a place where tidy3d just contains stuff for basic fdtd + photonics. and tidy3d.rf extends tidy3d and adds anything specific to microwave. I think we'll necessarily have to add more classes there but hopefully most things can be shared.
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
2 times, most recently
from
837a080 to
c685b6b
Compare
dmarek-flex
changed the title
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
2 times, most recently
from
bee9d40 to
008ab9f
Compare
|
Alright lets have another go @greptileai. Also since @daquinteroflex is away, can @tylerflex or @yaugenst-flex take a look at this refactoring of the |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Additional Comments (1)
-
tidy3d/plugins/microwave/auto_path_integrals.py, line 32-34 (link)logic: Parameter descriptions don't match parameter names -
lumped_elementandgriddescriptions are incorrectContext Used: Rule from
dashboard- Keep docstrings and comments synchronized with code changes to ensure they are always accurate and n... (source)
63 files reviewed, 9 comments
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
2 times, most recently
from
b2458d6 to
40bcc17
Compare
add a ImpedanceSpec for controlling how characteristic impedance is calculated from modes add MicrowaveModeMonitor and MicrowaveModeSolverMonitor that accepts the new MicrowaveModeSpec BREAKING CHANGE: changed path integral class names in plugins/microwave
refactor impedance results into MicrowaveModeData and associated classes refactor monitors in progress finishing monitor/data refactor fix changelog improve coverage changelog and migration guide update fix mode limits calc and improve snapping helpers
dmarek-flex
force-pushed
the
dmarek/add_impedance_to_mode_data
branch
from
40bcc17 to
e9ca7aa
Compare
We should figure out a plan regarding the RF/Tidy3D separation and organization long term. @weiliangjin2021 just for a sense, here are some related discussions #2837 (comment) My feeling is that the best long term solution is a complete separation of RF from the main tidy3d components. Meaning perhaps a But for this to be a reality, we would need to (at least):
Could you guys think about this a bit in terms of requirements from your side and any preferences? @weiliangjin2021 let's discuss together with yannick and Lucas at the tech council meeting monday to get a general feeling because the same issues arise in photonforge. |
|
I just started looking at this: One idea occurred to me, which is that if we eventually do want to import While underlying things would still be all mixed without any changes, this would at least give us an ability to start crafting the user-facing side of the package. note sure if worth doing here since this is a needed feature, but wanted to make a note. |
5 participants
add a ImpedanceSpec for controlling how characteristic impedance is calculated from modes
backend PR: https://github.com/flexcompute/compute/pull/2497
Greptile Overview
Updated On: 2025-10-07 20:11:19 UTC
Summary
This PR introduces a comprehensive impedance calculation system for microwave mode solvers in Tidy3D. The implementation adds the ability to calculate characteristic impedance from electromagnetic modes, which is essential for microwave and RF transmission line analysis.Key architectural changes:
ImpedanceSpecTypesunion withAutoImpedanceSpecfor automatic impedance calculation andCustomImpedanceSpecfor user-defined voltage/current path integralsMicrowaveModeSpecextending the base mode specification with impedance calculation capabilities for each modeModeSpec,ModeSolver, and related classes to support microwave specifications while maintaining backward compatibilityMicrowaveModeMonitorandMicrowaveModeSolverMonitorfor microwave-specific data collectionMicrowaveModeDataandMicrowaveModeSolverDataclasses that include transmission line characteristics (impedance, voltage/current coefficients)Implementation highlights:
ModePlaneAnalyzerMicrowaveBaseModelbase class for consistent RF licensing and functionalityVoltageIntegralAxisAligned→AxisAlignedVoltageIntegral)The system integrates seamlessly with existing Tidy3D workflows - users can continue using standard mode specifications for basic electromagnetic analysis while accessing advanced impedance calculations through the new microwave specifications. The architecture properly separates automatic impedance calculation for common cases from custom path integral specifications for complex geometries.
PR Description Notes:
Important Files Changed
Changed Files
tidy3d/components/microwave/path_integrals/impedance_spec.pytidy3d/components/microwave/microwave_mode_spec.pytidy3d/plugins/microwave/impedance_calculator.pytidy3d/components/mode_spec.pytidy3d/components/microwave/path_integrals/mode_plane_analyzer.pytidy3d/components/mode/mode_solver.pytidy3d/components/microwave/path_integrals/base_spec.pytidy3d/components/microwave/path_integrals/voltage_spec.pytidy3d/components/microwave/path_integrals/current_spec.pytidy3d/components/microwave/monitor.pytidy3d/components/microwave/data/monitor_data.pytidy3d/components/microwave/base.pytidy3d/components/simulation.pytidy3d/components/geometry/utils.pytidy3d/plugins/microwave/path_integrals.pytidy3d/plugins/microwave/custom_path_integrals.pydocs/api/microwave/microwave_migration.rsttidy3d/__init__.pyCHANGELOG.mdConfidence score: 3/5
tidy3d/components/mode_spec.pyfor the missing closing quote in the validation error messageContext used:
Rule from
dashboard- Do not use markdown formatting in exception or warning messages; use single quotes to highlight vari... (source)Rule from
dashboard- Update the CHANGELOG.md file when making changes that affect user-facing functionality or fix bugs. (source)