Splitting
Input-output connections of the Light data type must be one-to-one, yet we frequently want the same wave or waves to impinge on two or more different sensors, or more generally to be sent through two or more different optical paths. The splitting may correspond to an actual physical beamsplitter in the optical system we are modeling, but it may equally well be an artificial splitting that allows us to study the effects of two different optical processing arrangements or sensors. The mechanism provided for this purpose is a set of library components whose basic version is the Splitter. Splitter has one LightLike input and two LightLike outputs, and simply produces two copies of the incident LightLike. Note that Splitter does not act exactly like a physical beamsplitter: each output LightLike from Splitter is identical to the incident LightLike in all respects, includingenergy. That is, Splitter does not conserve total energy. Although this restricted implementation may initially seem peculiar, it was motivated by the need for duplication rather than physical splitting in the original LightLike code development.
If the user wishes to model the attenuation aspects of a physical beamsplitter, two methods are available: (a)Attenuator components can be added to the two output paths of Splitter, or (b) alternate library components such as LabSplitter can be used.
The basic Splitter is sufficient for all purposes, but a number of variations are also included for convenience. Potentially convenient variations (convenient mainly for display reasons) carry names such as IncomingSplitter and OutgoingSplitter. However, we emphasize that the plain Splitter is itself applicable to either incoming or outgoing waves.
The system that was illustrated in the tutorial exercise in preceding chapter of the User Guide is a typical example of the use of LightLike splitters: after incoming light passed through a Telescope module, the LightLike was split (duplicated) by using an IncomingSplitter and then sent to two different types of sensors, namely the Camera and the SimpleFieldSensor. Note that the two sensors can occupy exactly the same physical space in this example, since the splitting is meant to be interpreted conceptually here. If desired, one sensor could be transversely offset from the other by introducing an extra TransverseVelocity module. A plain Splitter module could have been used instead of IncomingSplitter. If we added an outgoing wave from a new source, that wave could be passed without modification through the "outgoing" input and output of IncomingSplitter. However, the basic Splitter could still be used even then, since it is permissible to simply bypass the Splitter component with the outgoing connection: the only advantage of the IncomingSplitter is that it may help to prevent obscuration of the outgoing connecting line by the Splitter icon.
Combining
In addition to splitting LightLikes, it is often necessary to combine two or more LightLikes into one. A typical example occurs when we want to send light, say in the "incoming" direction, from more than one source through the same atmosphere. The AtmoPath module only accepts one incidentIncoming LightLike input, so this is handled in LightLike system building by using a Combiner module to create a single composite LightLike for input to AtmoPath (or other relevant modules). The composite LightLike output by Combiner should be viewed simply as a container that carries all the unmodified, separately generated LightLikes: there is no physical interaction implied by the Combiner operation.
As in the case of Splitter, variants of Combiner such as IncomingCombiner and OutgoingCombiner may be convenient for display purposes, but are not necessary.
The following picture gives another illustration of Combiner and Splitter usage. Light from two sources, a PointSource and a UniformWave, is packaged by a Combiner into a single LightLike, passed through an atmophere module, and then split by a Splitter to impinge on two different types of sensors. There are several important features to be noted in this example.
First, note that Splitter sends a copy of the complete incident Light, i.e., light from both sources, to each sensor. However, because of the source and sensor wavelength parameter settings (highlighted by the red bars in the picture), the Camera only sees the PointSource, and the TargetBoard only sees the UniformWave.
If the wavelengths of the two sources were equal, and we still wanted to have each sensor see only one of the sources, then an extra distinguishing tag would have to be applied to each wave. LightLike provides "polarization" tags for this purpose.
Combining and separating light with polarization tags
At the end of the preceding example, we noted that Splitters and Combiners are not always enough to ensure that only the desired beams strike the desired sensors in a LightLike system. The LightLike machinery provides one additional degree of freedom for this purpose, namely the feature of "polarization" tags. "Polarization" is manipulated using library components like Polarizer and PolarizingSplitter. We put "polarization" in quotes here because LightLike's polarization has some unphysical aspects designed for convenience of simulation. For details on how to use the LightLike polarization tags, see the section on polarizers in the Modeling Details chapter.