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

variable distance between injection source and monitor #327

Merged
merged 2 commits into from
Apr 22, 2022

Conversation

tylerflex
Copy link
Collaborator

@tylerflex tylerflex commented Apr 19, 2022

To compute S_ii elements in the S matrix, we need to place a monitor at approximately the same position as the i-th source. They could not be at the exact same location due to numerical issues. So we decided to place the monitor one grid cell away.

This only supported uniform mesh, because we knew what this grid cell was. In nonuniform, choosing this distance becomes a bit more tricky.

For now, I just made the distance a parameter (default of 0.1 um) that is a Field of the ComponentModeler and can be changed by the user. I added a bit of description on how to do this.

This will eliminate errors from using ComponentModeler when nonunform is default. We may want to revisit this PR to come up with a way to choose this distance automatically based on the local grid_size.

At the least, let's just make sure this PR gets merged around the same time as the main nonuniform changes.

@tylerflex tylerflex linked an issue Apr 19, 2022 that may be closed by this pull request
Copy link
Contributor

@shashwat-sh shashwat-sh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Out of curiosity, what were the numerical issues when the source and monitor were collocated?
  • When the monitor is placed one cell away (in the pre-GridSpec or the new case), the monitor would still have a thickness of a couple cells, so would a part of it still intersect with the source plane? If that's the case, and if there is interpolation during the sampling of fields on that monitor, I wonder if those numerical issues may affect the results anyway. If so, it may be worth trying to address those numerical issues and avoid the shift (in the future).

@momchil-flex
Copy link
Collaborator

  • Out of curiosity, what were the numerical issues when the source and monitor were collocated?

I think it's really just about the interpolation. The Yee fields themselves are correct everywhere, but they are zero to the left of a certain point, and nonzero to the right, and if you're in the same cell and try to interpolate, you're missing the ones on the left.

However, now that I'm saying this, we may even want to test what happens if they are placed in the same cell. I think the tangential fields should be correct. These are all you need to compute modal overlap in the case of normal incidence, but most generally we could have slanted waveguides, where you'll need all three components.

  • When the monitor is placed one cell away (in the pre-GridSpec or the new case), the monitor would still have a thickness of a couple cells, so would a part of it still intersect with the source plane? If that's the case, and if there is interpolation during the sampling of fields on that monitor, I wonder if those numerical issues may affect the results anyway. If so, it may be worth trying to address those numerical issues and avoid the shift (in the future).

So yeah, it is all about ensuring that all components can be interpolated, and just one cell away achieves that.

@momchil-flex
Copy link
Collaborator

I think you should just try the following, roughly speaking: put the monitor exactly where the mode is specified, then

grid_normal = sim.grid.boundaries.to_list[normal_axis]
monitor_ind = np.argwhere(monitor.center[normal_axis] < grid_normal)[0]
source_offset = sim.grid.sizes.to_list[normal_axis][monitor_ind]

Potentially with some check that monitor_ind is not None or out of bounds for the sizes array.

@momchil-flex momchil-flex merged commit 40f89c0 into develop Apr 22, 2022
@tylerflex tylerflex deleted the tyler/nonuniform_smatrix branch April 22, 2022 21:19
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

Successfully merging this pull request may close these issues.

S matrix nonuniform
3 participants