Closed briandleahy closed 3 years ago
Re: the naming of S1-S4. Our general (though unwritten) policy is to retain the notation used by Bohren and Huffman. The notation here follows B&H, though the convention precedes them.
FWIW, van de Hulst also uses the S1-S4 notation for the elements of the amplitude scattering matrix, as do other codes like scsmfo1b and mstm. I agree that it's not the most physically illuminating, but it seems to be enough of a convention in the scattering literature that I would personally argue against changing it.
Best, Jerome
On Mon, Dec 14, 2020 at 4:35 PM vnmanoharan notifications@github.com wrote:
Re: the naming of S1-S4. Our general (though unwritten) policy is to retain the notation used by Bohren and Huffman. The notation here follows B&H, though the convention precedes them.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/manoharan-lab/holopy/issues/380#issuecomment-744725274, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3MN4GJ3SUS243HAEL2C4LSU2AKBANCNFSM4U3LFZQQ .
Thanks for the feedback! Just to clarify, the main point of this PR isn't about the S1-S4 notation, but about the way the xarray dims and coords are defined. Right now, the matrix is defined like this:
The labels were presumably chosen to describe the rows of the matrix, but that's not actually what they represent as dims and coords. Here's a naming scheme that more correctly describes the transformation being done by the scattering matrix:
Currently,
ImageFormation.calculate_scattering_matrix
returns the scattering matrices in a confusing format, cf Line 160ff ofimageformation.py
:The dimensions of the returned xarray should describe the two dimensions of the 2x2 scattering matrix, not just the two rows.
We should decide what is the best way to return the scattering matrices as an xarray. (I would also advocate for a better naming convention than S1, S2, S3, and S4, since I can never remember how these relate to the parallel or perpendicular components....)
Since this is a user-facing change we should make sure that any change does not break existing workflows.
@barkls feel free to edit this issue as you see fit. (I'm not 100% sure I understand the problems you mentioned in the discussion on #377.)