Grid Attributes Introduce Numerical Artifacts?

[mboug]

Hello,

I have been trying to use fdtd-solutions to compute the absorption and scattering spectra of a 35 nm diameter Au sphere in the presence of an external magnetic field. In order to properly treat the difference in permittivity experienced by right- and left-handed circularly polarized light, I’ve been utilizing a user-defined, 3D-sampled permittivity tensor (diagonal anisotropy), and then creating a permittivity rotation grid attribute (as described: https://kb.lumerical.com/en/materials_anisotropic.html). To generate the circularly polarized incident fields, I use two TFSF sources with identical positions & geometries, but with orthogonal polarizations and a relative phase shift of 90 degrees. However, the results I get from running the simulations seemed incorrect - when running the simulation as described above, I observed an additional spectral feature at ~675 nm, redshifted from the LSPR, which I did not expect, but persisted as I varied parameters such as the simulations time, early-termination cut-off, FDTD simulation domain size, mesh override region, etc…

After varying many different parameters, none of which solved this issue, I’ve finally begun to think that this may be a numerical artifact associated with the utilization of the permittivity rotation grid attribute. In an attempt to confirm this, I’ve run three simulations of the same physical situation (.fsp files attached), but with 1) a single linearly polarized source and no grid attribute, 2) circularly polarized source (as described above) and no grid attribute, 3) circularly polarized source with the permittivity rotation grid attribute enabled. In all cases, the strength of the external magnetic field was set to zero so that the permittivity tensor of the sphere is diagonal and isotropic (this is to ensure that circular and linear polarizations lead to identical absorption and scattering spectra - this was also confirmed using Mie theory). Therefore, I would expect all three methods should produce identical scattering and absorption spectra. Instead, I get:

Judging from these plots, it seems that enabling the grid attribute somehow affects the resulting spectra even though it should have no effect. Is this an effect that is well documented/expected for the types of simulations I am running? Any comments/guidance you could provide would be greatly appreciated in helping me understand if I am somehow setting up the simulations incorrectly, or if this is a shortcoming of the FDTD method.

Please let me know if any clarification of the problem is needed, and thanks very much in advance!

Simulation files:

1. linear polarization, no grid attribute: 35nm_Au_linear.fsp (364.4 KB)
2. circular polarization, no grid attribute: 35nm_Au_m90_diag.fsp (402.6 KB)
3. circular polarization, grid attribute enabled: 35nm_Au_m90.fsp (405.2 KB)

File containing Real & Imag. xx, yy, zz permittivity components used to generate the user-defined 3D-sampled material:
Au_anistropic_0T.txt (5.1 KB)

[bkhanaliloo]

Dear @mboug

Thank you very much for a detailed topic and providing all the supporting documents.

I checked your simulation file and I noticed that for 35nm_Au_m90.fsp you are using a matrix transformation grid attribute that is not unitary:

This means that basically the material simulated in this simulation file will behave differently than the material on other two simulations. Can you please explain why you chose this U transformation? Maybe you can try a unitary U matrix and compare the results?

On another note, there might be some slight changes using grid attributes due to, for example, meshing algorithm used in grid attribute, which we can improve the discrepancy if this happens. Please see the link below for more information:
https://kb.lumerical.com/en/materials_anisotropic_tip_grid_attribute.html

Please keep me updated with your thoughts and we can discuss it in more details if you had any questions.

Thanks and have a great weekend.

[mboug]

Hello - thanks very much for your response!

However, I am not quite sure I understand why the U matrix I have defined in file 35nmAu_m90.fsp is incorrect. I defined that matrix in analogy to the transformation used in the Faraday Effect tutorial (https://kb.lumerical.com/en/other_application_faraday_effect.html). I see from this example that the matrix transformation is defined in such a way that: epsilon_diagonal = U epsilon_cartesian U^(dagger), as is specified under “General anisotropic materials” section here: https://kb.lumerical.com/en/materials_anisotropic.html. The way I have U defined in 35nmAu_m90.fsp also conforms to this diagonalization convention.

Could you point out where I am going wrong here?

Also, could you provide any links/references that explain in detail how the field components are computed when using these permittivity rotation grid attributes?

Thank you very much!

[bkhanaliloo]

Dear @mboug

Thank you for additional info and my apologies for the confusion.

I think I understand it better now, thanks to your clarifications.

Basically, since index_xx = index_yy = index_zz, a matrix transform grid attribute that rotates material (like the one in KB page or in your simulation file), should not affect the results.

Since your simulations were taking too long due to fine mesh, I used a coarser mesh ( FDTD mesh accuracy of 2, 2.5nm mesh override, and PML layer of 8) and, surprisingly, obtained identical results for all three cases:

This is being said that if grid attribute affects the results, we expect that the error to become smaller as we use finer mesh. So, I am not sure why we have better results with coarse mesh! I recall this warning from grid attribute tips:

Spatial offset of field components within FDTD Yee cell approximation

In all FDTD simulations, each field component is calculated at a slightly different position within the Yee cell. At cells which contain material interfaces, grid attribute transformations are applied only to field components where there will be no mixing of field components in different materials.

This can introduce some additional error into the simulation, compared to a similar simulation without a grid attribute object. In some cases, this approximation can introduce asymmetries into otherwise symmetric systems. Reducing the mesh step size can help reduce these errors, but in some cases at interfaces between materials with high index contrast, it is challenging to make the mesh size sufficiently small.

From your first post, it looks like none of the employed practices helped to remove the the discrepancy. So, I am not quite sure how grid attribute is affecting your simulations.

I will ask around to see if someone has a similar experience. In the mean time, can you please try coarser meshes and report the results? Also, try modifying attribute to an identity matrix and see if the problem is still there.

Also, could you provide any links/references that explain in detail how the field components are computed when using these permittivity rotation grid attributes?

I will discuss it with R&D and will get back to you when I have a clear answer for you.

I hope this was useful.
Thanks

[bkhanaliloo]

Dear @mboug

I focused on the linear case, with and without grid attribute, to employ symmetries and run quick tests. While the results were converging as I was decreasing the mesh size, so far, the results of with and without attribute are identical:

I will run overnight tests with fine meshes as yours (reducing FDTD span to 800nm in all directions for quicker runs) to see if the results you are seeing is specific to the mesh choice. I will keep you updated with the results.

Thanks

[mboug]

Dear @bkhanaliloo,

Thanks again for your assistance with this topic. I’m also running some additional tests overnight and will post the results tomorrow.

Thanks!

[mboug]

Dear @bkhanaliloo,

What size mesh were you using in the mesh override region in your most recent simulations? I’ve re-run the three simulation files I attached in my initial post, but this time with 1 nm mesh override instead of 0.5 nm. Somehow, with this set of parameters, I get different spectra for all three simulations:

This is very surprising to me, as I’ve only changed the mesh in the override region, and left all other parameters alone …
It is also very strange that your simulations with ‘relaxed’ simulation parameters (lower mesh accuracy, smaller simulation region, larger mesh override, etc …) produce identical results with and without the grid attribute.

In case they’re useful, here are my most recent simulation files:
35nm_Au_linear.fsp (356.8 KB)
35nm_Au_m90.fsp (387.8 KB)
35nm_Au_m90_diag.fsp (386.0 KB)

[bkhanaliloo]

Dear @mboug

I ran the simulation for circular polarization (with and without grid attribute), and the results for both scattering and absorption spectra were identical:

Scattering:

Absorption:

The only difference between my and your simulation file is the FDTD simulation
region (which is 800nm rather than 2000nm in your case). Mesh size and the number of PML layers are identical as yours. Below I have attached the simulation file for your review.

Since I have not observed any differences in my runs, I was not able to investigate the problem and do not have a clear answer for you yet. Maybe you can run my simulation files and check if you are seeing any differences? Also, if you are not using the latest version, I recommend to upgrade it to the latest version (v8.17.1157). This might be some bug on the previous versions which is fixed in the latest version.

We can discuss it more if the problem did not resolve yet.

35nm_Au_m90.fsp (412.6 KB)

35nm_Au_m90_noAttribute.fsp (403.3 KB)

Thanks

[bkhanaliloo]

Dear @mboug

I just wanted to follow up and see if you had a chance to run my simulation files? Any update if you could resolve the problem will be quite useful.

Thanks

[mboug]

Hi @bkhanaliloo,

I have run your simulation files with Lumerical v8.11.318 and v8.12.631. Both of these versions produce different results for the two simulation files you provided similar to the plots in my earlier posts. I’m still working on updating to v8.17 on the cluster my simulations are running on. I will provide another update once I’ve run your files on a more recent version.

Thanks

[bkhanaliloo]

Hi @mboug

Sorry for any inconvenience again.

Those two are very old version (5-6 years old!) and there is a high chance that feature has been upgraded and modified for much precise simulations in the most recent versions.

Please let me know if you had any further questions.
Thanks

[mboug]

Hi @bkhanaliloo,

Apologies for the delayed response, but wanted to provide a brief update. I’ve now re-run the simulation files you provided in your May 26 post using a Lumerical v8.16, and I get absorption and scattering spectra identical to yours. So it seems the issue is indeed a bug in the earlier versions of the Lumerical software.

Thanks very much for your assistance in tracking down this issue!

[bkhanaliloo]

Thanks for updating me @mboug, and I am glad that problem is resolved.