All sensors in LightLike are temporally-gated integrating sensors. For any simulation, the user specifies a sequence of exposure windows during which a sensor will accumulate light, and this sequence is the key specification that controls the number of propagation calculations that is performed during the simulation run. Successful setup of a LightLike simulation requires understanding of several peculiarities of the LightLike timing system.
The sensor exposure windows are specified by a combination of two types of inputs:
(1) Sensor modules like TargetBoard, Camera, or SimpleFieldSensor all have a set of inputs named "on", "exposureInterval", and "exposureLength". The "exposureLength" is the length (in seconds) of a single exposure window, and the "exposureInterval" is the time interval (in seconds) between the start of successive exposure windows.
CAUTION: most sensors also have an additional input named "sampleInterval", which has a different meaning than "exposureInterval" (see below).
(2) An output of the module called SquareWave can be connected to the "on" input of a sensor, to control the start time of the exposure window sequence.
The inputs "exposureInterval" and "exposureLength" define the underlying periodicity of a sensor's exposure scheduling. The parameters of SquareWave control the start time of the first active exposure window, and can also be used to modulate the underlying gate window repetition sequence. The meaning of modulation in this context is illustrated in example 2 below. If no SquareWave trigger module is attached to the sensor, then the sensor's "on" input must have its value set to "true" to activate the sensor. In that case, the first active exposure window starts at time t=0.
With an exception to be explained below, LightLike only works with time values t >=0. A simulation run always formally begins at t=0, but propagations only occur at those times and intervals required to produce the specified sensor exposures. LightLike operates in "event-driven" fashion, so if there are long time gaps between events there is no impact on wall-clock execution time.
Propagation delay
LightLike accounts for time-of-flight delay in the propagation of light. Suppose a user's timing parameters specify that a sensor exposure window opens at time tk. If the z-distance from source to sensor is L, and the speed of light is c, then a wavefront would have to leave the source at time tk' = tk -(L/c) in order to arrive at the sensor at tk. Depending on L and tk, it is possible that tk' is negative. What happens in that case depends on how the source module was coded. LightLike source modules are not consistent in this regard: some are capable of answering a "request" for emission prior to t=0, but others are not. In order to avoid surprises, we recommend that the user define sensor and trigger inputs so that no exposure windows require light that must be emitted prior to t=0. However, violating this guideline is usually not catastrophic: the sensor may simply report 0 output for those exposure windows that need emissions prior to t=0.
Integration over one "exposureLength", and number of propagations in one "exposureLength"
We stated above that LightLike sensors are "integrating" sensors. Now we discuss more precisely what this means in LightLike.
The default behavior of sensors is as follows. If an exposure window opens at tk, then:
(1) A wavefront is generated at the source at the advanced time tk' , and this wavefront is propagated with physical delays through the intermediate system planes. (These intermediate planes might, e.g., contain moving phase screens, each of which will be positioned at its appropriate transverse locations as the wavefront reaches it).
(2) If "exposureLength"=Texp, then at tkout = tk+Texp , an intensity sensor will report an output value defined by output = (sensor irradiance in W/m2)*(Texp) = (exposure in J/m2). The nomenclature that was adopted in LightLike uses the term "integrated intensity" for the quantity whose units are J/m2.
Note that the default integration procedure defined in the preceding paragraph (2) assumes that the irradiance at the sensor remains constant during "exposureLength". Note also that the default procedure requires only one propagation series for each exposure window. A propagation series refers to the set of propagations and phasor multiplications that are needed to propagate one wavefront from a source, through all phase screens and optics, to a sensor.
If the default integration procedure is not acceptable for the modeling task in question, then an optional sensor behavior can be invoked by explicitly setting the input named "sampleInterval", which appears in all the sensor modules. The default setting is 0.0, which produces the default integration behavior defined above. Changing the setting to a non-0 value (but smaller than Texp) causes LightLike to subdivide each exposure window and propagate several wavefronts, at intervals of "sampleInterval". The individual sensor irradiances are then multiplied by sampleInterval and added, thereby still yielding a single reported exposure (integrated intensity) for a given exposure window.
When output from a sensor is recorded in a .trf file, the .trf file contains a vector of times and a corresponding set of exposure maps, one map for each time. The recorded times are the ends of the exposure windows, denoted above as tkout. The logic for recording the end times is that they represent the times when the outputs are actually available from the physical sensor. In fact, some sensor modules have an optional processing delay parameter (e.g., see Camera). In that case, the recorded .trf times are the ends of the exposure windows plus the processing lag.
Example 1
Consider the following LightLike system:
The propagation distance L=100km has been specified in the AtmoPath module. The SquareWave bool-type output is connected to (and triggers) the TargetBoard bool-type input named "on".
The SquareWave timing parameters are
startTime = 100E3 m / speedOfLight (the constant speedOfLight is an internally
defined symbol in LightLike)
pulseLength = 1.0E6 sec
pulseInterval = 1.0E6 sec
The TargetBoard timing parameters are
exposureInterval = 1.0E-3 sec
exposureLength = 1.0E-4 sec
sampleInterval = 0.0
Suppose also that the simulation stopTime (specified in the Run Set editor) is 3.0E-3 sec.
The specified SquareWave startTime defines the beginning of the first sensor exposure window, and exposureInterval defines the interval between the beginning of successive exposures. Given the simulation stopTime, the following diagram shows the three exposure windows for which propagations will be generated by the above timing specifications. The exposure windows defined by the TargetBoard parameters are indicated by thin black lines, the SquareWave timing pulse is indicated by the heavier green lines, and the simulation Stop Time is the heavy black line:
Since sampleInterval was 0.0, one propagation series will occur for each exposure window, timed so that the wavefront arrives at the sensor at the beginning of the corresponding window.
Notice that the sensor startTime of (100km)/(speedOfLight) means that the wavefront that arrives at the sensor at startTime must be generated by the source exactly at t=0. This is not a requirement for the emission of the first wavefront of the simulation: any time >= 0 is always acceptable.
In the Example 1 system diagram, we entered the timing parameters as numerical values in the value fields of the subsystem blocks. However, we would often prefer to enter variables in the value fields, and elevate these variables to the level of the Run Set editor before assigning specific numbers.
In Example 1, SquareWave's pulseLength and pulseInterval have no effect because they extend beyond the simulation stopTime. Example 2 shows how these parameters can be used to modulate the timing pattern.
Example 2
The following diagram shows how the SquareWave pulseLength and pulseInterval can be used to modulate the sequence of sensor exposure windows that are active. The active exposure windows are those that fall during the high part of the SquareWave signal. The demand for such timing sequences is not particularly high in LightLike practice, but the following special case is often useful. We may often include a diagnostic sensor in a system, and it may be sufficient to record just a few data frames at the beginning or perhaps the end of the simulation run. Suitable combinations of startTime, pulseLength and pulseInterval can conveniently achieve this. Note that a pulseInterval or a pulseLength that extends beyond the stopTIme of the simulation is a legal specification (this feature was already used in Example 1). The simulation stopTime, specified in the Run Set editor, always cuts off the simulation at that designated instant.
