The optical quantities that we model using LightLike are usually described analytically in terms of continuum (x,y,z) coordinates. For computer modeling we must represent a continuum quantity by a sampled function on a discrete lattice, or mesh of points.
Nomenclature note: the term "grid" is often used in the general literature in a sense equivalent to "lattice" or "mesh". However, in LightLike the term "grid" has been appropriated to designate a data type that comprises the combination of a mesh of points together with function values defined on that mesh. We will attempt to maintain consistent terminology in the documentation: we will try to use "mesh" or "lattice" when we mean just a mesh of points, and to reserve "grid" for its specialized LightLike meaning.
Grid spacing, dimension and offset
In the present section, we introduce several important facts about the LightLike meshes used for physical (Fresnel) propagation, for phase screens, for detector sample points and other purposes. Later sections of the User Guide provide further details and sample usages, in the context of specific LightLike subsystems or of specific functions used to define meshes. The purpose of the present section is to gather in one place some general properties of and key facts about the LightLike meshes. Almost all the meshes used in LightLike are uniform rectangular meshes aligned with the x and y axes. The dx and dy spacings and the nx and ny dimensions may be allowed to differ, although for many applications equal x and y parameters are appropriate.
There are several variations in the data entry format, but LightLike meshes are almost always specified in terms of the parameter set (nx, ny, dx, dy), or a notation like (nxy, dxy) to specify a square mesh using just two parameters. In the following discussion we will use the notation (x, nx, dx) for brevity to refer to either dimension. In addition to (nx,dx), the remaining specification required to completely determine the mesh coordinates is the offset from x=0. The offset determination can be somewhat confusing in LightLike, so we now discuss this in some detail.
Most situations can be satisfactorily modeled with two options: either the mesh is forced to have a point at x=0 or the mesh is symmetrically disposed with respect to x=0. At the LightLike code level, these mesh types are constructed using functions named "gwoom" (= "grid_with_origin_on_mesh") and "GridGeometry". The two examples in the following diagram define the offset convention for the case nx = even:
The key rules for nx = even are:
(1) In the gwoom mesh, the nxy/2 point (counting from 0) lies at x=0.
(2) In the GridGeometry mesh, the points are symmetrically positioned relative to x=0.
The following two examples define the offset convention for the case nx = odd:
Note that when nx = odd, the two mesh-defining functions produce identical meshes.
The LightLike user is not always allowed to choose whether a gwoom or GridGeometry mesh will be used. In many LightLike library modules, the user is simply asked to enter (nx,dx), but is not asked to specify whether a gwoom or GridGeometry mesh should be used. In such cases, the mesh type will be a gwoom, unless module documentation explicitly specifies otherwise. As an example, consider the TargetBoard system in the left panel of the following picture. The parameter list calls for the specification nxy with no option to specify the grid type: this will be a gwoom mesh. The same situation holds for the sensor meshes in the SimpleFieldSensor and Camera sensors. An exception to the more common pattern is the HartmannWfsDft sensor module: again the user is just allowed to specify (nx,dx) parameters in the sensor plane, but this time a GridGeometry type of mesh is used.
In other library modules, the user is allowed to specify the choice of gwoom or GridGeometry in addition to the (nx,dx) specification. An example is the SensorNoise block shown in the right-hand panel of the above figure. In this case, the data type of the input parameter (left-most column) is itself named GridGeometry: that is the signal that the user must enter a setting expression in the value field (right-most column) which is written in terms of either the function gwoom(...) or the function GridGeometry(...). An example using the GridGeometry function is shown in the figure. Further details of the allowed input syntax for gwoom(...) and GridGeometry(...) is given in the User Guide chapter on data entry.
Propagation Mesh
The propagation mesh, i.e, the mesh on which Fresnel propagation calculations are performed, has some special restrictions. This mesh is specified in PropagationController, AtmoPath, or analogous subsystems. In order to use highly optimized FFT (Fast Fourier Transform) routines, LightLike requires that nx for a propagation mesh be a power of 2. (Even if the user enters a non-power-of-2, LightLike will round up to the nearest power.)
In addition to the power-of-2 restriction, there are other constraints on the propagation mesh (nx, dx) that should be observed in order to avoid DFT (Discrete Fourier Transform) aliasing and wrap-around effects. These issues are discussed in a separate section. The propagation mesh is a gwoom, unless explicitly specification to the contrary is allowed in a propagation module.
Phase Screen Mesh
The mesh on which phase screens are defined is specified in AtmoPath, GeneralAtmosphere or analogous modules. To allow for relative transverse motion of the screens, sources and sensors, without repeating the screens, one may specify screens that are much longer in one dimension than another. The screens are also computed using FFT routines, but there is no power-of-2 constraint in this case. The screens must only be computed once, at the beginning of a LightLike run, so it is acceptable to be non-optimally efficient here. Another slight difference in the way phase screen meshes are specified is this: the spacing dx is still an input parameter, but instead of nx the user must specify the span of the screen in meters.
Further explanation of the phase mesh specifications, and how these interact with the transverse motion specifications, is deferred to a separate section.
Interpolation
When one LightLike module operates on the discrete complex field or other output of the preceding module, it is often necessary to interpolate the preceding output onto the mesh of the current module. This is frequently necessary even if we set those mesh items under our direct control so that the meshes are registered as much as possible. For example, suppose we have a simple static system consisting of a source, an AtmoPath module, and a TargetBoard sensor. In this case, (nx,dx) specs are requested in AtmoPath to define the propagation mesh and phase screen mesh, and in TargetBoard to define the points at which the final irradiance will be sampled. Since all these meshes are gwooms as described above, if we specify a common dx value then the mesh points of all the modules coincide and no interpolation is necessary. However, if we introduce any relative displacement in the system, such as wind, target motion or just static displacements, then it will frequently happen that the displacement for a simulation time step is not a whole number of mesh points. In that case, LightLike must internally interpolate to pass the optical data from some modules to others. No special action is required by the user to effect this: LightLike takes care of this matter internally. However, the user should be aware that interpolation is frequently occurring, because there are occasionally surprising artifacts that arise from the interpolation. These artifacts are more likely to occur when the complex field must be interpolated as opposed to a real irradiance map.