Issue with absorption profile calculation when using angular redistribution matrix method

[phoebe-p]

Describe the bug
When there is a significant contribution to the interface absorption in the front surface from light which is incident on the front surface from inside the cell, the absorption profiles are not calculated correctly when using RT+TMM to calculate the redistribution matrices. This can be seen by comparing to absorption profiles calculated with either TMM or RT with integrated TMM (no redistribution matrices, pure ray-tracing). This is an unusual situation, because usually the bulk layer would absorb any short-wavelength light which is easily absorbed in front layers, so unless you have e.g. a thin or transparent bulk this is not noticeable, hence why it was not noticed in tests previously. The issue does not seem to occur when other methods are used to calculate the redistribution matrices, possible issue with e.g. binning for the ray-tracing angular redistribution matrix calculations?

IMPORTANT NOTE: All the issues discussed here only affected absorption profiles, and NOT the calculation of total reflection, transmission, and absorption per layer (not position-resolved).

To Reproduce
The issue only seems to occur when the front redistribution matrix is calculated using RT + TMM. If all the matrices are calculated using TMM, or the rear matrices are calculated with RT + TMM and the front matrix with just TMM, the issue does not occur.

The discrepancy appears to be a convergence issue; using enough rays and angular bins gives very similar results when comparing pure RT and RT + angular redistribution matrices.

Expected behavior
For a planar structure, should be able to replicate absorption profiles across methods (TMM, pure RT with TMM probabilities, TMM with angular redistribution matrices, RT + TMM with angular redistribution matrices).

Screenshots

Environment (please complete the following information):

• RayFlare version [e.g. 1.1.0]

[phoebe-p]

With further testing, there was definitely an issue with the bulk absorption profile for light travelling backwards in the bulk, which will be addressed in #55. This was due to the "outgoing" and "incoming" ray definitions used in the matrix multiplication (see here. When calculating the total absorption per bin, which is used to scale the absorption profile to make sure integrated and total absorption agree regardless of the depth spacing chosen. However, when calculating the upwards-travelling profile in the bulk medium (i.e. light reflected from the back and travelling towards the front surface), vf_2 and vb_2 (the binned intensity of the light before and after traversing the bulk) were not in the same format, resulting in incorrect absorption per bin and thus incorrect scaling.

However, the differences in absorption profile when comparing methods for pyramidal textures seem to be due to convergence issue when using the angular redistribution matrix approach. Using a pyramidal back surface (RT + TMM) and a planar front surface (treated with both TMM and RT + TMM for testing purposes) gives very similar results (taking into account random noise from the ray-tracing) in terms of the profile matrices generated, and also agrees well qualitatively with 100% ray-tracing.

GaInP/GaAs/Ge stack (with purposely strange layer thicknesses in order to test this behaviour). Dashed lines = angular redistribution matrices, solid lines = RT with TMM probabilities, no matrices.

Total R/A/T:

Front surface absorption profile:

Back surface absorption profile:

Bulk absorption profile:

scratch_18.txt

[phoebe-p]

Separately, there was an issue when calculating absorption profiles in the surfaces (as opposed to the bulk, as discussed in the previous comment). This was due to a bug when calculating the TMM lookup tables prior to generating the angular redistribution matrices using RT + TMM. When specifying the profile layers (prof_layers= in the Interface), if not all the layers were selected, for the profile coming from the rear the profile would be calculated for the wrong layers because the prof_layers variable was not being flipped appropriately with the structure. This was also addressed in #55.