WaveTrain: A User-Friendly Wave Optics Propagation Code
Steve Coy
MZA Associates Corporation, Albuquerque, NM 87106
abstract
WaveTrain is a software tool for high fidelity modeling of advanced optical systems such as laser weapons systems and compensated imaging systems. It makes use of a well established modeling approach known as "wave optics", in which optical wavefronts are modeled using two-dimensional meshes of complex numbers. Wave optics is the most powerful approach known for predicting the performance of optical systems in the presence of strong turbulence. WaveTrain differs from previous wave optics modeling tools primarily in that it is much easier to use. Historically, wave optics codes been notoriously difficult to use with the result that only a very small number of people - the code authors and a few others - could use the codes effectively. WaveTrain is designed to make wave optics accessible to a much broader user community. In WaveTrain, the user assembles system models in a "connect-the-blocks" visual programming environment, where each block represents a system component such as an optical sensor, a laser source, a mirror or a lens. Each connection represents a specific type of interaction: for example, connections between optical components represent optical interfaces. WaveTrain provides a GUI for setting up parameter studies and a Matlab[1] interface for postprocessing.
Keywords: WaveTrain, wave optics, diffraction optics, modeling, simulation, Airborne Laser
1. Background
Wave optics simulation has become an indispensable tool in the design and analysis of advanced optical systems, especially systems that involve imaging and/or beam projection through the turbulent atmosphere. There is no other practical way to capture the optical effects of turbulence in the context of complex closed loop systems, and these effects are important design and performance drivers. Because of this, many organizations engaged in the design and analysis of such systems have come to rely on wave optics simulation. Generally, each of these organizations has chosen to develop its own wave optics code in-house, and each code is actually used by at most a few individuals, the author and perhaps one or two others. These codes are notoriously difficult to use, and even the authors of the codes agree with this assessment.[2] There are several reasons for this. First, the intrinsic complexity of wave optics modeling is considerable, and the computer languages used - usually Fortran, sometimes C - provided very little support for dealing with this complexity. Second, the code authors necessarily had to be expert in optical systems and computer modeling of optical effects; they did not have to be experts in software design. Third, when the author intends a code primarily for his own use, which has often been the case, it is less necessary to design for ease of use, and less cost-effective, than when a code is intended to be used by many. Fourth, and finally, until recently wave optics simulation has been very expensive in terms of computer resources, which limited the extent to which it could be used, and this reduced the incentive to develop a more user-friendly code.
In recent years, the situation has changed. Advances in computer hardware and software technologies have made the development of a user-friendly wave optics code both more feasible and more worthwhile. Today, anyone working in the field is likely to have access to a machine powerful enough to run wave optics simulations. At the same time, there have been significant advances in a number of software technologies relevant to large-scale simulation, such as object-oriented programming, component-based software architectures, and visual programming environments. By exploiting these technologies we found that it was possible to present the user with a much simpler and more intuitive interface while maintaining the same level of fidelity as traditional wave optics codes.
In developing WaveTrain we did not "reinvent the wheel". All of the basic techniques and algorithms used in wave optics had already been implemented and tested for previous wave optics codes, and we had access to the source code for several of these (ACS, YAPS, TASAT, BBPC). Where it made sense, we used the legacy code directly. In some cases minor modifications were needed to satisfy integration requirements, and in some cases it was simpler to rewrite the code. Wherever we chose to do a rewrite, we verified that the new implementation was functionally equivalent to the original. Also, we performed two detailed side-by-side comparison studies to anchor WaveTrain to ACS, which itself has been well-anchored to both theory and experiment. We found that WaveTrain reproduced the results of ACS for a variety of sensitive measures (log amplitude variance, phase variance, etc.) for both point sources and extended beacons.
WaveTrain has been implemented using tempus[3], a general purpose simulation development environment. tempus provides a component-based software architecture with an object-oriented application programmer interface (API), and an integrated visual programming environment. In addition to the general purpose facilities provided by tempus, WaveTrain consists of (1) A C++ software library designed to support wave optics modeling. This library makes heavy use of software imported from the various legacy codes. (2) A tempus component library for wave optics, where each type of software component models a different system component or physical effect. (3) A number of specialized graphical user interface (GUI) components designed to support certain complex tasks specific to wave optics, such as setting up deformable mirror and wavefront sensor geometries. (4) A number of working examples of complete system models. These models are designed to illustrate the correct use of the tool, and to provide a useful starting point for building new models.
WaveTrain is a working tool, with a small but growing user community. At the same time, it is under continuing development, driven by our user's needs. New types of components are being added regularly, and all aspects of the tool are being continually reviewed and revised in the attempt to improve usability. Our users report that they find WaveTrain much easier to use than previous wave optics codes, but there remains room for improvement. WaveTrain has been developed by MZA Associates Corporation with assistance from Scientific Applications International Corporation, under funding from Air Force Research Labaratory. tempus, which serves as the foundation for WaveTrain, was also developed by MZA Associates Corporation, under partial funding from a Small Business Innovative Research grant.
Figure 1. The tempus System Class Editor
2. An overview of WaveTrain
The most visible parts of WaveTrain are its Graphical User Interface (GUI) components. The most important of these is the tempus Visual Editor, or tve. As the name indicates, the tve is a part of tempus, the general-purpose simulation tool which serves as the foundation for WaveTrain. The tve has two major components, the System Class Editor, and the Run Set Editor. The System Class Editor, shown in Figure 1, is a connect-the-blocks visual programming environment in which the user assembles system models. The Run Set Editor, shown in Figure 2 is a simple spreadsheet-like interface which allows the user to set up and execute parameter studies using these system models. Both the System Class Editor and the Run Set Editor use automatic source code generation to translate the users' requests into an executable simulation. In the System Class Editor, each system model is translated into a different C++ class derived from a common base class, called System. (The class System is a key part of the tempus application programmer interface (API).) In the Run Set Editor, each parameter study is translated into a C++ main program, typically with a set of nested for-loops, one for each system parameter the user wished to vary. Once generated, the C++ code is portable and completely independent of the visual programming environment. This means the user can run the visual programming environment and smaller simulation jobs on his desktop machine, then transfer large jobs to a more powerful server for execution.
Figure 2. The tempus Run Set Editor
While the tve provides the overall framework for constructing and using WaveTrain models, being a general-purpose tool it cannot provide the kind of application-specific support that is needed for certain specialized modeling tasks, such as setting up an adaptive optics geometry. To handle such cases, we design special purpose GUI components, which augment the tve. At present, WaveTrain includes two such GUI components, AoTool and TurbTool. AoTool, shown in Figure 3, is used for setting up adaptive optics geometries. This includes the subaperture geometry for the wavefront sensor, the actuator geometry for the deformable mirror, the actuator influence function, and so on. For each geometry, AoTool generates a file which records this information; the filename is then used in tve to specify which geometry should be used. Also, the file is in Matlab format, and we have a variety of Matlab functions which can be used to analyze the system. TurbTool, shown in Figure 4, is used for setting up a models of atmospheric propagation paths. This includes the distribution of turbulence along the path, wind velocities, and the power spectra of the turbulence. Following the same pattern as AoTool, TurbTool generates a file for each turbulence distribution, and the filenames are used in tve to specify which distribution to use. As before, the files are in Matlab format. Both AoTool and TurbTool are implemented using Matlab graphical user interface utilities. (Note: For simple cases, such as a uniformly distributed turbulence, or distributions based on a well-known model such as Clear 1 Night, it is not necessary to use TurbTool at all. Instead, we have provided a simple function call interface that can be used directly from the tve.)
Figure 3. AoTool, the WaveTrain tool for setting up adaptive
optics geometries
Figure 4. TurbTool, the WaveTrain tool for setting up
atmospheric path turbulence profiles
Another key feature of WaveTrain is its output recording facility. All outputs of all subsystems are available for recording, provided the output is of a type the facility knows how to record. This includes C++ intrinsic types such as int and float, and a number of user-defined types we use frequently, such as Vector<float> and Grid<Complex>, and this list can be expanded as needed. Outputs can be recorded at regular intervals, whenever they change, or both. Which outputs should be recorded, and how, can be specified either in the System Class Editor or in the Run Set Editor; the System Class Editor defines the default recording, but this can be overridden in the Run Set Editor. Changes to the data recording are considered changes to the run set, not the system model. This means that the same system model can be used in a wide variety of parameter studies, which greatly simplifies the problem of configuration management.
The outputs for each run set are recorded to a specially formatted random access file called a tempus results file, with the extension trf. The trf file format preserves the structured character of the data, and support efficient browsing, searching, and filtering of the data, without loading the data set into memory. In principle trf files could be used with almost any analysis software, but in practice we have been using Matlab exclusively, and we have developed a library of Matlab functions to facilitate this. These include mechanisms designed for interactive use (see Figure 5), and mechanisms designed for use within other software. Once the selected data has been loaded, Matlab's analysis and data visualization capabilities can be brought to bear.
Figure 5. Loading WaveTrain simulation output into Matlab for postprocessing
3. example: A WAVETRAIN MODEL of a Planned Ground-To-AIR EXperiment
Later this year, the Air Force plans to conduct a ground-to-air laser propagation experiment at the White Sands missile range. In this experiment, an aircraft carrying a laser beacon and a "target board" (a large rectangular array of optical sensors) will fly past a mountaintop adaptive optics laser facility at a range of approximately 50 to 60 kilometers. The laser beacon carried by the aircraft will be used to drive both an adaptive optics system and a track loop, and a compensated scoring beam will then be propagated back to the aircraft, where the received energy will be measured by the target board. WaveTrain is being used to test and refine the design of the experiment.
Figure 6. WaveTrain model of the
ground-to-air experiment
The intent of the experiment is to demonstrate a closed loop adaptive optics beam projection system with a moving target. The first question to answer was whether the existing adaptive optics system, which was not designed for moving targets, could be expected to achieve a siginificant improvement in performance as compared to an uncompensated system. To answer this question, the first step was to construct a system model incorporating all the relevant components and effects, each modeled at an appropriate level of fidelity. What level of fidelity is "appropriate" depends on the question being considered, and how much the particular component or effect is expected to affect performance. Typically, one puts in the components and effects expected to be critical at high fidelity, and everything else at lower fidelity. One of the models we used is shown in Figure 6. As shown, only the overall structure is apparent, but using the System Class Editor one has access to all the details of the model: system and subsystem parameters, inputs, outputs, and structure. For example, if the user double-clicks on the beam control subsystem (the block labeled "Controls"), he will "descend" into it, and its internal structure becomes visible, as shown in Figure 7.
Figure 7. The beam control subsystem for the ground-to-air experiment
Once the model was complete, we performed a parameter study to measure the performance with and without adaptive optics for various assumed turbulence strengths. To measure the expected performance, we averaged over a number of random realizations of turbulence, in each case waiting for the adaptive optics loop to close, then averaging over the remaining simulation time. There is a tradeoff between using more turbulence realizations versus using longer simulation times: the former gives more independent samples, but the latter is more efficient, since the overhead related to closing the loop is less. For this study we chose to terminate the simulation just after the loop converged, at .01 seconds. We considered four strengths of turbulence, and used 100 random turbulence realizations at each strength. We also varied a number of control parameters, attempting to optimize performance. Figure 8 shows one of the run sets we used in the study. Space does not permit us to show all the system parameters; there were a total of 32, allowing the user to fine-tune the control system, the engagement scenario, the atmosphere model, and various modeling options. For the same reason, you do not see all the "Run Variables"; there were a total of eight. Run variables used to specify the simulation runs we wish to perform in this run set. They include "loop variables", which define a set of nested for-loops, and other variables used in the setting expressions for the system parameters.
Figure 8. One of the "run sets" used in this study
The main result of the study was what we had hoped: according to our model, system performance should be substantially improved when the adaptive optics and track loops are closed, as shown in Figure 9. This was encouraging, but it also meant we had more work to do. In constructing our original model we chose to neglect certain degrading effects, such as radiometrics and dynamic range limits, because we expected them to be of secondary importance. Had our results been negative we would have been finished, but getting a positive result with a simplified model meant that we needed to put together a more detailed model, and check whether the result would hold up. This meant we needed to create a few new WaveTrain components, and modify at least one existing component, HartmannSensor. This work is underway.
Figure 9. Expected performance improvement for the ground-to-air experiment
4. Conclusion
Our design objective for WaveTrain was to make it much more user -friendly than previous wave optics codes, without sacrificing fidelity or efficiency. We believe we have met this objective. WaveTrain is in now regular use for practical applications, and some of its heaviest users are not simulation specialists. Users can build models from scratch, or a copy an existing model, then modify it to suit their needs. More advanced users can create their own components, which can then be used and reused just like those in the WaveTrain library. They can (and do) develop their own post-processing software using the Matlab command language and the trf file interface. At least two of the other papers to be presented in this session make use of WaveTrain results.
At the same time, there remains considerable room for improvement. WaveTrain is still very much under development, and still has quite a few rough edges. The documentation is never up to date. The component library is far from complete, and many of component interfaces could be improved. The GUI is getting better and better, but there is always more to do. And so on. We are hard at work on all these things.
5. Acknowledgements
WaveTrain is built upon the work of the many scientists and engineers involved in developing the technologies of adaptive optics and wave optics simulation. We are especially indebted to Russ Butts (AFRL), Bill Brown (AFRL), Greg Cochran, Brent Ellerbroek (AFRL), Don Link (SAIC), Russ Vernon (SAIC), and Don Washburn (AFRL).
The work described has been funded under Air Force
contracts F29601-92-C-0131 and F29601-97-C-0030.
MZA
Associates Corporation
2021 Girard
SE, Suite 150, Albuquerque, NM 87106
Voice:
(505)245-9970