Analyzing a High Energy Laser Modeling and Simulation Framework

1. Analyzing a High Energy Laser Modeling and Simulation Framework Midn 1/C Eric Eckstrand SI495 Computer Science Department United States Naval Academy Annapolis, Maryland, USA

2. Introduction • Our focus is on end-to-end lasing simulations that consider system performance modeling/assessment of weapon effectiveness from varying perspectives. • One simulation prospective: Follow the physics of a shipboard laser's energy starting with: • energy conversion from the ship’s fuel, • generation of the laser’s light, • beam transport, etc, and • ending with illumination on target. Proposed HEL M&S architectures must fit into this hierarchy, with data transfer facilities between the levels as a design goal. The military M&S hierarchy pyramid.

3. Engineering-Engagement Modeling • Notional methodology for passing physics-based High Energy Laser (HEL) modeling results through to the mission-model level.

4. The Role of Software Engineering • Collections of such simulations must include the integration of a variety of laser devices, beam control technologies, and provide for atmospheric compensation considerations, and can be expected to contain significant overlap in functionality. • Software architectures developed for such simulations must be: • extensible, and reusable • support data transfer between simulations to facilitate data traceability Domain-Specific 65% Domain-Independent Three Classes of Software in a Typical Software Application 20% Application-Specific 15%

5. Component-based software engineering • Component-based software engineering focuses on constructing software from previously existing components in an effort to improve reuse. • Toolkits such as Carnegie Mellon University’s Aesop System allow developers to mitigate disparities between assumptions made about a reusable component and the system in which the component is to be reused. • We analyze Northrup Grumman’s High Energy Laser Simulation End-to-End Modeling (HELSEEM) framework developed as part of the JTO HEL M&S program. • The HELSEEM framework provides a message-passing based architecture for integrating dissimilar models, and supports the inclusion of both legacy and emergent modeling codes.

6. Northrop Grumman’s HELSEEM • Such frameworks can be either monolithic or modular. • Monolithic Approach • Northrop Grumman’s Approach • Modular Approach • Why? High Energy Laser Software Simulation HELSEEM Clock Laser Target Propagation Method Sensor Modeling framework must anticipate both future refinements to the wave propagation model as well as the emergence of competitive models with varying levels of fidelity.

7. HELSEEM’s Joint Message Passing System • HELSEEM provides a message passing bus, communication protocol, and message broker that together form the Joint Message Passing System (JMPS). • JMPS bus provides comm between components in sim. • Messages on bus are defined both by name and by the information contained inside the message. • Each component within the framework, including user-defined components, samples the bus for messages it can respond to. • Different components can be made responsible for getting the conditions that impact beam quality, actually computing the beam quality, and then displaying the resultant beam

8. Message Passing Hierarchy • Including a laser model’s code into the framework is a two step process, and involves building a ‘shell’ of a propagation component for the new model and then integrating the model into the shell. • The JMPS protocols for propagating a wavefront can be viewed as a message passing inheritance hierarchy, • BlurPropagator redefines methods allowing for the default introduction of a low fidelity blur effect used to control output to the display.

9. Goal: Integrating Legacy Laser Codes • Our goal was to consider the difficulty of integrating legacy laser codes within the HELSEEM framework. • The HELSEEM framework is written in Windows-based C++ and offers both • its own model of laser propagation, as well as • providing its users with a reuse-based capability of augmenting the framework with their own models of laser propagation • We incorporated a variant of NPS’s Dr. Bill Colson’s model for laser wavefront propagation through the atmosphere into the HELSEEM framework.

10. Propagation Component • Project Focus: Replace HELSEEM’s default propagation code with Dr. Colson’s code HELSEEM w/default propagation Clock Laser Target Propagation Method Sensor HELSEEM w/Colson’s prop Clock Laser Target Sensor Dr. Colson’s Propagation Code Propagation Method

11. Colson’s model for laser wavefront propagation • Code used by NPS physics graduate students as part of intro to Free-Electron Laser coursework. • Input parameters define the propagation environment. • UNIX-based C program generates and progressively manipulates a laser wavefront. • Virtual lenses allow modeling various conditions such as thermal blooming

12. Incorporating Dr. Colson’sPropagation Model HELSEEM w/Colson’s prop Clock Laser Target Sensor ? Input file: initialization parameters Script File: initialization parameters #2 #1 Legacy Prop Code NewPropagator NewPropagator w/ Legacy Prop Code Output File: Representation Of a propagated wave Approach #2 Legacy Code rewritten as HELSEEM entity Approach #1 Legacy Code as External Entity

13. 1st Approach – Legacy Code as External Entity • Colson’s code propagates wavefront by incrementally manipulating beam’s underlying data representation. • Each increment partially propagates the wavefront, and can be viewed as individual slices of the wavefront, or in aggregate as a 3D view of path from transmission source to target. • Treated legacy code as an external entity rather than rewriting the wavefront propagation source code to create a HELSEEM component.

