unit test for mode decomposition in 3d

[oskooi]

Adds a missing unit test for the mode-decomposition feature in 3d. This is based on verifying that the reflectance and transmittance (obtained using the Poynting flux) for a 3d silicon grating on a silicon dioxide substrate using a normally incident planewave from the substrate is equivalent to the sum of the Poynting flux (obtained using mode decomposition) of all the individual reflected and transmitted diffracted orders.

Unfortunately, while the transmittance in air is equivalent for the two methods the reflectance is not which is causing the test to fail. Here is the output from the actual run. The second column are the results obtained using mode decomposition and the third column is the Poynting flux.

refl:, 0.10166823054447949, 0.1309250065061772
tran:, 0.8774699636319175, 0.8770360580866046
sum:,  0.979138194176397, 1.0079610645927817

[stevengj]

Does it work if you get rid of the substrate (e.g. air above and below)?

[oskooi]

Replacing the substrate with air improves the agreement in the reflectance values somewhat. Nevertheless, the difference is still large enough that the test is failing:

refl:, 0.016781793607059767, 0.01874350601300043
tran:, 0.9957095363765546, 0.9952349354146496
sum:,  1.0124913299836142, 1.01397844142765

A hint as to what might be the cause of this behavior is revealed if this critical line is removed:

sim.load_minus_flux_data(refl_flux,input_flux_data)

The reflectance result for this arbitrary test case is unexpected:

refl:, 0.01708516443766082, -0.9807934242633807

Note that the value obtained using meep.Simulation.get_eigenmode_coefficients (0.01708516443766082) has changed very little compared to its previous value of 0.016781793607059767. Contrast this with the large change in the value obtained using meep.get_fluxes (-0.9807934242633807) relative to its previous value of 0.01874350601300043.

Related to this, I have recently observed several other instances of incorrect reflectance results for different test structures and configurations all involving the use of the function load_minus_flux_data in 3d. This may be because the load_minus_flux_data feature has not been properly tested in 3d until now. There could be a bug somewhere that has gone undetected. It may be more suitable to create a separate issue for this topic.

(More generally, we ought to have more unit tests in 3d. With the exception of a couple of tests involving a 2d cell with out-of-plane wavevector which is technically a 3d simulation, none of the unit tests are actually in 3d.)

[stevengj]

This may be because the load_minus_flux_data feature has not been properly tested in 3d until now.

This seems very unlikely to be the source of the problem; nothing is really different here between 2d and 3d.

[oskooi]

Turns out there was no bug after all: the grid resolution simply needed to be increased. However, because the required resolution to demonstrate two digits of accuracy in the reflectance values is 200 pixels/μm which leads to an excessively long run time (of several hours) for this unit test, I just increased the relative tolerance when comparing the values.