# Total internal reflection: case of simple interface glass/air

#1

I have a plane-wave source incident at an angle of 45 degrees from glass to air. In the
prospective of exciting a gold nanoparticle on the top of the glass. It is a 3D simulation, one particle so PML all around. I put a movie monitor to see what happens and I notice that I’m getting a part transmitted all the time. (even without the nanoparticle). I only chose one wavelength of 532 nm in order to avoid the wavelength-angle dependence. I don’t
understand the source of error. (with 45 degrees angle of incidence glass/air interface, I’m expecting total internal reflection + evanescent waves).
Thank you very much in advance!

#2

@aberr.al-mahtar

I think the problem is because the plane wave source is not meant to be used with PML boundaries at the sides, as it truncates the plane wave causing diffractive edge effects:

You can consider using a TFSF source instead of a plane wave source, and this will inject a plane wave with a finite span. There are also some examples which simulate particle scattering that you can take a look at in the Knowledge base:
https://kb.lumerical.com/en/index.html?particle_scattering.html

This video also has a good discussion about the simulation setup for single particles on a substrate:
https://www.lumerical.com/solutions/materials/video/introduction_plasmonic_simulations.html

I hope this helps!

#3

Thank you very much for your reply. I tried the TFSF source as well as Gaussian source. I do have the same problem :(, though I made a mesh refinement (conformal 1) at the boundaries and I choose the PML to be far from any scattering (with option of steep angles). I’m always having a transmitted part.

#4

@abeer.al-mohtar

Here is an example file which uses a setup similar to the one shown in your original post but using a TFSF source instead of a plane wave source at 532 nm wavelength:
TIR_example.fsp (234.1 KB)

I also added a monitor inside the TFSF source region in the air above the glass substrate to measure the fraction of power transmitted to the air. Using the default settings (standard PML profile, mesh accuracy 2, and conformal variant 0 mesh refinement method) the transmission was less than 0.2% and I believe it can be attributed to numerical error and should be reduced by using a finer mesh.

Are you seeing a much larger transmission value in your simulation file? If so I would be happy to take a look if you could share a copy of your file.

#5

You are right the transmission is less the 0.2%, but way greater than the scattered field
from the gold nanoparticle thus created a huge background. However, using TFSF
solved the problem of background :). I just have two more questions:
1- I’m interested in calculating sigma (scattering cross-section) in the upper half-space. I placed a monitor exactly
like monitor “T” in the TIR_example.fsp you sent me (my simulation is 3D). I’m just not sure if I should normalize the sourceintensity by multiplying it by cos(theta):

m=“monitor”;
f=getdata(m,“f”); #get frequency vector
T=transmission(m); # get power transmission (fraction of source power)
sp=sourcepower(f);
out = sourceintensity(f)cos(45);
sigma=T
sp/out; #calculates the scattering crosssection

2- I need the continuous response of my structure and I read that “The CW response of a structure can easily be
obtained from a simulation that used a pulse source”. I’m not sure I know how to do it. Is lumerical answer regarding sigma for example the CW response? I got different answers if I check/ uncheck the “optimize for short pulses” in wavelength/frequency tab of the source option. Thanks for clarifying its effect.
Thank you very much

#6

@abeer.al-mohtar

Regarding your first question, you don’t need to multiply sourceintensity with cos(theta) since that is already incorporated within the sourceintensity script command. You can confirm this by running a test where you change the injection angle of the source and plot the sourceintensity result over angle.

Regarding your second question, I would expect that you should get the same sigma result from a frequency domain monitor result between using the “optimize for short pulse” option and not using it. You may want to double check the normalization state of your simulation file by going to the “Setting” titlebar menu and making sure the CW normalization is on.

If you are still seeing different results please let me know!

#7

Thank you

1- See the
sourceintensity with normal incidence and compare to that at 45 degrees. I
noticed that if:

I_normal=sourceintensity
#at normal incidene

I_45=sourceintensity
#at 45 degree incident.

The result
is: I_45=I_normal+20%

2- I ran
two tests (with CW normalization on). and noticed that
sigma_optimized_for_short_pulse=sigma_not_optimized +20%.

My
simulation confirmed what you said just within 20% range :(. Do I need to use a
finer mesh or use optimized source since it is more accurate?

Thank you again :).

Thank you again :).

#8

@abeer.al-mohtar

I suspect that it could be related to the simulation time being too short, so the longer pulse does not have time to fully propagate through the simulation region, but it’s difficult to tell without seeing the file. If you have an example file where you are seeing the difference between the optimized short pulse and the longer pulse when the “optimize for short pulse” option is not enabled I would be happy to look into it if you could attach a copy!

#9