14. 1st Approach Leaves Legacy Code Intact • Create Microsoft Visual C++ program to house system calls to legacy code written in C under Unix • Make system call to legacy code in HELSEEM component (NewPropagator.cpp) • Read output of legacy program and process to a form understood by HELSEEM (Intensity Grid) • Place the grid in a HELSEEM message • Broadcast the message via JMPS message broker network Sensor Target Laser Script File Clock Legacy Code Propagation Method Display Output (Intensity Grid)

15. Legacy Code via System Calls • HELSEEM represents a laser’s wavefront as an intensity grid and a phase grid, with a one-to-one correlation between the output produced by the legacy code and the input required by HELSEEM framework for intensity. • Legacy code minor modification in order to produce output for phase angles of each complex entry in grid, • Required pre-processing to prepare grid for entry into JMPS message broker.

16. Advantages of Legacy Code as External Entity • Invoking the legacy code via system or remote calls allows: • minimization of code transfer from the legacy code to the corresponding HELSEEM component, and • the ability to run a wavefront’s prop code on disparate hardware. • The 2nd approach we took was to rewrite the legacy code to allow its inclusion as a self contained HELSEEM component.

17. 2nd Approach: Convert Legacy Code to HELSEEM Component • Convert legacy code’s C functions into C++ functions • Move the functions and variables into the NewPropagator class (“Converted Legacy Code” below) as private members • NewPropagator class designed to accept input from a script file • Write the script file section that inputs the initialization parameters

18. 2nd Approach, Legacy as HELSEEM entity • Advantageous when the legacy code takes on more responsibility than just wavefront propagation. • In our case, we had code that generates an initial beam and also contains the model for propagating the beam. • Within HELSEEM, generating a wavefront should be the responsibility of a component within the framework since generation depends on the characteristics of the laser which should not be visible to the other components. • Disadvantages: • Not all legacy code can be easily re-written. • Legacy code may run faster on dissimilar architecture

19. Advantages provided by the HELSEEM Framework • HELSEEM’s advantages center around the ability to communicate with any component by broadcasting a message via the broker. • Framework supports the ability to write additional components that transform one message’s contents to a different format which tends to mitigate data model disparity issues. • Took this route with our 2nd approach in order to compute phase angles that HELSEEM’s display components could recognize. • Suggests that a message arbitrator would be useful to: • determine which messages a component may, or should, respond to, • especially where more than one component can be expected to act on the same message.

20. Advantages provided by the HELSEEM Framework • Other advantages provided by HELSEEM’s approach include support from the framework for the user to tailor the output. • For example, the legacy code’s propagation can be viewed as a series of two dimensional slices of the laser’s wavefront. • Users can add their own user-defined display components to the framework. • These components could display a 3D view of the beam during propagation, or present tables numerically depicting the computed intensity of the beam at any or all points along propagation path. • This extensibility makes HELSEEM particularly valuable for end-to-end simulations.

21. Areas of Improvement • The ease with which legacy propagation codes can be made to interact with the HELSEEM framework. • If HELSEEM were modified to support generalized wrapper classes designed for integration with laser propagation codes, much of the effort needed to integrate legacy code would be diminished. • Such wrapper classes would need an interface that HELSEEM could expect to dynamically invoke. • The legacy code would then need to be tied in only with the wrapper class, leaving little knowledge required on the part of the user regarding the inner workings of the HELSEEM framework. • This requires the identification of a super-set of methods and data used in end-to-end high energy laser simulations

22. Areas of Improvement • We found that while the hierarchy of components capable of responding to user-defined JMPS messages is readily expandable, the underlying data model is somewhat limited with regard to what data can be placed in a message. • We cannot, for example, send a message directly to a display component that contains information that describes how the propagating wavefront looks on a target, but must instead follow the HELSEEM message passing protocols though which the data is manipulated according to the component(s) receiving and acting upon the message. • A standardized but expandable data model would prove beneficial for end-to-end simulations.

23. Conclusions • Simulation environments that support integration and substitution of laser modeling codes of varying fidelity are required for high energy laser end-to-end simulations. • Northrop Grumman’s HELSEEM framework supports tracing a laser’s energy from initial conversion through to target illumination. • Such simulations benefit from a modularized architecture in which components can be modified or replaced without significantly impacting the rest of the simulation framework.  • We incorporated an existing laser propagation model into the HELSEEM framework, and considered the framework’s underlying component model from the perspective of such legacy code integration.

24. Future Work • Consider the runtime impact of the various laser models communicating via the HELSEEM message broker. • There is a wide range of models with different degrees of fidelity (mathematical accuracy). • High fidelity models typically take significantly longer to compute a result than a lower fidelity model. • An end-to-end laser propagation simulation can expect to integrate models of differing fidelity, and it would be useful to understand the impact on message passing via the broker in terms of timing issues between models. • For example, if one model produces a high fidelity, but short-lived, result for consumption by other components via the broker, then the time spent conducting message brokering must be evaluated to ensure timely use of that message’s data within the simulation.