si-495 presentation 1 analyzing a high energy laser modeling and simulation framework computer...

SI-495 Presentation 1

Analyzing a High Energy Laser Modeling and Analyzing a High Energy Laser Modeling and Simulation FrameworkSimulation Framework

Computer Science DepartmentUnited States Naval Academy

Annapolis, Maryland, USA

Midn 1/C Eric Eckstrand

SI495


IntroductionIntroduction

Our focus is on end-to-end lasing simulations that Our focus is on end-to-end lasing simulations that consider system performance modeling/assessment consider system performance modeling/assessment of weapon effectiveness from varying perspectives. of weapon effectiveness from varying perspectives.

One simulation prospective: Follow the physics of a One simulation prospective: Follow the physics of a shipboard laser's energy starting with: 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.


Engineering-Engagement ModelingEngineering-Engagement Modeling

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


The Role of Software EngineeringThe Role of Software Engineering

Collections of such simulations must include the Collections of such simulations must include the integration of a variety of laser devices, beam control integration of a variety of laser devices, beam control technologies, and provide for atmospheric technologies, and provide for atmospheric compensation considerations, and can be expected to compensation considerations, and can be expected to contain significant overlap in functionality. 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

Domain-Independent

Application-Specific

65%

20%

15%

Three Classes of Software in a

Typical Software Application


Component-based software engineeringComponent-based software engineering

Component-based software engineering focuses on Component-based software engineering focuses on constructing software from previously existing constructing software from previously existing components in an effort to improve reuse. 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 We analyze Northrup Grumman’s High Energy Laser Simulation End-to-End Modeling (HELSEEM) Simulation End-to-End Modeling (HELSEEM) framework developed as part of the JTO HEL M&S framework developed as part of the JTO HEL M&S program. 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.


Northrop Grumman’s HELSEEMNorthrop Grumman’s HELSEEM

Such frameworks can be either monolithic or modular.Such frameworks can be either monolithic or modular. Monolithic Approach

Northrop Grumman’s Approach Modular Approach Why?

High Energy Laser Software Simulation

Laser Target SensorPropagation

Method

HELSEEM

Clock

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.


HELSEEM’s Joint Message Passing SystemHELSEEM’s Joint Message Passing System

Messages on bus are defined Messages on bus are defined both by name and by the both by name and by the information contained inside information contained inside the message.the message.

HELSEEM provides a message passing bus, communication HELSEEM provides a message passing bus, communication protocol, and message broker that together form the Joint protocol, and message broker that together form the Joint Message Passing System (JMPS).Message Passing System (JMPS). JMPS bus provides comm

between components in sim.

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


Message Passing HierarchyMessage Passing Hierarchy

Including a laser model’s code into the framework is Including a laser model’s code into the framework is a two step process, and involves building a ‘shell’ of a two step process, and involves building a ‘shell’ of a propagation component for the new model and then a propagation component for the new model and then integrating the model into the shell. 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.


Goal: Integrating Legacy Laser CodesGoal: Integrating Legacy Laser Codes

Our goal was to consider the difficulty of integrating Our goal was to consider the difficulty of integrating legacy laser codes within the HELSEEM legacy laser codes within the HELSEEM framework.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 We incorporated a variant of NPS’s Dr. Bill Colson’s model for laser wavefront propagation Colson’s model for laser wavefront propagation through the atmosphere into the HELSEEM through the atmosphere into the HELSEEM framework. framework.


Propagation ComponentPropagation Component

Project Focus: Replace HELSEEM’s default Project Focus: Replace HELSEEM’s default propagation code with Dr. Colson’s codepropagation code with Dr. Colson’s code

Laser Target Sensor

PropagationMethod

HELSEEM w/Colson’s prop

Dr. Colson’sPropagation

Code

Clock

Laser Target SensorPropagation

Method

HELSEEM w/default propagation

Clock


Colson’s model for laser wavefront propagationColson’s model for laser wavefront propagation

Code used by NPS physics graduate students as part Code used by NPS physics graduate students as part of intro to Free-Electron Laser coursework.of intro to Free-Electron Laser coursework.

Input parameters Input parameters define the propagation define the propagation environment.environment. UNIX-based C

program generates and progressively manipulates a laser wavefront.

Virtual lenses allow modeling various conditions such as thermal blooming


Incorporating Dr. Colson’sIncorporating Dr. Colson’sPropagation Model Propagation Model

LegacyProp Code

Input file:initializationparameters

Output File:RepresentationOf a propagated

wave

