You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: