-
Notifications
You must be signed in to change notification settings - Fork 3
Description
In the function ϵ_hole_layers and ϵ_pillar_function, there are subpixel averaging. Now let us take the former function as an example. In the code, the weight for the subpixel averaging is weight_eps_hole, which is given by
half_width = ps[it_holes]/2δ - w_offset
n_half_width = floor(Int64, half_width)
weight_eps_hole = half_width - n_half_width
Here w_offset is defined as
if x[nx÷2] == 0
w_offset=1/2
else
w_offset=0
end
When I use this code, the elements in the array x is positive by default and hence w_offset is zero by default. Beside, the default value of δ is 0.025.
There is a glitch when ps[it_holes] takes some special values. For example, for ps[it_holes]=0.35, the correct values of half_width, n_half_width, and weight_eps_hole should be
half_width=7, n_half_width =7, weight_eps_hole=0.
However, when ps[it_holes]=0.35 is in Float64, Julia gives the results below:
half_width=6.999999999999999, n_half_width =6, weight_eps_hole=0.9999999999999991.
The same situation happens for ps[it_holes]=0.7. The correct values of half_width, n_half_width, and weight_eps_hole should be
half_width=14, n_half_width =14, weight_eps_hole=0.
However, when ps[it_holes]=0.7 is in Float64, Julia gives the results below:
half_width=13.999999999999998, n_half_width =13, weight_eps_hole=0.9999999999999982.
Similar situations happen when ps[it_holes]=0.35 and 0.7 are in Float32 or BigFloat. When using Float16, the values of weight_eps_hole produced by Julia are 0.001953125 and 0.00390625, which are close to the correct value (zero) but not accurate.
I think the glitch can be largely removed when we choose Chebyshev points for ps[it_holes], because in most cases Chebyshev points are not so special as 0.35 or 0.7.