flexcompute / tidy3d

Fast electromagnetic solver (FDTD) at scale.
https://docs.flexcompute.com/projects/tidy3d/en/latest/
GNU Lesser General Public License v2.1
190 stars 44 forks source link

Results do not match Lumerical #411

Closed joamatab closed 2 years ago

joamatab commented 2 years ago

Hi!

How can we make the FDTD simulations match lumerical FDTD?

Im running tidy3d-beta==1.4.0

See Sparameters for a 1x2 mmi in tidy3d

image

here is what i think is happening. At one wavelength the mode solver is finding the wrong mode

image

momchil-flex commented 2 years ago

So it seems that it's just that the mode plane covers a part of the other waveguide. By default, we have PEC boundaries at the edges of the mode solver. So this essentially makes a spurious waveguide which I guess turns out to have a higher effective index than the central waveguide at that frequency. Have you actually done the exact same simulation with Lumerical? What boundary conditions do you use for the edges of the mode plane?

More practically, the modes you're looking at seem very strongly confined. It seems that you can decrease the mode plane span along y (and z, just cause why not) without a loss in the accuracy, and this should fix the problem. Let me know!

joamatab commented 2 years ago

even when I make the y span = 0.2, which computes the correct modes image

the Sparameters have some issues

image


         top view
              ________________________________
             |                               |
             | xmargin_left                  | port_extension
             |<------>          port_margin ||<-->
          ___|___________          _________||___
             |           \        /          |
             |            \      /           |
             |             ======            |
             |            /      \           |
          ___|___________/        \__________|___
             |   |                 <-------->|
             |   |ymargin_bot   xmargin_right|
             |   |                           |
             |___|___________________________|

        side view
              ________________________________
             |                     |         |
             |                     |         |
             |                   zmargin_top |
             |xmargin_left         |         |
             |<---> _____         _|___      |
             |     |     |       |     |     |
             |     |     |       |     |     |
             |     |_____|       |_____|     |
             |       |                       |
             |       |                       |
             |       |zmargin_bot            |
             |       |                       |
             |_______|_______________________|
momchil-flex commented 2 years ago

So now this looks like it may be a little too close? You could try an intermediate value between these two tries. I am really guessing here though... It's hard to debug without access to the actual simulation. Could you share the json so that I can import it and have a look?

joamatab commented 2 years ago

Here is the actual simulation

https://gdsfactory.github.io/gdsfactory/notebooks/plugins/tidy3d/00_tidy3d.html

momchil-flex commented 2 years ago

The mode source in ports 2 and 3 is injecting in the wrong direction. It's a bit hard to see the arrow here but you can see it once you know it, or you can check s.sources and see that direction is "+".

image

What is happening is that there's a small numerical-error power injected backwards, but since you normalize everything to the total power backwards (which is very small), results look like they kinda make sense, but there's a big signal to noise ratio.

Bottom line: this is a simulation setup issue in gdsfactory, so I'm closing this.

joamatab commented 2 years ago

Hi!

i fixed the port orientation but the strange spectrum persists

image

joamatab commented 2 years ago

https://github.com/gdsfactory/gdsfactory/pull/453

momchil-flex commented 2 years ago

I ran this with the latest version of gdsfactory and port_margin=0.6 and the results look good: image

Same results with port_margin = 0.9 actually.

How do you clean cached results in gdsfactory? If I try to rerun this now (e.g. changing the port margin), it just loads the data from the previous run. To force it to rerun I changed the wavelength range. It seems that in the last image you sent, the cached results were loaded. Maybe that's why it still looks bad, cause it didn't rerun with the updated source orientation?