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 ships fuel,
• generation of the lasers light,
• beam transport, etc, and
• ending with illumination
  on target.

Proposed HEL MS architectures must fit into this
hierarchy, with data transfer facilities between
the levels as a design goal.
The military MS 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 Universitys
  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 Grummans High Energy Laser
  Simulation End-to-End Modeling (HELSEEM)
  framework developed as part of the JTO HEL MS
  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 Grummans HELSEEM

• Such frameworks can be either monolithic or
  modular.
• Monolithic Approach
• Northrop Grummans Approach
• Modular Approach
• Why?

High Energy Laser Software Simulation
HELSEEM
Laser
Target
Sensor
Propagation Method
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.
7
HELSEEMs 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 models 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 NPSs Dr. Bill
  Colsons model for laser wavefront propagation
  through the atmosphere into the HELSEEM
  framework.

10
Propagation Component

• Project Focus Replace HELSEEMs default
  propagation code with Dr. Colsons code

HELSEEM w/default propagation
Laser
Target
Sensor
Propagation Method
Clock
HELSEEM w/Colsons prop
Laser
Target
Sensor
Clock
Dr. Colsons Propagation Code
Propagation Method
11
Colsons 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. ColsonsPropagation Model
HELSEEM w/Colsons prop
Laser
Target
Sensor
Clock
?
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

• Colsons code propagates wavefront by
  incrementally manipulating beams 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 lasers 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
  wavefronts 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 codes 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

• HELSEEMs 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
  messages 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 HELSEEMs 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 HELSEEMs approach
  include support from the framework for the user
  to tailor the output.
• For example, the legacy codes
  propagation can be viewed as a series
  of two dimensional slices
  of the lasers 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 Grummans HELSEEM framework supports
  tracing a lasers 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 frameworks 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 messages
  data within the simulation.