Create a reusable codebase for optics/light sims.

[zepumph]

EDIT: Note that this issue was originally created in the geometric-optics repository, and later transferred to optics-lab.

While working on phetsims/geometric-optics#154, I was thinking about the other sims that are optics/light-related. Bending Light and Optics Lab both seem quite similar to this sim at least in theory. Looking through the common model code between them, I see OPTICS_LAB/SourceModel and GEOMETRIC_OPTICS/SourceObject. I also see a version of a light ray in all three (LightRay.js or RayPath.js).

Was there discussion ever about the potential to reuse some code, or create an optics-like common code repo? I have little understanding of any of these implementations, but I thought I would pose the question to you. Feel free to close.

[veillette]

Thanks MK for bringing this up.
Very early on, we have taken a look at both Optics lab and Bending light. As you point you, they deal with the same subject and share many similarities. Bending light and optics lab are ray driven simulation. As a result they can display the effect of aberrations and coma.
The handling of rays in the two previous simulation is done in a more physical ways where, in the case of bending light, the rays are refracted across a boundary following Snell's law. Optics-lab has not been published and code-reviewed, and may not be a very good example to follow.

I'll leave this issue open an go back and see to what extent we may be able to create some common code.

[zepumph]

Well those sound like great examples to not use either of those two sims as a base for the code you have already written. Perhaps it would make sense to take a look through GO code to see if there is anything foundational or modular that has potential for use elsewhere (like with optics-lab get's worked on next). Currently I feel like the main model types are quite hard coded to the specific case of GO (i.e. only one or two sources or objects, source on the left, and target on the right, etc). Perhaps thinking of how GO code could be refactored to support future optics work would be beneficial. I don't recommend factoring anything out into another repo, but if things like Source, Target and LightRay(s) (for example) where easily adaptable to future sims, that seems really nice.

On the other hand, it is often stupid to generalize too eagerly, as we don't really know the constraints of the next sim. So take this whole issue with a grain of salt, and if you would rather just close it, go for it.

[veillette]

The actual foundational basis of this simulation is that lenses and mirrors follow the thin-lens equation or the mirror equation.
This is used as a ground truth in the simulation. It is unquestionably the right approach from a pedagogical stand point.
However, it is a not a foundational model such as the law of refraction in bending light.

For instance, the simulation deals with very large lens and mirror, which fails the thin lens and paraxial approximation.
As a result, there are some situations, such as the behavior of rays when crossing through the top of a diverging lens, that do not have answers. The thin-lens equation does not offer any guidance on this because it should not occur in this approximation.

The design team is well aware of these limitations and tried to minimize the visual artefacts that can occur and find ad-hoc work arounds. However these ad hoc mechanisms/workaround make it very unlikely that they can be generalized.

Optic Labs is likely do be developed within the next few years but it would be built on a stronger model that involve a local ray model, which is not what is used in this simulation.

On the other hand, there may be a smaller component of the sim that could be teased out for OpticsLab, such as how to go from segments of rays to a shape.

[veillette]

Some of the functionalities found in OpticsLab/RayPath are similar to functionalities in LightRay.
There are a few differences::
RayPath is an array of line segments of finite length. where LightRays is collection of Rays (finite or semi infinite.)
RayPath can generate a shape from the light segments, whereas LightRays generate a shape with an additional time dependency that (can) determine the end point on the last segment.

RayPath can generate a shape and relative shape (relative to the source center) of the rays whereas LightRays only generate absolute positioned shape.

I'll note that RayPath seems like a misnomer, seems it has nothing to do with a SCENERY/Path.

[veillette]

LightRay in Bending light is very hard coded (with 14 parameters in the constructors!). Part of it functionality is to deal with the "wave" nature of a lightray which does not apply here so the isn't much to do about it.

[veillette]

In summary, we could tease out from LightRay a class similar to RayPath (with a better name) that could be used in a future OpticsLab simulation.

[pixelzoom]

In the context of geometric-optics... This late in the game, this would be very difficult and expensive. I have no familiarity with bending-light or optics-lab, and I inherited geometric-optics. So I don't recommend tackling this. And I have high confidence that the Geometric Optics team would agree. (@arouinfar let me know if you disagree.)

I do agree that a reusable codebase for optics/light sims would be valuable. So I'm going to transfer this issue to the optics-lab repository, where that team can decide (preferably early in the life of that sim) whether to tackle this. @arouinfar @veillette @jbphet FYI.