Transmission

[hao14chasing]

How to get transmission data from the detectors? In documentation, it specifically points to ModeOverlapDetector, but it doesn't normalized by source's power. I wonder how can we also get source's power so that we can actually calculate the transmission.

[ymahlau]

Hi @hao14chasing, you can do that with the ModeOverlapDetector. The sources in fdtdx are normalized to output a poynting flux of 1, so there is no normalization necessary. For example, if you measure a poynting flux of 0.96 with the ModeOverlapDetector, then you have 96% transmission.

[hao14chasing]

Hi @l-berg and @ymahlau, thank you for the suggestion. I have updated my code following your recommendation and am now cross-verifying the results between FDTDX and Lumerical (before doing optimization) using a simplified setup with two output channels at a single wavelength.

So far, both simulators produce symmetric power distribution between the two output waveguides. However, I observe a discrepancy between FDTDX and Lumerical when increasing the output channel separation, as shown in the figure below:

In Lumerical, when the separation increases (around 0.5 µm), the transmission first increases and then decreases. My interpretation is that when the waveguides are very close, there may be mode cross-talk or modal overlap, which reduces the coupling efficiency. Increasing the separation initially reduces this interaction and improves transmission.

However, in FDTDX, the transmission appears to decrease monotonically as the separation increases.

For small separations (~0.1 µm), where I performed the topology optimization in FDTDX, the results roughly agree with Lumerical. But at larger separations, the discrepancy becomes more noticeable.

I am therefore wondering whether the discrepancy may be due to the fact that FDTDX might not fully account for modal overlap (or coupling) between waveguides.

If you have any suggestions on what might cause this difference, I would greatly appreciate your insight.

[ymahlau]

Hi @hao14chasing, It is a bit difficult for me to comment on this without seeing the actual simulation setup. Are you measuring transmission in each waveguide individually in both fdtdx and lumerical and reporting the sum in the image? If so, I don't see why there should be a difference in the handling of mode overlap.

You are right that when waveguides are very close there may be interactions between the waveguide modes. You could check that by calculating the output mode over both waveguides (using a large detector that covers both waveguides). If the mode looks different than the individual modes you have interactions.

[hao14chasing]

Thank you for the reply. Yes, I am measuring each output waveguide individually in both cases.

For reference, the scripts are here:

• FDTDX: Notebook link
• Lumerical: Notebook link

With those scripts, FDTDX gives:

and Lumerical gives:

After looking through the setup more carefully, I do not think there is an obvious bug in fdtdx, but I am wondering whether the two tools may currently be reporting slightly different observables.

My understanding is that in fdtdx, ModeOverlapDetector computes a mode on the detector slice itself and then evaluates overlap against that mode. In contrast, in my current Lumerical script I am using a DFT monitor, which is measuring total power flux through the monitor plane rather than an explicit modal overlap. If that is correct, then the comparison may currently be:

• fdtdx: how much of the field matches the local guided mode
• Lumerical: how much total power passes through the monitor plane

So one possibility is that the Lumerical monitor is also counting some non-guided or radiative power within the monitor window, while fdtdx is more strictly projecting onto the guided mode.

Would that interpretation make sense? If so, then perhaps a better apples-to-apples comparison would be either:

1. use a flux-type detector in fdtdx and compare flux to flux, or
2. use a mode expansion / port-mode measurement in Lumerical and compare mode overlap to mode overlap.

[hao14chasing]

After looking through the setup more carefully, I no longer think the issue is simply that I was comparing a mode-overlap quantity in fdtdx against a total-flux quantity in Lumerical. Initially that seemed plausible, since my first Lumerical setup used a DFT monitor, while fdtdx uses ModeOverlapDetector, which computes overlap against a mode solved on the detector slice itself.

However, after replacing the Lumerical DFT monitor with a mode expansion monitor, I still see a different trend in Lumerical, including a slight increase in transmission for intermediate output gaps:

I checked the fdtdx source again and did not find an obvious issue in ModeOverlapDetector.compute_overlap() itself. The overlap expression there looks standard. What stood out to me instead is the source implementation: in ModePlaneSource.apply(), a complex mode is first computed, but then the injected fields are explicitly reduced to

jnp.real(mode_E), jnp.real(mode_H)

before being launched.

Since ModeOverlapDetector, on the other hand, later projects the simulated fields onto the full complex mode, I am wondering whether this source/detector inconsistency could affect the measured overlap and possibly also its trend versus output gap.

A second point is that fdtdx seems to return a raw overlap coefficient from compute_overlap(), namely something of the form

alpha_coeff = jnp.sum(E_cross_H_star_sim + E_star_cross_H_sim)
alpha_coeff = alpha_coeff / 4.0

and then the reported quantity is typically taken as

jnp.abs(det.compute_overlap(...))

So in fdtdx, this appears to be a raw overlap-like amplitude constructed from the phasor fields and the detector mode. By contrast, Lumerical’s mode expansion monitor reports quantities such as Tforward, which are already normalized modal transmission results in Lumerical’s convention.

Because of that, I understand that the absolute values from the two tools are not necessarily expected to match exactly unless the normalization conventions are aligned. That part would explain an absolute offset. What I am less sure about is whether the jnp.real(...) step in ModePlaneSource.apply() could also be contributing to the different shape of the transmission-vs-gap curve.

Would that be a reasonable interpretation, or am I missing something else in how ModeOverlapDetector is intended to be normalized/used?

[ymahlau]

Hi @hao14chasing, sorry for the late reply, I did not have time to look at this into detail. I am also not sure where the differences come from. If I find the time, I will investigate a bit more. In general, the use of jnp.real is fine since fdtdx does not implement dispersion and all fields are real always.

Some ideas may be:

• Do you record the same mode in fdtdx and lumerical (TE / TM and same order)?
• There is a small bug in the field interpolation in fdtdx (see Interpolation mask incorrect in interpolate_fields (core/physics/curl.py) #256). I dont think that this should make such a big difference here, but could contribute to differences

If you have any new insights please let me know!

[ymahlau]

@renaissancenerd, could you please take a look if you find anything here? For example, how do the results differ between TE and TM mode with the fdtdx script provided? Also please check if you find any mistakes in the script that may contribute to the difference reported here.

[renaissancenerd]

@ymahlau I suspect the ModePlaneSource to be a root cause because it uses mode_index=0. fdtdx defines TE modes as those where the electric field component along the propagation direction is zero — so for x-propagating modes, TE means Ex = 0, meaning the dominant E-field is in the y-direction (in-plane). Without a filter_pol filter, there is no guarantee that mode_index=0 picks the same polarization that Lumerical's updatesourcemode(1) picks. As per our docs, correct method would be to apply filter_pol="te" to both the source and all detectors so they all operate on the same polarization and match Lumerical's default

[hao14chasing]

Hi @renaissancenerd, thank you for the advice. For my waveguide at 1.55 um, the fundamental mode is TM, and both fdtdx and Lumerical give the same mode. I tried adding filter_pol="tm", but results stay the same for fdtdx.

[hao14chasing]

Hello, is there any updates on this?

[ymahlau]

Hi @hao14chasing, I did not have time to take a closer look at this. I am currently on a work trip and might find the time to take a closer look in the next 2-3 weeks, but cannot promise anything

[hao14chasing]

Thanks for the update and for the care you're putting into this. I really appreciate it—there is absolutely no rush on this end, so please take the time you need.