lbolla / EMpy

Electromagnetic Python
MIT License
194 stars 83 forks source link

VFDModeSolver fields different from commercial software #21

Closed blyves closed 7 years ago

blyves commented 7 years ago

Hey, I plan to use EMpy in order to calculate the fields for different waveguides. So far, I have been using a commercial software (Lumerical) but EMpy would be much more convenient since I could integrate it into other python scripts. However, after comparing the fields from the EMpy example (http://lbolla.github.io/EMpy/#example_modesolver) for the 2nd mode to the solution of the commercial software, I found them to be quiet different:

In order to check the E to H field relation I calculated the magnetic field from the Electric field using:

image

For the commercial software the resulting field is of the same order of magnitude as the field magnetic field calculated by the solver. For EMpy this is not the case.

Do I need to adapt anything in the example code? Thank you for your help.

EMpy linear scale: empy linear

Lumerical linear scale: lumerical linear

EMpy logarithmic scale: empy log

Lumerical logarithmic scale: lumerical log

lbolla commented 7 years ago

It looks like you are using different boundary conditions? For EMpy, the "walls" of the box seem metallic (null electric fields), but for Lumerical they are not. Can you try to set the same boundary conditions and try again?

blyves commented 7 years ago

The boundary conditions are only slightly different (see below). However, the reason for the fields not decaying to zero in the plots above is the following. The simulation window was chosen to be larger in Lumerical. The plots above are a zoom, in order make it easier to compare them to EMpy. So the actual boundaries are not visible. The reason why I chose the simulation window to be so large is the slow decay of the fields.

To get a fair comparison between the two, I simulated both for a simulation window of 5 um * 5 um for an equal amount of mesh points. The differences are still the same as above. A further increase of the simulation window has basically no effect.

EMpy logarithmic Scale: empy log large

Lumerical logarithmic Scale: lumerical log large

Boundary Conditions: I cannot choose the exact same boundary conditions but I don't think that they are the reason for the difference.

For EMpy I chose boundary = '0000' (Hx and Hy are zero immediately outside of the boundary).

In Lumerical they are set to be "Perfect Electric Conductor" (PEC). The component of the electric field parallel to a metal (PEC) boundary is zero; the component of the magnetic field H perpendicular to a metal (PEC) boundary is also zero.

boundary condition pmc
lbolla commented 7 years ago

It's close to impossible for me to do the comparison "visually". But, given that you are interested in modes of a rectangular box, with PEC walls, analytic solutions are available, that you can compare with both EMpy and Lumerical.

DanHickstein commented 7 years ago

The results look pretty similar now, within a scaling factor. How do the effective indices compare?

When comparing EMpy results with COMSOL, I found that I needed to be careful to generate the mesh with the correct dimensions for the waveguide. In EMpy, it's relatively easy to have the effective size of the waveguide be off by a pixel, which can cause disagreement with other software.

blyves commented 7 years ago

Thank you, for the fast reply. I really appreciate this.

I don't think that the results look the same apart from a scaling factor. I am sorry if the plots are not so clear. I will try to explain my concern more precisely.

The magnetic field in EMpy is 2 orders of magnitude larger than in Lumerical whereas the electric field is 1 or 2 orders of magnitude lower. To me, there seems to be an issue in the relation between the electric field and the magnetic field. This is why I calculated the magnetic filed from the electric field using: image

This is plotted in the third row. In the Lumerical plots the third row is very similar to the second row. So the relationship between the E and H field is how I would expect it to be. For EMpy this is not the case. The magnetic field calculated from the electric field (third row) is much lower than the magnetic field from the simulation (second row). I have observed this in all simulations that I have done in EMpy.

About the meshing: I indeed need to be more careful when choosing the mesh. I have adjusted the mesh and redone the simulation. The effective index was affected and now matches Lumerical (1.76776 and 1.7659). However, the fields were basically not affected by the meshing. They still look exactly the same as plotted above.

I even see the issue of the E to H relation if I use the example code (http://lbolla.github.io/EMpy/#example_modesolver). Do I misunderstand something in the E to H relation or could there potentially be an issue with the solver?

lbolla commented 7 years ago

What unit of measures is Lumerical using? MKS? cgs? Else?

blyves commented 7 years ago

MKS

lbolla commented 7 years ago

Can you post the complete code of the example? I thought you were running ex_modesolver.py, but I get different results from the screenshots you attached, so I assume you are running some other simulation?

blyves commented 7 years ago

https://gist.github.com/blyves/fca51a00560ecf6b8975c88d5cd2f531

This should give you the EMpy plots of the first comment.

lbolla commented 7 years ago

Right, I think the issue is that your epsfunc does not really return eps in MKS, but rather n^2. It's as if you had set the speed of light = 1 and mu_0 = 1, too. If you do so in your script, numbers will match better.

I would not try to compare field profiles too much, as they depend on what kind of algorithm Lumerical is using (finite difference, some kind of multipole expansion, etc.). Instead, I'd concentrate on comparing the effective indexes and making sure that the fields that are supposed to be continuum or discontinuum are so. Also, are you sure both EMpy and Lumerical's solutions have converged?

blyves commented 7 years ago

Thanks a lot. That solved the issue.