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

Intensity definition and units #2051

Open
doddgray opened this issue Nov 1, 2024 · 1 comment
Open

Intensity definition and units #2051

doddgray opened this issue Nov 1, 2024 · 1 comment

Comments

@doddgray
Copy link

doddgray commented Nov 1, 2024

The intensity property of ElectromagneticFieldData, calculated here:

def intensity(self) -> ScalarFieldDataArray:

appears to be the local electric field magnitude squared. This seems inconsistent with the standard definition (ex. RP Photonics) which scales with the local refractive index in isotropic media or more generally as E*ε*E. Or maybe I am misunderstanding something?

If the fields have units of [Volt/micron] then it looks like this intensity has units of [Volt^2/micron^2] rather than [W/micron^2]or [W/cm^2].

I've been looking at this for ModeFieldData in case that changes the interpretation or units.

@momchil-flex
Copy link
Collaborator

I think I agree with you, that definition would make more sense. When it comes to units though the fields are indeed Volt/micron, so it is our definition of intensity that is kind of wrong, not the fields themselves.

I think part of the confusion came from the fact that the intensity function was implemented for the mode area computation, using the formula here where both |E|**2 and I can be used but that's just because the normalization constants cancel out, not because they are equivalent.

Unfortunately there are some caveats with modifying the intensity definition in our current code:

  • If we want to be able to return the value with the epsilon, we don't actually store the permittivity, and the permittivity obtained from the frontend Simulation.epsilon is not going to be the solver one in the subpixel regions. Also, we generally store colocated field values, and in principle to get an accurate epsilon * E * E you should do the product on the Yee grid and only then colocate.
  • We generally try not to introduce brekaing changes, so modifying the existing behavior of that specific function is something we would avoid even if wrong.. We might instead try to deprecate that function in favor of another one, but the first issue still remains and may require another refactor (like an option to store D in the monitors?)

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