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

Line in epsilon-matrix for non-integer geometric_center #1554

Open
HelgeGehring opened this issue Apr 23, 2021 · 2 comments
Open

Line in epsilon-matrix for non-integer geometric_center #1554

HelgeGehring opened this issue Apr 23, 2021 · 2 comments
Labels

Comments

@HelgeGehring
Copy link

Hey, for a simulation (with the latest git-version) I found a strange output for the epsilon values. I've reduced it to a minimal-example:

import numpy as np
import meep as mp
import matplotlib.pyplot as plt

# geometry = [mp.Prism([mp.Vector3(*x) for x in [(70., 0.), (70., 1.), (77., 1.), (77., 0.)]],
#                     height=1, material=mp.Medium(epsilon=2))]
geometry = [mp.Block(center=mp.Vector3(74, 0), size=mp.Vector3(7, 2), material=mp.Medium(epsilon=2))]

sim = mp.Simulation(cell_size=mp.Vector3(79, 15), resolution=15,
                    geometry_center=mp.Vector3(35.5, 0), geometry=geometry,
                    boundary_layers=[mp.PML(2)], subpixel_maxeval=0)

sim.init_sim()

epsilon = sim.get_epsilon()
print(np.unique(epsilon))
plt.imshow(epsilon[1100:])
plt.colorbar()
plt.show()

print(np.unique(sim.get_epsilon()))

As output I get (where the second line is not always the same):

[1.         1.04347826 1.2        1.5        1.84615385 2.        3.        ]
[1.         1.04347826 1.2        1.41176471 1.5        2.        ]

and in the plot there's an additional horizontal line:
plot
also when getting the epsilon the second time, there's still this line.

What I noticed:

  • It happens with both geometries in the script
  • The position of the line depends on the PML-thickness and is quite close to the PML
  • If I change the geometric_center to integer numbers, everything's alright
  • Without subpixel_maxeval=0 the problem remains. I also found an example where this line is not constant and the numbers get far higher
@oskooi
Copy link
Collaborator

oskooi commented Apr 23, 2021

There is a known bug in geometry_center (see e.g. #1335) which has not yet been resolved. Running your example as-is, the values output from get_epsilon() that I am seeing also includes nans.

In your example, if you remove geometry_center from the Simulation object constructor and shift your Block object accordingly, the results are as expected:

geometry = [mp.Block(center=mp.Vector3(74-35.5, 0), size=mp.Vector3(7, 2), material=mp.Medium(epsilon=2))]

output

Using MPI version 3.1, 1 processes
-----------
Initializing structure...
time for choose_chunkdivision = 0.000194522 s
Working in 2D dimensions.
Computational cell is 79 x 15 x 0 with resolution 15
     block, center = (38.5,0,0)
          size (7,2,0)
          axes (1,0,0), (0,1,0), (0,0,1)
          dielectric constant epsilon diagonal = (2,2,2)
time for set_epsilon = 0.0873263 s
-----------
[1.         1.04347826 1.2        2.        ]
[1.         1.04347826 1.2        2.        ]

epsilon

@oskooi oskooi added the bug label Apr 23, 2021
@HelgeGehring
Copy link
Author

Thanks for the quick reply! For integer numbers it seems to work alright for me. I'll keep an eye on that and if I encounter any problem I'll just avoid using geometric_center. Thanks!

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

No branches or pull requests

2 participants