Should Raysect v1 just support polarised light?

[CnlPepper]

Abandoning the unpolarised light code path would simplify the optical package considerably. The cost is a reduction in performance for unpolarised calculations (exact throughput reduction to be measured, but likely to be of the order of 20-25%), though accuracy of reflections etc... would obviously be substantially improved.

This decision would obviously have an impact on cherab.

[jacklovell]

If the performance impact is moderate, I would follow your advice from the Readme:

The general development philosophy is ease of use trumps performance, but performance is not to be ignored.

It sounds like a single code path would result in a considerable improvement in ease-of-use (both for end users and maintainers), larger than the reduction in performance.

Since Cherab already makes heavy use of caching and interpolating, perhaps some of the performance could be clawed back through improvements there, such as https://github.com/cherab/core/issues/50.

[vsnever]

I looked through the new code in v1/feature/polarisation. Even at this stage, it is already clear that maintaining both polarised and unpolarised versions of all related classes and methods would be very painful. I support the idea of abandoning the unpolarised light calculations, even at the cost of performance.

[CnlPepper]

Thanks for the feedback. I have been heavily leaning to abandoning the unpolarised code. I've run a quick Cornell box test, it is looking to be a ~20% hit, but I think I can claw a lot of that back moving the internals from numpy to python.array.

[CnlPepper]

Decision has been made that v1 will implement only polarised light propagation.