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

Overlapping Source inside Object #22

Open
0xDBFB7 opened this issue Jul 9, 2021 · 1 comment
Open

Overlapping Source inside Object #22

0xDBFB7 opened this issue Jul 9, 2021 · 1 comment

Comments

@0xDBFB7
Copy link
Contributor

0xDBFB7 commented Jul 9, 2021

I was trying to build a (dubious) test-case for current density by putting a source in a conductive medium, like so:

grid[x_,y_,z_] = fdtd.AbsorbingObject(permittivity=1.0, conductivity=conductivity)
grid[x_,y_,z_] = fdtd.PointSource(period=500)

The source E-field seems to always be forced to zero in this case. The source works when the objects are added in the other order.

I might be doing something wrong, just posting this issue to ask what the expected behavior should be when troubleshooting - is the overlapping case allowed and meaningful?

Thanks!

(tangentially related, should adding an object inside a PML maybe throw an exception? Do you know of any cases where that would be a valid thing to do?)

@0xDBFB7 0xDBFB7 closed this as completed Jul 9, 2021
@flaport
Copy link
Owner

flaport commented Jul 9, 2021

Hey Daniel,

Please give me some time to answer before closing the issue 😉

Anyway... I assume this is related to the internals of how this library works:

  1. If an object is added to the grid, the refractive index 'behind' the object is put to 0. This causes some problems and ideally a better solution should be found (see removing objects doesn't reset grid permittivity #4 and new grid permittivity strategy & issues with PML and Objects #6 ).
  2. Adding objects inside the PML is not recommended. The PML in this library is implemented pretty naively, which unfortunately makes it not so easy to combine with custom objects. It would indeed be better to raise an Exception right now.
  3. To solve the above issue, the PML probably has to be implemented differently... probably stretched coordinates or uPML... unfortunately I lack the time (and expertise?) to implement something like this right away... (feel free to give it a try and open a PR 😉)

@flaport flaport reopened this Jul 9, 2021
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

2 participants