Skip to content
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

Glitch in subpixel averaging #1

Open
mawc2019 opened this issue Aug 8, 2020 · 0 comments
Open

Glitch in subpixel averaging #1

mawc2019 opened this issue Aug 8, 2020 · 0 comments

Comments

@mawc2019
Copy link

mawc2019 commented Aug 8, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant