Skip to content

Conversation

@George-Guryev-flxcmp
Copy link
Contributor

@George-Guryev-flxcmp George-Guryev-flxcmp commented Feb 8, 2026

Summary

Adds frequency-parametrized support for lossy dielectrics and lossy metals to the RF material library, enabling users to request material models for specific frequency ranges.

Changes

Core Functionality

  • Added frequency-parametrized materials:

    • VariantItemFreqRangeDielectric: For lossy dielectric materials with PoleResidue models
    • VariantItemFreqRangeMetal: For lossy metal materials with LossyMetalMedium models
  • Enhanced medium() methods:

    • Both classes support optional frequency_range parameter
    • VariantItemFreqRangeDielectric: Validates if requested range is within stored measurements
      • Returns stored model with updated metadata when within range
      • Creates new PoleResidue model using constant loss tangent fitter with averaged properties when outside range
      • Issues informative warnings when measurements are unavailable
    • VariantItemFreqRangeMetal: Creates LossyMetalMedium fitted for the requested frequency range
  • Added fields to VariantItemFreqRangeDielectric:

    • loss_tangent: Loss tangent values (single or list)
    • eps_real: Real permittivity values (single or list)
    • measurement_frequencies: Frequencies at which measurements were taken

Testing

  • Added comprehensive unit tests covering:
    • Frequency range validation for dielectrics (inside/outside/overlapping ranges)
    • Metal material creation with frequency ranges
    • Warning verification using AssertLogLevel
    • Averaged values verification for dielectrics

Behavior Changes

Before: RF material library only supported fixed-frequency material models.

After: Users can now:

  1. Use default frequency range: variant.medium() returns model for stored/default range
  2. Request custom frequency range: variant.medium(frequency_range) returns model fitted for requested range
  3. For dielectrics outside stored measurements: Receive warnings and models created with averaged properties
  4. For metals: Always get models fitted specifically for the requested frequency range

Testing

Ran the following checks:

  • pytest tests/test_plugins/test_rf_material_library.py - All tests pass

Documentation

  • Updated docstrings for both VariantItemFreqRangeDielectric and VariantItemFreqRangeMetal
  • Warning messages clearly explain the situation and approach taken
  • Examples demonstrate usage of both material types

Note

Medium Risk
Introduces new public material item/variant types and changes how some RF library entries are accessed/constructed (notably metals requiring frequency_range), which could affect downstream usage and fitting accuracy for out-of-range requests.

Overview
Adds frequency-range parametrization to the RF material library by introducing VariantItemFreqRangeDielectric and VariantItemFreqRangeMetal plus a new MaterialItemFreqRange wrapper for these variants.

Dielectric variants now accept measured loss_tangent/eps_real data and a prefitted_medium; requesting an out-of-range frequency_range logs a warning and fits a new PoleResidue using averaged properties, while in-range requests reuse the prefitted model. Metal variants are added as conductivity-based entries that require an explicit frequency_range to construct a LossyMetalMedium (with optional roughness/thickness/fit parameters).

Expands the RF library catalog with multiple new dielectrics and metals, updates rf_material_reference.py with new sources, and adds a comprehensive test_rf_material_library.py covering validation, warning behavior, range handling, and material access patterns. Also updates CHANGELOG.md to document the new frequency-parameterized RF materials.

Written by Cursor Bugbot for commit ecee22f. This will update automatically on new commits. Configure here.

@George-Guryev-flxcmp George-Guryev-flxcmp force-pushed the george/rf_materials branch 3 times, most recently from d3b2269 to 2617775 Compare February 8, 2026 19:46
@github-actions
Copy link
Contributor

github-actions bot commented Feb 8, 2026

Diff Coverage

Diff: origin/develop...HEAD, staged and unstaged changes

  • tidy3d/plugins/microwave/rf_material_library.py (96.5%): Missing lines 316-319

Summary

  • Total: 115 lines
  • Missing: 4 lines
  • Coverage: 96%

tidy3d/plugins/microwave/rf_material_library.py

Lines 312-323

  312                 "where frequency_range is a tuple (f_min, f_max) in Hz."
  313             )
  314         else:
  315             # Fallback: try to call if it's callable, otherwise return as-is
! 316             medium_attr = getattr(variant, "medium", None)
! 317             if callable(medium_attr):
! 318                 return medium_attr()
! 319             return medium_attr
  320 
  321 
  322 Rogers3003_design = VariantItem(
  323     medium=PoleResidue(

@George-Guryev-flxcmp George-Guryev-flxcmp force-pushed the george/rf_materials branch 2 times, most recently from 8188acd to 6f4b8ac Compare February 8, 2026 22:18
@weiliangjin2021
Copy link
Collaborator

Could you also update doc-related scripts and take a look at how the doc page looks like?

@weiliangjin2021
Copy link
Collaborator

A few comments by Claude first:


tidy3d/plugins/microwave/rf_material_library.py:761

Megtron6_R5775_N.frequency_range appears too narrow

This variant has measurement data spanning 1 GHz to 50 GHz (10 data points at lines 751-753), but
pole_residue.frequency_range is (1e9, 1e10) — only up to 10 GHz. A user requesting e.g. (1e9,
50e9) would get the averaged fallback model despite measurement data existing up to 50 GHz.

Should this be (1e9, 5e10) to match the measurement range? (Compare with Megtron6_R5670_N at line
776 which correctly uses (1e9, 5e10).)


tidy3d/plugins/microwave/rf_material_reference.py:133-138

Cobalt reference appears to cite the wrong paper

The reference for Cobalt cites "Benon H. J. Bielski, et al., Reactivity of HO2/O Radicals in
Aqueous Solution" — this is a paper on radical chemistry, not electrical conductivity. The JPCRD
volume/issue looks correct but the specific paper seems wrong.


tidy3d/plugins/microwave/rf_material_library.py:780

"Neclo" should be "Nelco"

The variable names and library keys (Neclo_N4000_6, Neclo_N4000_13EP, etc.) misspell the brand —
it's Nelco (Park Electrochemical). The reference datasheet_title at rf_material_reference.py:101
spells it correctly as "Nelco". Since these are user-facing keys in rf_material_library.keys(),
worth fixing before this ships.


tidy3d/plugins/microwave/rf_material_library.py:1060-1085

Duplicate display names across distinct library entries

Several pairs share the same name field:

  • "Megtron6_R5775_KG" and "Megtron6_R5670_KG" both → name="Megtron6 R5775_R5670(KG)"
  • "Megtron6_R5775_N" and "Megtron6_R5670_N" both → name="Megtron6 R5775_R5670(N)"
  • "Neclo_N4000_13EP" and "Neclo_N4000_13EP_SI" both → name="Neclo N4000-13"

Could be confusing in listings/summaries. Consider differentiating the display names (e.g.
"Megtron6 R5775(KG)" vs "Megtron6 R5670(KG)").


tidy3d/plugins/microwave/rf_material_reference.py:90-91

Duplicated substring in datasheet_title

Python implicit string concatenation produces:
"...Multi-layer circuit board materialsMulti-layer circuit board materials"
Missing a space or the second line is an accidental duplicate.


tidy3d/plugins/microwave/rf_material_library.py:314-319

Nit: dead else branch

VariantItemFreqRange is sealed to VariantItemFreqRangeDielectric and VariantItemFreqRangeMetal —
this fallback with getattr(variant, "medium", None) can never be reached. Consider removing it.


tidy3d/plugins/microwave/rf_material_library.py:1144-1150

Nit: Aluminum/Aluminium dual library entries

Both "Aluminium" and "Aluminum" exist as separate entries pointing to the same variant object.
This is user-friendly but it means both show up in iterations/listings. A note in the docstring or
a comment here would help clarify the intent.


Returns the medium for the default variant using its default frequency range.
For dielectrics, this returns the stored PoleResidue model (equivalent to calling
``variant.medium()`` without arguments).
For metals, raises ValueError as frequency_range is required.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this makes me wonder if we should add a default frequency range to VariantItemFreqRangeMetal, which is based on measured data or known valid range. With that both Variant will have a default frequency range.

Copy link
Contributor

@dmarek-flex dmarek-flex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a nice contribution! Just a bit confused by that part where it falls back to checking if the variant is callable. From the Pydnatic model it seems like it has to be either one of the previous classes? VariantItemFreqRangeDielectric/VariantItemFreqRangeMetal

Copy link
Collaborator

@yaugenst-flex yaugenst-flex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change introduces callable variant.medium(...) for RF frequency-range variants, but doc-generation logic still assumes var.medium is a medium object. Repro:

from tidy3d.plugins.microwave import rf_material_library as rf_lib
for _, mat in sorted(rf_lib.items()):
    for _, var in sorted(mat.variants.items()):
        medium = var.medium
        _ = len(medium.poles)

This fails with AttributeError: 'function' object has no attribute 'poles'. Could we update docs/generate_doc.py accordingly?

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 2 potential issues.

Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants