-
Notifications
You must be signed in to change notification settings - Fork 638
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulation results change with resolution #2196
Comments
according to numerical stability of FDTD, you have to have like wavelength/20/index, here, e.g., 500nm/20/3.4, almost resolution close to 135. this should always be in mind. |
Thanks! But the issue remains.
Indeed, satisfying such a stringent requirement is safe, but it does not reveal the rate of convergence as the resolution increases. I wonder whether the rate of convergence is normal. To be specific, in the test, when the resolution amounts to 10 points per wavelength/index=0.5/3.4, the relative error is above 25%. Is such a large error at such a level of resolution normal? By the way, in some built-in examples in Meep, they do not use the resolution as high as 20 points per wavelength/index. For example, the resolution here amounts to 9.2 points per wavelength/index=1.56/3.4.
This issue does not seem a matter of numerical stability. In FDTD, numerical stability typically requires that the time step has an upper bound related to the space increment in the lattice. In Meep, as the default value of the Courant number is 0.5, the time step is always adjusted accordingly unless it is otherwise specified. |
Oh, sorry, It is called the numerical dispersion that requires space discretization as dx (in 3D) < lambda / 12 / index ~ close to resolution 82. in experience, the lambda here should be the minimum wavelength of the light source (at max frequency in gaussian source). so, in your case, lambda is around 454nm, the required resolution should be at least 90. in fact, about the time sampling, dt < T/12 should be fulfilled as well. So, to me, FDTD has two conditions to make good simulations: one is the courant conditon dt< 1/sqrt(3) dx; the other is space discretization, dx < lambda (in medium) / 12. as soon as all these two conditions are fulfilled, you can get close to the true propagations. otherwise, the light phase speed will mess up and the simulation can not be trusted. |
Although the source contains a range of frequencies, the two black curves in the last figure above (where I just supplemented the curve for the relative error) were evaluated at a single frequency, which was the central frequency. When the range of frequency is shrunk from 0.4 to 0.1, the change in these two curves are negligible.
Sometimes we may not obtain satisfactory results when the two conditions are fulfilled. In the previous example, the relative error is about 15% when the two conditions are fulfilled (and the time step obeys a more stringent condition by default). It does not seem acceptable. The code for calculating the sum of adjoint gradients using an
|
when the two conditions are fulfilled, in theory, it guarantees error within around 1~2%. However, this numerical error accumulates while propagating, so resolutions might need to be higher to get that accuracy. In terms of gradients, I think there are some problems are not solved, especially for bloch-boundary where the manually introduced boundary condition break the Lorentz-transformation. However, while doing reversing k-point in simulation settings or k-point are all zero, it should work. based on what I know of meep, it has problems as follows: I have a feeling, it is the setting of adjoint source that introduce the problem, which seems to be a big issue. I tested for 3D a few months ago, and it has big error as well. I need to find out that result. |
I'm not sure there is actually an issue here — the key point is that when you have a phenomenon involving a sharp resonance, even a tiny shift in the resonant frequency can cause a huge change in the transmission. In your plot at the top, at a resolution of 40 (about 20 pixels/λ in air but only about 7 pixels/λ in the dielectric), the resonant frequency is shifted by about 10%, which is actually pretty good, but of course this causes a huge change in the transmitted power at any particular frequency. This also happens in practice, because even if your Meep calculation is infinitely precise, when you go to manufacture a structure the resonant frequencies will inevitably be shifted by a few percent. To compensate, the experiment needs to either be able to tune their operating frequency or to tune the structure (e.g. thermally). |
So, in practice, what you are interested in is the convergence of the peak value. Above, for a resolution of 40 (= 7 pixels/λ in the dielectric), your resonant frequency is off by about 10% and the peak transmission is also off by about 10%. This seems quite reasonable to me. |
As for adjoint gradients, you don't want the adjoint gradient to match the infinite resolution (exact Maxwell) solve. You want the gradient of your (approximate) forward solve, so that optimization can evolve the parameters to improve the forward solve. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
It seems that simulation results may not quickly converge as resolution increases. Here is an example, where the transmission spectrum is calculated as the normalized transmission power. The central wavelength is 0.5. The structure is as follows.
The transmission spectra for a series of resolution are as follows. The unit of resolution is the number of points per unit length.
The normalized transmission power at the central frequency (=2) under a series of resolution is as follows. If we assume that the result at the resolution 200 is correct, we need the resolution to be higher than 90 in order to attain a relative error below 10%, and we need the resolution to be higher than 110 in order to attain a relative error below 5%. Is this situation normal?
The code for calculating the transmission spectrum at a given resolution is as follows.
The text was updated successfully, but these errors were encountered: