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

Confusion with negative permittivity #1441

Closed
Vinc0110 opened this issue Dec 2, 2020 · 5 comments
Closed

Confusion with negative permittivity #1441

Vinc0110 opened this issue Dec 2, 2020 · 5 comments

Comments

@Vinc0110
Copy link

Vinc0110 commented Dec 2, 2020

Negative permittivity values apparently cause problems in the simulation, as explained in the FAQ:
https://meep.readthedocs.io/en/latest/FAQ/#why-does-my-simulation-diverge-if-the-permittivity-is-less-than-0

I'm now wondering why the predefined perfect electric conductor (PEC) material is then using epsilon=-inf instead of epsilon=+inf:

meep/meep.i, line 1780:

perfect_electric_conductor = Medium(epsilon=-inf)

If I attempt to model an imperfect electric conductor replacing the PEC, say a copper sheet with a frequency-dependent complex epsilon using a LorentzianSusceptibility with a magnitude of around 1e6 to 1e7, the Eigenmode decomposition with MPB for the EigenModeSource does not work anymore and the fields seem to blow up.

However, If I flip the sign for a negative permittivity, MPB does work again, the simulation finishes and I'm getting correct results. The only problem is a RuntimeWarning and a lot of confusion, because this seems to contradict the statements in the FAQ.

RuntimeWarning: Epsilon < 1 may require adjusting the Courant parameter. See the 'Numerical Stability' entry under the 'Materials' section of the documentation

It would be nice if someone could clarify what's going on here and give a hint how to properly model a lossy metal that works with EigenModeSources. After all, the examples in meep/materials.py are also using positive permittivity values.

@Vinc0110 Vinc0110 changed the title Confusing with negative permittivity Confusion with negative permittivity Dec 2, 2020
@stevengj
Copy link
Collaborator

stevengj commented Dec 2, 2020

What is actually used in the FDTD algorithm is 1/ε. So, it doesn't matter for perfect metals if ε=±∞, since in either case you get 1/ε = 0.

@stevengj stevengj closed this as completed Dec 2, 2020
@stevengj
Copy link
Collaborator

stevengj commented Dec 2, 2020

properly model a lossy metal

You need to use dispersive materials.

that works with EigenModeSources

These use MPB, which only supports non-dispersive materials with ε > 0. See also #1319 for how we might improve this in the future.

@Vinc0110
Copy link
Author

Vinc0110 commented Dec 7, 2020

Thanks for the explanations.

These use MPB, which only supports non-dispersive materials with ε > 0. See also #1319 for how we might improve this in the future.

Does this also mean that it's not currently possible to simulate complex scattering parameters when dispersive materials are involved (i.e. any realistic materials), because Meep's mode decomposition feature also relies on MPB?

@Vinc0110
Copy link
Author

Vinc0110 commented Dec 7, 2020

In the documentation for the EigenModeSource, I just read that any dispersion will be ignored by MPB during mode calculations. Is it ignoring the entire material, or just the resulting imaginary part of the permittivity?
In the latter case, the result should still be close enough and the EigenModeSource profile and the mode decomposition for calculating scattering parameters should work. This is however not the case for my simulations.

@stevengj
Copy link
Collaborator

stevengj commented Dec 7, 2020

@smartalecH enabled some support for dispersive materials in #919, so the documentation should be updated to reflect that. It ignores the imaginary part of the permittivity, however.

Nevertheless, it still won't support negative permittivity, since MPB requires ε and μ to be positive-definite.

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