Please find attachedsigma_correct.lsf (260 Bytes) a copy of my file. I’m using the monitor “monitor” and using this imple script to deermine sigma because I’m only interested in collecting in the upper space:
m=“monitor”;
f=getdata(m,“f”); # get frequency vector
T=transmission(m); # get power transmission (fraction of source power)
sp=sourcepower(f);
out = sourceintensity(f);
sigma=T*sp/out; #calculates the scattering crosssection

I’m getting with optimized for short pulse: 2.759e-16
without it checked: 2.2e-16

Thank you very muchcorrect.fsp (274.5 KB)

#10

@abeer.al-mohtar

I found that when I de-selected the “optimize for short pulse” option in the source, the source pulse which is injected takes about as long to inject as the entire specified simulation time of 80 fs, so the pulse did not have time to fully decay before the maximum simulation time was reached. When I increased the simulation time up to 2000 fs, I found that this was enough time for the simulation to reach the auto shutoff threshold and the results were much closer to matching the case where an optimized short source pulse was used. A good discussion about the effect of ending the simulation too early can be found here:
https://kb.lumerical.com/en/index.html?ref_sim_obj_frequency_monitors_simulation_time.html

Other suggested changes are to use symmetry for the y min boundary condition to help reduce memory requirements and simulation time, and to use a uniform mesh over the entire x and y span of the TFSF source to improve the performance of the source. This point is discussed under the “Particle on a surface at non-normal incidence” section on this page:
https://kb.lumerical.com/en/index.html?ref_sim_obj_tfsf_sources_examples.html

Please try it out and let me know if it helps!

#11

One more question if I use the source with “optimized for short pulses” option is it accurate to use simulation time 50 fs?

#12

@abeer.al-mohtar

Yes, since the optimized short pulse has a much shorter pulse length, it does reach the auto shutoff threshold within 50 fs. You can double check that the auto shutoff threshold was reached by opening up the log file which is saved to the same working directory (the file name should be “correct_p0.log”). You can open the log file using any text editor and check for the line “Early termination of simulation, the autoshutoff criteria are satisfied.”

If the log file shows that the simulation reached 100% and doesn’t contain the message that the simulation was terminated early then you would need to increase the maximum simulation time and re-run the simulation.

#13

Thank you very much :). you’ve been a great help!

#14

Hello again!
Upon comparing lumerical results to a matlab code based on green’s function. I noticed that lumerical has problems defining the angle of injection. While I understand that having a broadband source results in a varying angle (inclined injection). I don’t understand at all the discusion in:
https://kb.lumerical.com/en/ref_sim_obj_plane_waves_-_angled_injection.html
I mean when we specify in the source that we need 45 degrees angle of injection why does it appear 30 degrees?
More over in my simulation I need 45 degrees with a single lambda of 532 nm. In my general source characteristics, I’m putting 45 deg and I’m getting like 38!!!test.fsp (280.8 KB)

Can you provide me with more explanation?

#15

Hi,

The angle may appear to be different from the specified angle due in the CAD drawing, so it’s best to check the angle of the fields that is actually injected.

I tested this by taking the simulation file and removing all structures from the simulation so the source is injected in free space, I then plotted the real part of Ey to see the phase fronts of the angled plane wave:

Then to determine whether the light is travelling at 45 degrees, I looked at the peak of Ey at x=0 and found that the peak occured for z=0.53 um. Then along the same phase front at x=0.5 um the peak occured at z=0.03 um. The difference in x and the difference in z between the two points along the phase front is equivalent (0.5 um), which indicates that the wave is propagating at 45 degrees.

Hopefully this helps!

#16

Dear Nancy,
I’m back to this post, because I’m interested now in studying the near-field of a single structure over a substrate. So, I need to put a monitor within the excitation region of TFSF source. I’m so bothered with the transmission percentage at an angle of total internal reflection. No transmission is expected. Again, we are considering at glass/air interface with incidence in glass at 45 degrees, I retook your .fsp and I placed a monitor just after the source to see the total injected transmission and I was surprised that the total injected transmission is 0.0085 and the transmission to air (that is the numerical error) is 0.0007 which is huge. Though I used a mesh of 0.7 nm. Can you please let me know the source of such a huge error!
Thank you,
Abeer

#17

I just forgot to attach the file. Here it is.TIR_example_edit.fsp (253.3 KB)

#18

I believe the issue is that the power normalization by default is by the power injected in the main injection plane which doesn’t represent the total power injected by the source in this case, similarly to what is discussed under the “Power normalized to the source power” section on this page:
https://kb.lumerical.com/en/index.html?ref_sim_obj_tfsf_power_normalization.html

For the TFSF source, the power normalization can be unintuitive, but the fields within the total field region should still represent what you would see if the source was infinitely wide injecting a plane wave with maximum electric field amplitude of 1, so it would still be fine to look at the field values around the particle in the near field.