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
SI-495 Presentation 1
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.
SI-495 Presentation 2
Engineering-Engagement Modeling

Notional methodology for passing physics-based High
Energy Laser (HEL) modeling results through to the
mission-model level.
SI-495 Presentation 3
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
Three Classes of
Software in a Typical
Software Application
Domain-Independent
20%
65%
Application-Specific
15%
SI-495 Presentation 4
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.
SI-495 Presentation 5
Northrop Grumman’s HELSEEM

Such frameworks can be either monolithic or modular.
 Monolithic Approach
High Energy Laser Software Simulation

Northrop Grumman’s Approach
 Modular Approach
 Why?
Clock
HELSEEM
Laser
Target
Propagation
Sensor
Method
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.
SI-495 Presentation 6
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 userdefined 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
SI-495 Presentation 7
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.
SI-495 Presentation 8
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 Windowsbased 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.
SI-495 Presentation 9
Propagation Component

Project Focus: Replace HELSEEM’s default
propagation code with Dr. Colson’s code
HELSEEM w/default propagation
Clock
Laser
Target
Propagation
Sensor
Method
HELSEEM w/Colson’s prop
Clock
Laser
Dr. Colson’s
Propagation
Code
Target
Sensor
Propagation
Method
SI-495 Presentation 10
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
SI-495 Presentation 11
Incorporating Dr. Colson’s
Propagation Model
HELSEEM w/Colson’s prop
Clock
Input file:
initialization
parameters
Legacy
Prop Code
Output File:
Representation
Of a propagated
wave
Laser
Target
#1
NewPropagator
Approach #1
Legacy Code as
External Entity
?
Sensor
#2
Script File:
initialization
parameters
NewPropagator
w/ Legacy
Prop Code
Approach #2
Legacy Code
rewritten as
HELSEEM entity
SI-495 Presentation 12
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.
SI-495 Presentation 13
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
Script
File
Sensor
Target
Laser
Clock
Legacy Code
Output
(Intensity Grid)
Propagation
Method
Display
SI-495 Presentation 14
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.
SI-495 Presentation 15
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.
SI-495 Presentation 16
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
SI-495 Presentation 17
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
SI-495 Presentation 18
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.
SI-495 Presentation 19
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.
SI-495 Presentation 20
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
SI-495 Presentation 21
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.
SI-495 Presentation 22
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.
SI-495 Presentation 23
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.
SI-495 Presentation 24