Problems in designing Metagrating3D with Meep #31
Comments
|
Since this is a single-frequency problem and the accuracy of the adjoint gradients seems to degrade with increasing source bandwidth (as demonstrated in NanoComp/meep#2314), can you try redoing your test using a narrower bandwidth source, e.g. |
|
Apart from the issue above, the results may change when the number of processes changes. The above tests used 32 processes, but the results with Ex source become different when only 1 process is used. The comparison of the results between 1 process and 32 processes is as follows. The relative difference is calculated as On the other hand, the change in the results with Ey source is negligible. The tests here also use |
|
With random design parameters |
|
Unlike However, to make the setup smaller, I did not add |
|
Here is a different issue. I ran @oskooi's meep script |
|
The optimization is ongoing. The latest design pattern is as follows, which is not completely binarized. The resolution of FDTD simulation is 50 while the resolution of the design region is 100. The minimum length scale constraint is not imposed, but I set a minimum length of 50 nm to obtain a filter radius for the conic filter, which is 111.8 nm. The Meep script is as follows, which resembles @oskooi's script. |
|
For reference, here is the minimum lengthscale constraint function (borrowed from @mochen4's LDOS cavity optimization) and the optimization setup I used when testing the single-frequency waveguide mode converter while debugging #32. Also, to ensure a binarized final design, you may also want to include damping in the def glc(x, gradient, eta, beta):
"""Constraint function for the minimum linewidth.
Args:
x: 1d array of size Nx*Ny containing design weights.
gradient: the Jacobian matrix with dimensions (Nx*Ny,
num. wavelengths) modified in place.
beta: bias parameter for projection.
"""
filter_f = lambda v: mpa.conic_filter(
v.reshape(Nx,Ny),
filter_radius,
design_region_size.x,
design_region_size.y,
design_region_resolution,
)
threshold_f = lambda v: mpa.tanh_projection(v,beta,eta)
geom_c = (filter_radius/design_region_resolution)*5000
g_s = mpa.constraint_solid(
x,
geom_c,
eta_e,
filter_f,
threshold_f,
resolution,
)
g_s_grad = grad(mpa.constraint_solid,0)(
x,
geom_c,
eta_e,
filter_f,
threshold_f,
resolution,
)
gradient[:] = np.asarray(g_s_grad)
return float(g_s) betas = [8, 16, 32, 64, 128, 256]
max_evals = [70, 70, 70, 100, 100, 100]
for beta, max_eval in zip(betas,max_evals):
solver = nlopt.opt(algorithm, n)
solver.set_lower_bounds(lb)
solver.set_upper_bounds(ub)
solver.set_min_objective(lambda x, g: f(x, g, eta_i, beta))
solver.set_maxeval(max_eval)
solver.set_param("dual_ftol_rel",1e-8)
# apply the minimum linewidth constraint
# only in the final "epoch"
tol_lw = 1e-5
if beta == betas[-1]:
solver.add_inequality_constraint(
lambda x, g: glc(x, g, eta_i, beta),
tol_lw,
)
x[:] = solver.optimize(x) |
|
Thanks! However, minimum-length-scale constraints were not imposed when 3d metagratings were designed by RETICOLO/RCWA. Instead, only some filtering and projection were involved there. To make a fair comparison, perhaps we should not impose minimum-length-scale constraints either when performing optimization with Meep? Alternatively, should minimum-length-scale constraints be imposed on both RETICOLO/RCWA design and MEEP/FDTD design? |
In principle, the Reticolo/RCWA designs should have been designed using minimum lengthscale constraints. For the three devices designed using Reticolo/RCWA and checked into this repository ( |
Imposing constraints based on these minimum length scales may lead to additional issues. The details are as follows. These minimum length scales arise from device1.csv, device2.csv, and device3.csv, but according to You Zhou's email, these design patterns were not obtained directly from optimization, but were interpolated from the optimized design patterns. The pixel size of the design region in optimization is about 12 nm, while the pixel size in the interpolated design patterns (device1.csv, device2.csv, and device3.csv) is about 3 nm. The minimum length scales you mentioned above are measured from the interpolated design patterns, not from the design patterns obtained directly from optimization. To make a fair comparison, we may need to use the same design-region resolution as that in their optimization, which corresponds to the pixel size of 12 nm. Consequently, the measured minimum length scales, i.e., 25 nm, 12 nm, and 37 nm, amount to the sizes of only 2, 1, and 3 pixels. Imposing constraints based on such small length scales may be problematic. Even if those minimum length scales are successfully imposed, checking them using |
When the resolution is 200, the TM-polarization deflection efficiency calculated by Meep for
After more iterations, the structure became nearly binarized. The optimized deflection efficiency is 90% when the resolution is 50. However, when the resolution is 200, the deflection efficiency for the same structure is only 45%, which may imply a frequency shift, i.e., the working wavelength of the device is different from the target wavelength. The spectrum is as follows, where the dashed line indicates the target frequency, i.e., 1/1/05=0.952. |
These results are based on interpolated design patterns, which are not raw design patterns obtained directly from optimization. The minimum length scales of the raw design patterns are different. As listed here, the minimum length scales of the raw design patterns are 58 to 74 nm. These values are not at the single-pixel level because the size of a pixel is 11.6 to 11.7 nm. |
|
The evaluation history of the objective during optimization is as follows. Before the 280th iteration, there are |
|
As discussed, when using the damping feature you should probably turn off subpixel smoothing since there could be a bad interaction between the two when the design is greyscale (i.e., the weights are intermediate between 0 and 1) which is degrading the accuracy of the adjoint gradient and thus spoiling the optimization. Note that the left figure above does indicate the presence of intermediate weights which is where the adjoint gradient is largest in the right figure. Ideally, the adjoint gradient should be non zero only along the discontinuous contours. |
I used To binarize the design pattern, I tried to impose length-scale constraints, but all attempts so far lead to degradation of the objective function. |
|
In |
In my experience, as a hyper-parameter, c only needs to be at the right order of magnitude. So in practice it is equivalent. For the problems I worked on, I found the order is closer to |
I also tried this and found that the value of |
|
When I set |
You should use the beta (projection) from the material grid (design variable); you should change beta there, something like |
Sorry for my misunderstanding. I thought this only applied to the last epoch where Now using this format with When the resolution is 200 in fdtd simulation, the peak diffraction efficiency becomes 95.9% and the peak frequency shifts to 0.964, which is 1.2% higher than the target frequency, i.e., 1/1.05=0.952. The diffraction spectrum is as follows. The minimum length scale estimated by |
|
The diffraction efficiencies reported in README.md of Metagrating3D are not the maximum efficiencies around the target frequency. For example, the spectrum of diffraction efficiency of Device2 is as follows. The spectrum of diffraction efficiency of Device3 is as follows. |
|
The sharp rectangular corners in the design pattern may result from rectangular shapes of filter kernels in Meep, as mentioned here. I am not sure whether the rectangular shapes have adverse effects on topology optimization, especially the binarization process and length-scale constraint, but I should probably change the filter kernels back to circular shapes and redo the optimization. |
|
Here I use kernels with circular shapes and Starting from a random guess, the evaluation history and the optimized design pattern are as follows. The optimized diffraction efficiency at the target frequency is 96.3%, which is calculated in the forward run of the adjoint solver. |
The adjoint and finite-difference gradients are inconsistent when the
EigenmodeCoefficientadjoint solver in Meep is applied to a case similar to that in @oskooi's metagrating-meep.py. The tests were based on the latest version of Meep, namely, v1.25.0. The code ran with 32 processes. The comparisons between adjoint and finite-difference gradients are as follows.The code is as follows. It defines the same geometry as that in metagrating-meep.py, but does not include
DiffractedPlanewaveand the input flux.The text was updated successfully, but these errors were encountered: