search

NanoComp / meep

free finite-difference time-domain (FDTD) software for electromagnetic simulations
GNU General Public License v2.0
1.26k stars 629 forks source link

normalize gaussian beam source to unit power #1444

Open oskooi opened 3 years ago

oskooi commented 3 years ago

It would be useful to normalize the GaussianBeamSource such that the integral of its normal Poynting vector over the entire cross-section is 1. This should be straightforward given the analytic expression for the fields from the "complex point-source" reference which is implemented in gaussianbeam::get_fields in meep/src/sources.cpp. (Note that the expression for the electric field in Equation 4 of the reference is normalized to unity at the center of the beam waist.)

The benefit would be that a separate normalization run to compute the flux from just the source would be unnecessary when computing transmittance. Also, this choice of normalization would be consistent with EigenModeSource.

smartalecH commented 3 years ago

I think the actual power would still depend on the discretization, however -- just as with the EigenModeSource. The margin is probably small and the error, by definition, approaches zero with larger resolutions.

oskooi commented 3 years ago

Similar to the eigenmode source, the choice of normalization would not effect the discretization errors for backward-propagating fields and dispersive errors for off-center pulse frequencies.

smartalecH commented 3 years ago

would not effect the discretization errors for backward-propagating fields and dispersive errors for off-center pulse frequencies.

That's not related.

What I'm referring to is the difference of an analytic calculation assuming continuous time, versus the actual discrete-time implementation that meep uses.

The whole point of normalizing upfront is to avoid a separate normalization run. However, if the power you calculate analytically is different from what's actually being injected, that's a problem.

As I mentioned, this difference will decrease with resolution.

oskooi commented 3 years ago

The power that is computed for the gaussian beam would be based on the same fields used by the source itself (which is created using fields::add_volume_source(const src_time &src, const volume &, gaussianbeam beam). Thus, in effect, computation of the power does not involve any discretization error.

chenyudong92 commented 3 years ago

I found the GaussianBeamSource could only set for TM modes (Hx, Hy or Ez). When I change component to Hz (Ex or Ey), the results is nothing. Could I get a way to set TE component for this source?

smartalecH commented 3 years ago

Odd, I've used it for arbitrary polarizations. Maybe make sure you are visualizing the right field (especially for 2D simulations).

chenyudong92 commented 3 years ago

Odd, I've used it for arbitrary polarizations. Maybe make sure you are visualizing the right field (especially for 2D simulations).

Thanks for your mention. This problem solved by checking polarizations.

smartalecH commented 2 years ago

@oskooi are you still interested in implementing this feature?