NewPropagator NewPropagatorw/ LegacyProp Code

Script File:initializationparameters

Approach #1 Legacy Code as External Entity

Approach #2 Legacy Code rewritten as

HELSEEM entity

Laser Target Sensor

HELSEEM w/Colson’s prop

Clock ?

#1#2


11stst Approach – Legacy Code as External Entity Approach – Legacy Code as External Entity

Colson’s code propagates wavefront by incrementally Colson’s code propagates wavefront by incrementally manipulating beam’s underlying data representation. 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.


11stst Approach Leaves Legacy Code Intact Approach Leaves Legacy Code Intact

Create Microsoft Visual C++ program to house Create Microsoft Visual C++ program to house system calls to legacy code written in C system calls to legacy code written in C under Unixunder 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 messagePlace the grid in a HELSEEM message Broadcast the message via JMPS Broadcast the message via JMPS

message broker network message broker network

Laser

Target

Sensor

PropagationMethod

ClockScriptFile

Display

Legacy Code

Output (Intensity Grid)


Legacy Code via System CallsLegacy Code via System Calls HELSEEM represents a laser’s wavefront as an intensity HELSEEM represents a laser’s wavefront as an intensity

grid and a phase grid, with a one-to-one correlation grid and a phase grid, with a one-to-one correlation between the output produced by the legacy code and the between the output produced by the legacy code and the input required by HELSEEM framework for intensity.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.


Advantages of Legacy Code as External EntityAdvantages of Legacy Code as External Entity

Invoking the legacy code via system or remote calls allows: 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 2The 2ndnd approach we approach we took was to rewrite the took was to rewrite the legacy code to allow its legacy code to allow its inclusion as a self inclusion as a self contained HELSEEM contained HELSEEM component.component.


22ndnd Approach: Convert Legacy Code to Approach: Convert Legacy Code to HELSEEM ComponentHELSEEM Component

Convert legacy code’s C functions into C++ functionsConvert legacy code’s C functions into C++ functions Move the functions and variables into the NewPropagator class Move the functions and variables into the NewPropagator class

(“Converted Legacy Code” below) as private members(“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


22ndnd Approach, Legacy as HELSEEM entity Approach, Legacy as HELSEEM entity

Advantageous when the legacy code takes on more Advantageous when the legacy code takes on more responsibility than just wavefront propagation. 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: Disadvantages: Not all legacy code can be easily re-written. Legacy code may run faster on dissimilar

architecture


Advantages provided by the HELSEEM Advantages provided by the HELSEEM FrameworkFramework

HELSEEM’s advantages center around the ability to HELSEEM’s advantages center around the ability to communicate with any component by broadcasting a communicate with any component by broadcasting a message via the broker. message via the broker.

Framework supports the Framework supports the ability to write additional ability to write additional components that transform one components that transform one message’s contents to a different message’s contents to a different format which tends to mitigate data model disparity issues. 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: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.


Advantages provided by the HELSEEM Advantages provided by the HELSEEM FrameworkFramework

Other advantages provided by HELSEEM’s approach Other advantages provided by HELSEEM’s approach include support from the framework for the user to tailor include support from the framework for the user to tailor the outputthe 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.


Areas of ImprovementAreas of Improvement

The ease with which legacy propagation codes can be The ease with which legacy propagation codes can be made to interact with the HELSEEM framework. 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 This requires the identification of a super-set of methods and data used in end-to-end high energy laser methods and data used in end-to-end high energy laser simulationssimulations


Areas of ImprovementAreas of Improvement

We found that while the hierarchy of components capable We found that while the hierarchy of components capable of responding to user-defined JMPS messages is readily of responding to user-defined JMPS messages is readily expandable, the underlying data model is somewhat limited expandable, the underlying data model is somewhat limited with regard to what data can be placed in a message. 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.


ConclusionsConclusions

Simulation environments that support integration and Simulation environments that support integration and substitution of laser modeling codes of varying fidelity substitution of laser modeling codes of varying fidelity are required for high energy laser end-to-end are required for high energy laser end-to-end simulations. 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 We incorporated an existing laser propagation model into the HELSEEM framework, and considered the into the HELSEEM framework, and considered the framework’s underlying component model from the framework’s underlying component model from the perspective of such legacy code integration. perspective of such legacy code integration.


Future WorkFuture Work

Consider the runtime impact of the various laser models Consider the runtime impact of the various laser models communicating via the HELSEEM message broker. 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.

si-495 presentation 1 analyzing a high energy laser modeling and simulation framework computer...

Documents